The Nightmare of Migrating Legacy Physical Servers
About six months ago, I took on a system upgrade project for a local business. Their fleet of Dell PowerEdge R710 servers had been running non-stop for 8 years on CentOS 6 and Ubuntu 14.04. The amber warning lights were blinking, and the hard drives were clicking — a death rattle signaling the end was near. My job: lift all this “vintage hardware” onto a new KVM cluster to consolidate resources and simplify backups.
Anyone in the VMware world is no stranger to VMware vCenter Converter. But when you move into the open-source KVM or Proxmox ecosystem, finding a comparable tool is anything but easy. I tried dd over SSH and even Clonezilla. The result? VMs that constantly hung at the boot screen due to missing VirtIO drivers or broken GRUB configurations.
After several sleepless nights, I discovered virt-p2v. Combined with virt-v2v, this duo forms the smoothest toolkit for migrating Linux servers to KVM. In practice, I successfully migrated 5 physical servers to Proxmox in a single night — without spending a dime on licensing.
Comparing Popular P2V Methods
Before diving in, let’s look at the options you’ve probably already considered:
- Using dd/rsync: The most manual approach. You copy raw data from the physical disk to an image file. However, the bootloader failure rate is extremely high because it doesn’t automatically install VirtIO drivers.
- Clonezilla: Great for disk image backups. But when restoring to a VM, you have to manually reconfigure the kernel to recognize virtual storage devices — a very time-consuming process.
- virt-p2v / virt-v2v: A purpose-built solution from Red Hat. It automatically scans hardware, converts disk formats to qcow2, and reinstalls drivers during the conversion process.
How virt-p2v Works
The process relies on two components:
- Conversion Server: A powerful Linux machine with
virt-v2vinstalled. This is where the data is received and the filesystem “surgery” takes place. - Source Machine (Client): The target physical server. You boot this machine from a USB drive containing the
virt-p2vlive environment.
Data is transferred via SSH from the physical machine to the Conversion Server. There, virt-v2v injects the necessary drivers into initrd/initramfs so the OS can boot in a virtualized environment.
Preparation Before You Begin
1. Set Up the Conversion Server
Use an Ubuntu or Debian machine with free disk space at least 20% larger than the source machine. Install the required packages:
sudo apt update
sudo apt install virt-v2v libguestfs-tools -yMake sure this server is accessible via SSH as root, or as a user with passwordless sudo privileges, so the data transfer isn’t interrupted.
2. Create a virt-p2v Boot Disk
Download the virt-p2v ISO from the Red Hat repository or the community. If you want to build a custom image, use the virt-p2v-make-disk tool. Then use Rufus to create a bootable USB drive and plug it into the physical server.
Step-by-Step Instructions
Step 1: Boot the Physical Machine into the virt-p2v Environment
Boot the machine from the USB drive. The virt-p2v interface is fairly straightforward. Configure a static IP to ensure a stable network connection — avoid DHCP if your internal network is unreliable.
Step 2: Connect to the Conversion Server
In the interface, fill in the following details:
- Hostname: The IP address of your Conversion Server.
- User/Password: Your SSH login credentials.
Click Test Connection. If you see a success message, you’re halfway there.
Step 3: Configure the Target VM
Now you need to specify the parameters for the new virtual machine:
- Target Properties: Set the VM name, CPU core count, and RAM allocation.
- Disks: Select the disk to migrate (usually
/dev/sda). - Output format: Always prefer
qcow2to take advantage of KVM’s snapshot functionality.
Step 4: Start the Conversion
Click Start Conversion. Transfer speed depends on your LAN bandwidth. With a 1Gbps network, I typically see around 60–80 MB/s. A 100GB drive usually takes about 25–30 minutes.
Monitor the detailed progress on the Conversion Server with:
tail -f /var/log/virt-v2v.logReal-World Troubleshooting Tips
Through hands-on experience, I’ve gathered a few important lessons:
1. Missing VirtIO Drivers
On very old Linux distributions like CentOS 5, virt-v2v sometimes can’t find a compatible kernel. Update the kernel to the latest version on the source machine before starting the P2V migration.
2. SSH Configuration
If the connection fails, check /etc/ssh/sshd_config. You need to ensure PermitRootLogin yes is temporarily enabled. Don’t forget to disable it again after you’re done for security reasons.
3. UEFI-Based Machines
If the physical machine uses UEFI, you must select OVMF as the firmware when creating the VM in KVM. If you leave it as the default BIOS setting, the VM will invariably throw a “No bootable device” error.
Post-Migration Checklist
Once the process is complete, you’ll have a .qcow2 file and an XML definition file. Importing into KVM is quick:
virsh define /path/to/vm.xml
virsh start my_new_vmNote: The network interface name may change (for example, from eth0 to enp0s3). You’ll need to update the network configuration in /etc/netplan/ or /etc/network/interfaces to match the new interface name.
Conclusion
Using virt-p2v is the most professional way to give old physical servers a new life in a KVM virtualization environment. While the interface may look a bit dated, its reliability far surpasses raw copy-based methods. If you’re planning a server room cleanup, give this toolkit a try. Here’s to a smooth migration!
