Proxmox P2V: Migrate Physical Servers to Virtual Machines
Complete guide to physical-to-virtual (P2V) migration in Proxmox VE using dd, Clonezilla, qemu-img, and VirtIO driver injection.
Why Physical-to-Virtual Migration?
Physical-to-virtual (P2V) migration converts a physical server into a virtual machine running on Proxmox VE. This is common when consolidating aging hardware, moving workloads to a lab environment, or preserving a working system before hardware failure. Unlike enterprise tools that automate the process, Proxmox P2V relies on open-source tools and manual steps — but the result is a fully functional VM that mirrors the original physical machine.
Method 1: Raw Disk Image with dd
The simplest approach is to create a raw disk image of the physical server and import it into Proxmox. Boot the physical machine from a live Linux USB and run:
# Create a raw image of the entire disk (e.g., /dev/sda):
dd if=/dev/sda of=/mnt/external/server-disk.raw bs=4M status=progress
# If the physical machine is on the network, pipe over SSH:
dd if=/dev/sda bs=4M status=progress | ssh root@proxmox-host "dd of=/tmp/server-disk.raw bs=4M"
This creates an exact byte-for-byte copy. The downside is that the image will be the full size of the disk, including empty space. Convert it to a more efficient format:
# Convert raw to qcow2 (on the Proxmox host):
qemu-img convert -f raw -O qcow2 /tmp/server-disk.raw /tmp/server-disk.qcow2
# Or convert directly to a thin-provisioned raw image:
qemu-img convert -f raw -O raw /tmp/server-disk.raw /var/lib/vz/images/100/vm-100-disk-0.raw
Method 2: Clonezilla for Efficient Imaging
Clonezilla creates compressed images and skips unused disk sectors, making it much faster than dd for large disks with little data:
# Boot physical server from Clonezilla live USB
# Choose: device-image > local_dev > savedisk
# Save the image to an external drive or NFS share
# On the Proxmox host, restore the Clonezilla image to a raw file:
# Boot a helper VM from Clonezilla ISO, attach a blank disk, and restore
# Or use ocs-sr from command line:
ocs-sr -s /path/to/images -t /dev/sda restoredisk image_name sda
Import the Disk Image into Proxmox
Once you have the disk image on the Proxmox host, create a VM shell and import the disk:
# Create a VM with no disk (note the VM ID, e.g., 105):
qm create 105 --name migrated-server --memory 4096 --cores 2 --net0 virtio,bridge=vmbr0
# Import the disk to your storage (e.g., local-lvm):
qm importdisk 105 /tmp/server-disk.qcow2 local-lvm
# The command will output something like:
# Successfully imported disk as 'unused0:local-lvm:vm-105-disk-0'
# Attach the imported disk to the VM:
qm set 105 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-105-disk-0
# Set the boot order:
qm set 105 --boot order=scsi0
Fix the Bootloader
P2V migrations often break the bootloader because hardware has changed. If the VM fails to boot, attach a live ISO and repair:
# For GRUB (Linux systems):
# Boot from a Debian/Ubuntu ISO in rescue mode
mount /dev/sda2 /mnt # Mount root partition
mount /dev/sda1 /mnt/boot/efi # If UEFI
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt
# Reinstall GRUB:
grub-install /dev/sda
update-grub
exit
For Windows VMs, boot from a Windows installation ISO, choose "Repair your computer", open Command Prompt, and run:
bootrec /fixmbr
bootrec /fixboot
bootrec /rebuildbcd
VirtIO Driver Injection
Physical machines use hardware-specific drivers (SATA, e1000 NIC). Proxmox VMs perform best with VirtIO drivers. For Linux guests, VirtIO modules are usually already in the kernel. Verify and load them:
# Check if VirtIO modules are available:
modprobe virtio_blk
modprobe virtio_net
modprobe virtio_scsi
# Regenerate initramfs to include VirtIO drivers:
update-initramfs -u # Debian/Ubuntu
dracut --force # RHEL/AlmaLinux
For Windows guests, you must inject VirtIO drivers before switching the disk bus. Download the VirtIO ISO from Fedora, attach it to the VM, and install the drivers through Device Manager while the disk is still on IDE/SATA. Then switch to VirtIO in the VM config.
Post-Migration Cleanup
After the VM boots successfully, clean up hardware-specific configurations:
# Remove old network interface rules (Linux):
rm /etc/udev/rules.d/70-persistent-net.rules
# Update /etc/fstab if disk identifiers changed:
blkid # Check new UUIDs
nano /etc/fstab # Update UUIDs if needed
# Remove hardware-specific packages:
apt remove --purge firmware-* 2>/dev/null
# Reinstall guest agent:
apt install qemu-guest-agent -y
systemctl enable qemu-guest-agent
During P2V migrations, you often need to monitor the import progress and restart the target VM several times while troubleshooting boot issues. ProxmoxR makes this easier by letting you start, stop, and check VM status from your phone — useful when you are physically at the server adjusting BIOS settings while managing VMs remotely.
Summary
Physical-to-virtual migration in Proxmox involves imaging the physical disk (with dd or Clonezilla), converting the image with qemu-img, importing it into a Proxmox VM, and then fixing the bootloader and injecting VirtIO drivers. While more manual than commercial P2V tools, this approach is reliable and works with any operating system. Take the time to plan the migration, especially for production servers, and test the resulting VM thoroughly before decommissioning the physical hardware.
Take Proxmox management mobile
All the features discussed in this guide — accessible from your phone with ProxmoxR. Real-time monitoring, power control, firewall management, and more.