Joe Poyzer

Specializing in networking, systems, cloud, and automation.

📌 Overview

This project covers a physical-to-virtual (P2V) migration moving an existing lab environment — including a running Windows Server failover cluster — off a physical Hyper-V host and onto Proxmox VE. The goal was to change hypervisors without losing any of the work already built, and to understand what actually needs to be verified after a migration like this before trusting the environment again.

Environment:

  • Source: Physical Hyper-V host (FUSION-DT)
  • Destination: Cisco UCS host running Proxmox VE
  • Migration tooling: Veeam Agent for Windows

🤔 Why Migrate

The original lab ran on FUSION-DT's D drive — a spinning HDD used for VM storage. Under the I/O load of installing and running the cluster VMs, that drive was regularly getting pegged at 100% utilization, making the environment unreliable to work in. Rather than continue fighting disk performance on aging spinning storage, the cluster VMs were migrated to the Cisco UCS host, which had a proper RAID 10 SSD tier already built for exactly this kind of active VM workload (see the Cisco UCS Lab Server Deployment project).

🔧 Migration Approach: Two Veeam Tools, Two Reasons

This was a P2V (Physical-to-Virtual) migration — moving workloads off physical hardware (FUSION-DT) into a virtualized environment on the new host. It required two different Veeam tools, each solving a different part of the problem.

Veeam Agent for Windows — why it was necessary: FUSION-DT was running Windows 11 Pro, not Windows Server. Veeam Backup & Replication's Hyper-V integration is built around proper Hyper-V hosts (Windows Server with the Hyper-V role, or a dedicated Hyper-V Server) — it wasn't a supported target for hypervisor-level, host-integrated backup against a Windows 11 Pro machine, even with the client Hyper-V role enabled. Veeam Agent for Windows sidesteps that entirely by performing an image-level backup at the OS level, from inside the guest, regardless of what the underlying host is — which made it the right tool to actually get the VMs backed up off FUSION-DT in the first place.

Veeam Backup & Replication — finishing the migration: once the Veeam Agent backups existed, Veeam Backup & Replication's Instant VM Recovery feature was used to bring those backups up as running VMs directly from the backup repository — and then migrate them into permanent production storage on the Proxmox host, completing the move rather than leaving them running from a temporary recovery state.

The migration process followed a few key stages:

  • Pre-migration inventory — documenting exactly what was running on the source Hyper-V host, including the failover cluster nodes, their storage dependencies (the iSCSI shared disk), and any networking configuration that would need to carry over
  • Backup — using Veeam Agent for Windows to capture each VM at the OS level, since FUSION-DT itself wasn't a supported Veeam B&R Hyper-V target
  • Instant Recovery & migration to production — using Veeam B&R's Instant VM Recovery to bring the backed-up VMs online, then migrating them into permanent storage on the Proxmox host to finish the move
  • Post-migration validation — the critical step, and where most of the real work happened

✅ Post-Migration Validation

Moving VMs between hypervisors isn't the hard part — confirming everything still actually works afterward is. A few things specifically needed re-validation:

  • Cluster health — since the migrated environment included a Windows Server failover cluster, cluster validation had to be re-run post-migration to confirm nothing about the underlying virtual hardware change broke cluster communication or storage access
  • SCSI-3 Persistent Reservation behavior — a particular point of attention, since PR validation had already caused problems once during the original cluster build. Re-confirming this behavior specifically after a hypervisor change, rather than assuming it would "just work," avoided any surprises
  • Networking — confirming virtual NICs, VLANs, and any static IP/network configuration carried over correctly on the new virtual hardware layer under Proxmox

📈 Results

  • Full lab environment successfully migrated from Hyper-V to Proxmox VE with no data loss
  • Failover cluster re-validated and confirmed healthy post-migration
  • SCSI-3 Persistent Reservation behavior confirmed intact after the hardware layer change
  • Networking configuration carried over correctly with no reconfiguration needed

📝 Notes / Lessons Learned

  • A migration isn't done when the VM boots — it's done when everything dependent on that VM is re-validated. For a standalone VM, that might mean confirming the OS boots and services start. For something like a cluster, it means re-testing the specific mechanisms (like SCSI-3 PR) that could be sensitive to underlying hardware changes.
  • Documenting the source environment before migrating matters — knowing exactly what dependencies existed (shared storage, specific network config) made it possible to know what to check afterward, rather than discovering gaps reactively.
  • Choosing the right migration tool depends on what the source actually is — a client OS like Windows 11 Pro isn't a supported Veeam B&R Hyper-V target, so Veeam Agent was the right tool for the backup step, with Veeam B&R's Instant VM Recovery picking up from there to finish the move. Understanding the boundary between what each Veeam product actually supports avoided wasted time trying to force B&R to do something it wasn't designed for on this particular host.