P2V Done Right: Moving a Live Windows Server into Proxmox

Consolidating a rented Windows VPS onto your own Proxmox VE host is a classic physical-to-virtual (P2V) migration. The machine you manage over RDP becomes a KVM guest you control from the Proxmox API and web UI. Done carefully, the Windows installation, its roles, and its data move across intact. Done carelessly, you get an unbootable disk and a licensing headache. This guide walks the safe path, with the RDP/PowerShell steps you'll actually run on the source.

Understand what you're moving

You are not reinstalling Windows. You are capturing the exact state of the source disk and presenting it to new virtual hardware. The two things most likely to break are the storage controller driver (Windows won't boot if it can't see its own system disk) and the firmware mode (BIOS vs. UEFI must match the original). Plan for both before you start.

Check the firmware and disk layout first

Over RDP, open PowerShell as administrator on the source and confirm how Windows boots:

Confirm-SecureBootUEFI
Get-Disk | Select-Object Number, PartitionStyle, Size

If PartitionStyle is GPT and the firmware is UEFI, your Proxmox VM must use OVMF (UEFI) with an EFI disk. If it's MBR, use the default SeaBIOS. Getting this wrong is the single most common reason a migrated Windows disk shows a blinking cursor instead of booting.

Capture the running system with Disk2vhd

Because the source is a live server you reach only over RDP, the cleanest capture tool is Sysinternals Disk2vhd. It uses Volume Shadow Copy, so you can image the system volume while Windows is running. Download it on the source, then from an elevated prompt:

disk2vhd.exe C: D:\win-migrate.vhdx

Include every volume Windows needs to boot — typically the small system/EFI partition and C:. Write the output to a different drive than the one you're capturing, and prefer the .vhdx format. If possible, quiesce or stop heavy services (SQL Server, IIS app pools) during the capture to get a cleaner, more consistent image.

Move the image and import the disk

Copy the .vhdx to your Proxmox host over SCP, SMB, or any file transfer you trust. On the Proxmox node, create an empty VM shell in the web UI (no OS disk yet) matching the firmware mode you identified, and note its VMID. Then import the captured disk from the host shell:

qm importdisk 100 /root/win-migrate.vhdx local-lvm

Proxmox can import vhdx, vmdk, vhd, and raw images directly. If you'd rather convert first, qemu-img handles it:

qemu-img convert -f vhdx -O qcow2 win-migrate.vhdx win-migrate.qcow2

Attach the disk the way Windows expects

Fresh Windows installations don't ship with the VirtIO SCSI driver, so if you attach the imported disk as virtio-scsi straight away, it won't boot. Attach it first on a controller Windows already has a driver for — SATA or IDE:

qm set 100 --sata0 local-lvm:vm-100-disk-0
qm set 100 --boot order=sata0

You'll switch to high-performance VirtIO once the drivers are in place.

Boot, then install VirtIO drivers

Download the virtio-win ISO (the official Fedora-signed build) and attach it as a CD-ROM to the VM. Also add a VirtIO network interface now, even though Windows can't use it yet. Start the VM and open its console from the Proxmox UI.

On first boot Windows will detect the new virtual hardware and reconfigure. Once you're at the desktop, run the virtio-win-guest-tools installer from the mounted ISO. This installs the storage, network, and balloon drivers plus the QEMU guest agent in one pass. Enable the guest agent on the VM so Proxmox can report the IP and trigger clean shutdowns:

qm set 100 --agent enabled=1

Switch the system disk to VirtIO

With the drivers present, shut the VM down and move the boot disk onto the fast paravirtualized controller:

qm set 100 --scsi0 local-lvm:vm-100-disk-0 --scsihw virtio-scsi-single
qm set 100 --boot order=scsi0
qm set 100 --delete sata0

Boot again. Windows should come up on virtio-scsi with the VirtIO NIC working. Reassign a static IP inside Windows to match your new network, since the old adapter's configuration won't carry over to the new virtual card.

Clean up and verify

• Remove old agents. Uninstall any hypervisor or cloud tools from the source provider (VMware Tools, cloud-init agents, backup clients) — they're useless and may interfere.
• Re-activate Windows. A hardware change often de-activates Windows and Office. Have your license key ready, or re-run activation once the VM is stable.
• Trim leftover devices. In Device Manager, show hidden devices and remove the ghosted NICs and controllers from the old platform.
• Test the services. Confirm RDP still answers on the new IP, then check IIS, SQL, or whatever roles the box runs.

Keep the original VPS powered on but idle until you've confirmed the Proxmox VM works end to end. Treat the first successful boot as a checkpoint: take a Proxmox snapshot before you change anything else, so you always have a clean restore point if post-migration tuning goes sideways.