P2V Migration to Proxmox VE: Physical Server to VM Guide

What P2V Migration Actually Means

Physical-to-virtual (P2V) migration is the process of taking an operating system that is currently installed on real, physical hardware — a tower server under a desk, a 1U box in a rack, an old workstation someone turned into a "server" five years ago — and converting it into a virtual machine that boots and runs on Proxmox VE, with no reinstall and no reconfiguration of the applications running on top.

This is different from every other migration path Proxmox VE documents well. Importing from VMware ESXi, pulling in an OVA/OVF appliance, or moving a VM between two Proxmox clusters all start from a guest that is already virtualized somewhere. P2V starts from bare metal: there is no hypervisor, no export format, no VM configuration file to read. All you have is a disk (or several), a running kernel, and whatever hardware-specific drivers that kernel currently depends on to boot.

People reach for P2V for a handful of very concrete reasons:

Aging hardware that is about to fail or go end-of-life. A ten-year-old file server with SMART errors piling up is a ticking clock. P2V lets you preserve the exact working system — OS, application state, licensing, cron jobs, quirky configuration nobody wrote down — without a risky from-scratch reinstall under time pressure.
Consolidating scattered physical boxes onto a Proxmox VE host or cluster. Small businesses and homelabs alike tend to accumulate one-off physical machines over the years. P2V is how you fold them into a single, backed-up, snapshot-able virtualization platform.
Preserving a system you can no longer safely reinstall. Some old line-of-business applications only work because of years of undocumented manual configuration. Reinstalling from scratch risks losing something nobody remembers configuring in the first place.
Testing an OS or application before committing to decommissioning the physical box. P2V lets you validate the migrated copy in a VM while the original hardware keeps running as a fallback.

Scope note: This guide focuses on P2V for general-purpose Linux and Windows servers — the case where the goal is "make this physical machine's disk boot as a VM." It is not about importing from another hypervisor (see the ESXi Import Wizard or OVA/OVF import if that's your situation) and not about moving guests that are already Proxmox VMs between clusters (see remote migration or live migration for that).

How P2V Compares to Other Migration Paths in Proxmox VE

It's worth being explicit about where P2V sits relative to the migration tooling Proxmox VE actually ships, since the terminology gets mixed up constantly:

Method	Source	What already exists	Tooling
P2V (this guide)	Physical hardware, no hypervisor	A running OS on bare metal disks	Live-boot media + disk imaging (dd, Clonezilla) or virt-p2v
ESXi Import Wizard	VMware ESXi host	An existing VM on another hypervisor	Proxmox VE's built-in Import Wizard
OVA/OVF import	A portable virtual appliance file	An exported VM package	`qm importdisk` + manual VM creation
Remote cluster migration	A different Proxmox VE cluster	An existing Proxmox VM/CT	`qm remote-migrate` / `pct remote-migrate`
Live migration	Another node in the same cluster	An existing Proxmox VM/CT	`qm migrate`

P2V is the odd one out because there's no export format and no API to call. You're working directly with block devices and, usually, a live-boot USB stick on the physical machine.

Prerequisites and Planning

Before you touch the physical machine, get these pieces in place:

Downtime window. Unlike live migration, P2V almost always requires the source machine to be offline (or at least quiesced) during the disk read, because you're imaging a live filesystem. Plan a maintenance window matched to the size of the data being copied and your network throughput.
Enough destination storage. Confirm the Proxmox VE storage you're targeting (local-lvm, local-zfs, a directory, etc.) has free space to comfortably fit the source disk(s), plus some headroom — you generally do not want to be right at the edge of a thin pool immediately after a P2V import.
Network path between the physical machine and the Proxmox host. Both the dd/netcat method and the Clonezilla network-clone method need the physical machine and the Proxmox node to be able to reach each other directly, ideally on a fast, low-latency LAN segment rather than over a VPN.
A live-boot USB for the physical machine. SystemRescue, a Clonezilla Live ISO written to USB, or any recent Debian/Ubuntu live image work for the dd/netcat method. Use the official Clonezilla Live ISO for the Clonezilla method.
Know your source firmware type. Check whether the physical machine boots BIOS/legacy or UEFI, and whether its disk uses an MBR or GPT partition table. This single detail determines whether the destination VM needs SeaBIOS or OVMF, and mismatching it is the single most common reason a freshly P2V'd machine won't boot.
- On Linux, ls /sys/firmware/efi existing means the running system booted UEFI.
- On Windows, run Get-Disk | Select PartitionStyle in PowerShell, or check msinfo32 → BIOS Mode.
Driver strategy decided up front. Decide whether you'll boot the freshly migrated VM first on emulated IDE/SATA and a standard NIC (easiest, works even without VirtIO drivers pre-installed) and switch to VirtIO afterward, or inject VirtIO drivers offline before the first boot. The step-by-step sections below cover both.

Choosing a P2V Method

There are three practical ways to get a physical disk into a Proxmox VE VM. None of them are Proxmox-specific tools — Proxmox VE has no built-in "P2V wizard" — so you're assembling the migration from generic imaging tools plus standard qm commands.

Method	Best for	Pros	Cons
Raw `dd` over `netcat`/SSH	Linux source machines, simple partition layouts, when you want a byte-exact copy	No extra tooling on the Proxmox side; fastest for mostly-full disks; simple to reason about	Copies free space too unless you truncate/sparsify; no filesystem-aware resizing; slower on very large mostly-empty disks
Clonezilla device-to-device (network clone)	Windows or Linux, when you want filesystem-aware cloning (skips free space) and a guided workflow	Only copies used blocks by default; well-tested with NTFS and most Linux filesystems; works over the network without an intermediate image file	Requires a temporary Clonezilla boot on both ends; slightly more moving parts to set up
`virt-p2v` (libguestfs)	Linux-savvy admins comfortable with libguestfs tooling, converting into an intermediate libvirt/qemu target	Purpose-built P2V tool, handles some driver adjustments automatically for common Linux distros	Does not output directly to Proxmox VE — you still import the resulting disk manually with `qm importdisk`; heavier setup for a one-off migration

This guide walks through the two most commonly used methods in detail: the dd/netcat approach, and the Clonezilla network-clone approach. Both end with the same post-migration driver and boot-fix steps.

Method A: Raw Disk Imaging with dd and netcat

This is the fastest path when you just want a bit-for-bit copy of the source disk landed directly onto a Proxmox VE block device, no intermediate image file required.

Step 1: Create the Destination Block Device on Proxmox VE

Before you image anything, allocate a raw volume on the Proxmox host sized to match (or slightly exceed) the physical disk. Pick a VMID you're not using yet — this example uses 9000.

# On the Proxmox VE host
pvesm alloc local-lvm 9000 vm-9000-disk-0 100G

For a ZFS-backed storage, the equivalent is a straightforward zfs create -V against the pool, or you can let qm create allocate the disk normally and then simply overwrite it with the incoming image in Step 3.

Confirm the resulting block device path:

lvs | grep vm-9000-disk-0
# e.g. /dev/pve/vm-9000-disk-0

Step 2: Boot the Physical Machine from Live Media

Boot the physical server from your SystemRescue or Debian/Ubuntu live USB. Once at a shell, identify the source disk:

lsblk
# confirm the disk to image, e.g. /dev/sda

If the machine has multiple disks (OS disk plus data disks), repeat this whole process per disk, allocating a matching destination volume for each.

Step 3: Stream the Disk Across the Network

On the Proxmox host, open a listener that writes directly into the destination volume:

# On the Proxmox VE host
nc -l -p 9000 | dd of=/dev/pve/vm-9000-disk-0 bs=1M status=progress

Then, on the physical machine booted into live media, push the disk across:

# On the physical source machine
dd if=/dev/sda bs=1M status=progress | nc 10.0.0.50 9000

Replace 10.0.0.50 with the Proxmox host's IP address reachable from the physical machine's live-boot network. If you'd rather not open a plaintext netcat listener on the network (reasonable in a shared or untrusted VLAN), pipe over SSH instead:

# On the physical source machine, SSH method
dd if=/dev/sda bs=1M status=progress | ssh root@10.0.0.50 "dd of=/dev/pve/vm-9000-disk-0 bs=1M"

Let this run to completion — for a full disk this can take anywhere from minutes to a few hours depending on disk size and network speed. status=progress gives you a live throughput readout so you can sanity-check it isn't stalled.

Free space caveat: dd copies every block on the source disk, including unused space, unless you specifically use a sparse-aware invocation. For a 2 TB disk that's 90% empty, this method will still transfer close to 2 TB worth of blocks over the wire. If your source disks are large and mostly empty, the Clonezilla method below (which is filesystem-aware and skips unused blocks by default) will usually be significantly faster.

Step 4: Create the VM Shell Around the Imported Disk

Once the transfer finishes, create the VM definition and attach the disk you just wrote to. Match the BIOS/UEFI setting and machine type to what you confirmed the source used:

# Legacy BIOS example (source used MBR + legacy boot)
qm create 9000 --name p2v-fileserver --memory 8192 --cores 4 \
  --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-pci \
  --bios seabios --ostype l26

qm set 9000 --scsi0 local-lvm:vm-9000-disk-0
qm set 9000 --boot order=scsi0

If the source machine booted UEFI (GPT disk), use OVMF and add an EFI disk instead:

# UEFI example (source used GPT + UEFI boot)
qm create 9000 --name p2v-fileserver --memory 8192 --cores 4 \
  --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-pci \
  --bios ovmf --machine q35 --ostype l26 \
  --efidisk0 local-lvm:1,efitype=4m,pre-enrolled-keys=1

qm set 9000 --scsi0 local-lvm:vm-9000-disk-0
qm set 9000 --boot order=scsi0

Set --ostype to win10/win11 (or the appropriate Windows type) instead of l26 if the source was Windows — this affects some QEMU default tuning, not just cosmetics.

Method B: Clonezilla Device-to-Device Network Clone

This method is a better fit when the source disk is mostly empty, when you're migrating a Windows machine and want a well-tested tool that understands NTFS, or when you'd rather work through guided menus than raw dd commands.

Step 1: Create a Normal Destination VM First

Unlike Method A, here you create a fully normal VM with an empty disk of the right size and firmware type up front — Clonezilla will write the cloned filesystem directly onto it.

qm create 9001 --name p2v-clonezilla --memory 8192 --cores 4 \
  --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-pci \
  --bios seabios --ostype l26
qm set 9001 --scsi0 local-lvm:100
qm set 9001 --boot order=scsi0

(Swap in the OVMF/EFI disk block from Method A if the source is UEFI.)

Step 2: Attach the Clonezilla Live ISO and Boot the VM Into It

Upload the Clonezilla Live ISO to a Proxmox storage that supports ISO images, attach it to the new VM as a CD-ROM, and set the boot order to boot from CD-ROM first temporarily:

qm set 9001 --cdrom local:iso/clonezilla-live-amd64.iso
qm set 9001 --boot order=ide2

Start the VM and let it boot into the Clonezilla Live environment. From the Clonezilla menu, choose the networking option that starts an SSH server or the built-in P2P clone-server mode (Clonezilla's menu wording varies slightly by release, but the option you want is the one that lets a second Clonezilla instance connect to this one over the network to send it an image). Note the IP address the VM's Clonezilla instance reports on the console.

Step 3: Boot the Physical Machine and Push the Clone

Boot the physical source machine from a Clonezilla Live USB. Choose the device-to-device (not device-to-image) workflow, select the remote/network target option, and enter the IP address and any session details the VM's Clonezilla instance is showing. Select the correct source disk on the physical machine and the correct destination disk on the far end (it will be the single virtual disk you already sized in Step 1), then start the clone.

Clonezilla clones filesystem-by-filesystem and, for supported filesystems (ext4, NTFS, XFS, and others), only copies used blocks — free space is skipped, which is usually dramatically faster than a byte-for-byte dd on disks that aren't nearly full.

When the clone finishes, power off both the physical machine and the VM cleanly from within Clonezilla before disconnecting.

Step 4: Detach the ISO and Boot the Migrated VM

qm set 9001 --delete cdrom
qm set 9001 --boot order=scsi0

The VM is now ready for its first real boot — proceed to the driver fixes below before you expect it to come up cleanly.

Fixing Drivers After the Clone: Windows

A physical Windows install almost never has VirtIO drivers loaded, because VirtIO devices didn't exist on the physical hardware. Boot straight onto a VirtIO SCSI disk and NIC and you'll typically get an INACCESSIBLE_BOOT_DEVICE blue screen. There are two ways around this:

Option 1: Boot First on Emulated Hardware (Recommended)

This is the path of least resistance for most admins:

Temporarily configure the VM's disk bus as sata0 or ide0 instead of scsi0/virtio0, and the NIC model as e1000 instead of virtio. Windows has built-in drivers for both, so it will boot without any extra driver work.
Boot the VM. Windows will go through its usual hardware-change device enumeration (new HAL/ACPI tables, new disk controller, new NIC) but should come up successfully since everything it's seeing is emulated hardware it already has inbox drivers for.
Mount the VirtIO drivers ISO (virtio-win.iso, published by the Fedora Project's VirtIO-Win project) as a second CD-ROM in the VM, and install the VirtIO guest tools package from inside Windows. This installs the storage and network drivers along with the balloon and guest agent drivers.
Shut the VM down, then switch the disk bus to scsi0 (with scsihw: virtio-scsi-pci) and the NIC model to virtio in the VM configuration.
Boot again. Windows will now detect the VirtIO storage and network controllers, find the drivers you installed in the previous step already present, and come up cleanly on the fully virtualized hardware profile.

Option 2: Offline VirtIO Driver Injection (When You Can't Boot on Emulated Hardware Either)

Occasionally a P2V'd Windows install won't even boot cleanly on emulated SATA/IDE — usually older installs with a minimal, stripped-down driver store, or images where the boot-critical storage driver itself got corrupted in transit. In that case, inject the drivers offline before the first boot:

Attach the migrated VM's disk as a secondary disk to any working Windows VM (or boot the target VM from a Windows PE / installation media in repair mode).
From that environment, mount the VirtIO ISO and run DISM against the offline Windows volume, targeting the correct architecture folder:
```
Dism /Image:D:\ /Add-Driver /Driver:"E:\viostor\w10\amd64" /Recurse
Dism /Image:D:\ /Add-Driver /Driver:"E:\NetKVM\w10\amd64" /Recurse
```
(Replace D:\ with the offline Windows volume's drive letter and E:\ with the mounted VirtIO ISO, and pick the OS-version subfolder that matches the migrated system.)
Reattach the disk to the VM as scsi0 with virtio-scsi-pci, set the NIC to virtio, and boot normally — the boot-critical storage driver is now present in the offline image before Windows ever tries to load it.

Licensing note: Windows may prompt for reactivation after a P2V migration, since the underlying hardware fingerprint (CPU, motherboard, disk controller) changes completely. This is expected. Volume-licensed and KMS-activated systems typically reactivate automatically against your KMS host; retail/OEM licenses tied to the original physical hardware may require a call to Microsoft's activation line.

Fixing Drivers After the Clone: Linux

Linux P2V migrations are usually more forgiving because most modern distributions build a broad set of storage and network drivers into their initramfs by default. Still, check these three things before you assume it "just works":

1. Confirm VirtIO Modules Are in the initramfs

Mount the migrated disk (either by booting the VM once on emulated sata0/e1000 hardware first, the same way as the Windows path, or by mounting it from a rescue environment) and check:

# Debian/Ubuntu
cat /etc/initramfs-tools/modules
# add if missing:
echo -e "virtio_blk\nvirtio_scsi\nvirtio_pci\nvirtio_net" >> /etc/initramfs-tools/modules
update-initramfs -u -k all

# RHEL/CentOS/Rocky
dracut --force --add-drivers "virtio_blk virtio_scsi virtio_pci virtio_net"

Doing this while still booted on emulated SATA/e1000 hardware, then switching the VM config to virtio-scsi-pci and a virtio NIC afterward, avoids ever needing an offline chroot.

2. Check /etc/fstab and the Bootloader for Hardcoded Device Paths

Older systems occasionally reference disks by raw device name (/dev/sda1) instead of UUID or label. Since the migrated VM's controller and bus can shift device enumeration order, hardcoded paths are the most common cause of a P2V'd Linux box dropping to an emergency shell on boot. Convert to UUID-based mounting if you find raw device paths:

blkid /dev/sda1
# then edit /etc/fstab to reference UUID=... instead of /dev/sda1

3. Remove Stale Network Interface Naming Rules

Older Debian/Ubuntu and RHEL releases persist NIC naming to a specific MAC address via udev rules (commonly /etc/udev/rules.d/70-persistent-net.rules) or via systemd's predictable naming keyed to PCI bus location. Since the VirtIO NIC has a new MAC address and a different bus path than the physical NIC it replaces, leaving this file in place can cause the interface to come up as a different name than what your network configuration expects (or not come up at all). Delete or update the stale rule, and reconcile it with whatever interface name your /etc/network/interfaces, netplan config, or NetworkManager profile expects.

4. Reinstall GRUB If the Boot Loader Fails to Find Its Root Device

If you land at a grub rescue> prompt, boot the VM from a rescue live ISO, mount the root and boot partitions, chroot in, and reinstall the bootloader against the new virtual disk:

mount /dev/sda2 /mnt
mount /dev/sda1 /mnt/boot
for d in dev proc sys; do mount --bind /$d /mnt/$d; done
chroot /mnt
grub-install /dev/sda
update-grub
exit

Troubleshooting Common P2V Boot Failures

Symptom	Likely cause	Fix
"No bootable device" / VM drops straight to a UEFI shell	Firmware mismatch — source was UEFI/GPT but VM was created with SeaBIOS, or vice versa	Recreate the VM with the matching `--bios ovmf` + `--efidisk0`, or `--bios seabios`, to match the source disk's partition scheme
Windows `INACCESSIBLE_BOOT_DEVICE` blue screen	Booting directly on VirtIO storage without the driver present	Boot once on `sata0`/`ide0`, install VirtIO guest tools, then switch to `scsi0` + `virtio-scsi-pci`
Linux drops to `(initramfs)` or an emergency shell, "cannot find root device"	VirtIO block/SCSI modules missing from initramfs	Rebuild the initramfs with `virtio_blk`/`virtio_scsi` included, ideally while still on an emulated disk bus
`grub rescue>` prompt, "unknown filesystem"	Boot loader still pointing at the old disk geometry/UUID, or GRUB itself wasn't reinstalled after the clone	Chroot in from rescue media and rerun `grub-install` + `update-grub`
VM boots but has no network connectivity	Stale udev NIC naming rule tied to the old physical MAC address, or wrong bridge/VLAN in the VM's `net0`	Remove the stale persistent-net rule and confirm `vmbr` bridge/VLAN tag matches what the guest expects
Disk appears far smaller than expected inside the guest	Partition table or LVM physical volume still reflects the original (smaller) disk geometry even though the virtual disk was sized larger	Grow the partition/PV/filesystem inside the guest after boot — P2V does not automatically resize partitions to fill a larger destination disk

Post-Migration Cleanup and Verification

Once the VM boots reliably and you've confirmed the applications on it work as expected, don't rush to decommission the physical hardware. Instead:

Run it in parallel for a few days if possible. Keep the physical machine powered off but intact (don't wipe it) until you're confident the migrated VM has been exercised under real usage — including anything that only happens weekly or monthly, like backup jobs or batch reports.
Take an immediate backup of the new VM. Once it's confirmed working, get it into your normal Proxmox Backup Server or vzdump schedule right away — it's easy to forget a freshly migrated one-off VM until something goes wrong.
Update any monitoring, DNS, or inventory records that referenced the physical machine's hostname, IP, or asset tag, since these often drift once a box becomes "the VM formerly known as that old server."
Decommission the physical hardware only after a confirmed backup exists of the new VM, not just the old physical disk. The old disk itself is your rollback plan right up until that first VM backup lands.

Frequently Asked Questions

Do I need to reinstall the OS after a P2V migration?

No — that's the entire point of P2V versus a fresh install. The existing operating system, applications, and data are cloned as-is. The only changes needed afterward are driver and boot-loader adjustments so the OS recognizes the new virtual hardware.

Can I P2V a machine while it's still running?

Not reliably. Imaging a live, mounted filesystem risks capturing an inconsistent state (open files, in-flight writes, database files mid-transaction). Always boot the source machine from live/rescue media so the disk being imaged is not mounted read-write by its own running OS.

Does Proxmox VE have a built-in P2V wizard like the ESXi Import Wizard?

No. As of Proxmox VE 9.x there is no equivalent one-click tool for physical hardware — ESXi Import Wizard and OVA import both assume the source is already virtualized. P2V is assembled from generic disk-imaging tools (dd, Clonezilla, or virt-p2v) plus standard qm commands, which is exactly what this guide walks through.

Will the migrated VM have the exact same disk size as the physical disk?

With the dd method, yes by default — it's a byte-for-byte copy, so the destination volume should be at least as large as the source. With Clonezilla, you can clone onto a differently sized destination disk, but you'll need to grow the partition/filesystem afterward to use any extra space; it won't auto-expand.

What if the physical machine has hardware RAID?

Hardware RAID is transparent to the operating system — the OS sees a single logical disk regardless of how many physical drives sit behind the RAID controller. P2V doesn't need to know or care about the RAID topology; you're imaging the logical disk exactly as the OS already sees it.

Should I match vCPU count and RAM to the physical machine's specs?

Not necessarily. Start with a reasonable allocation based on the workload's actual observed usage rather than blindly matching physical core/RAM counts, which are often oversized relative to what the application actually needs. You can always adjust CPU and memory allocation later without re-migrating anything.

Is P2V migration officially supported by Proxmox?

There's no official, Proxmox-branded P2V tool or support path — the tools involved (dd, netcat, Clonezilla, virt-p2v) are all standard, well-established, general-purpose utilities used across the broader virtualization community, not Proxmox-specific features.

Conclusion

P2V migration is more manual than any of Proxmox VE's other guest-import paths, simply because there's no export format or API to lean on — you're working directly with disks and live-boot media. But the actual mechanics are straightforward once you've done it once: image the disk across with either dd/netcat or a Clonezilla network clone, build a VM shell that matches the source's firmware type, and walk through the driver fixes so the guest can actually see its new virtual storage and network hardware. Keep the original physical disk untouched until you've confirmed a real backup of the migrated VM exists, and you have a clean, low-risk path off of aging hardware and onto Proxmox VE.

Vormox is an independent virtualization management platform built on Proxmox VE. Proxmox® and Proxmox VE® are trademarks of Proxmox Server Solutions GmbH. Vormox is not affiliated with, endorsed by, or sponsored by Proxmox.

How to Migrate a Physical Server to Proxmox VE (P2V Guide)