1. Download Disk2vhd or run it straight from \\live.sysinternals.com\tools\disk2vhd.exe.

2. As administrator: tick Use Vhdx and Use Volume Shadow Copy, select every volume on the system disk (including the System Reserved or EFI System Partition), pick a destination on another disk or a network share, and Create.

3. From the command line (the whole disk, handy for scripts):

   1	disk2vhd * D:\p2v\server01.vhdx

   disk2vhd /? shows the switches equivalent to the checkboxes in the current version.

Result: one .vhdx per physical disk, bootable on Hyper-V and convertible for Proxmox/KVM.

What it does

Disk2vhd (Sysinternals, version 2.02 from 2021) takes a Volume Shadow Copy snapshot of the volumes you tick and dumps it into a VHD or VHDX. That is why it runs on a live system: the copy is consistent as of the snapshot even though the server keeps writing. It preserves the disk’s partition table (MBR or GPT) and copies only the data of the selected volumes, so you can take the system and leave a data disk behind.

It runs on Vista/Server 2008 and later, x86 and x64.

Before creating the image

• Space: the VHDX is dynamic and grows to the size of the used data. The destination should be on another disk; on the same disk you are converting it works, but slowly.
• BitLocker off on the volumes to convert, fully decrypted. Disk2vhd does not support encrypted volumes.
• Hibernation off (powercfg /h off): hiberfil.sys weighs as much as the RAM and is useless in the VM.
• Hardware tools out: RAID utilities, NIC teaming, vendor agents; in the VM they only get in the way.
• Drivers for the target: if you are going to KVM/Proxmox, install the virtio-win drivers on the physical machine first (the virtio-win-guest-tools installer). Windows only boots on new hardware if it already has the disk controller driver; if you cannot install them beforehand, boot the VM on SATA/IDE and switch to virtio later.
• Dynamic disks: convert to basic first. Disk2vhd copies them, but booting from LDM on another machine is a source of trouble.

Booting the image

Hyper-V

On first boot Windows detects the new hardware and installs what it has; the Integration Services fill in the rest.

Proxmox / KVM

1
2
3
4
5
6

qm create 120 --name server01 --memory 8192 --cores 4 --net0 virtio,bridge=vmbr0 --ostype win11
qm disk import 120 /mnt/p2v/server01.vhdx local-lvm            # qemu-img converts the VHDX
qm set 120 --sata0 local-lvm:vm-120-disk-0 --boot order=sata0   # first boot without depending on virtio
qm set 120 --bios ovmf --efidisk0 local-lvm:1                   # only if the source was GPT/UEFI
qm set 120 --cpu x86-64-v2-AES                                  # do not use "host" with Windows
qm start 120

Once it boots, install virtio-win, shut down, switch the disk to virtio0 or scsi0 with virtio-scsi, and boot again. The host CPU is slow with Windows; that post explains why x86-64-v2-AES.

If it does not boot

Windows usually recovers the boot from the installation ISO: Repair your computer → Command Prompt:

1
2
3

bootrec /fixmbr
bootrec /fixboot
bcdboot C:\Windows

On UEFI, bcdboot C:\Windows /s S: /f UEFI with the ESP mounted as S: (diskpart → select disk 0, list partition, select partition 1, assign letter=S).

Traps

• Do not mount the VHDX on the source machine if you plan to boot it: Windows changes its disk signature to avoid a clash with the original, and the BCD, which references disks by signature, stops finding the boot disk. It is the most important warning in the documentation.
• Two identical machines on the network: the VM is a clone with the same name, SID, and IP. Do not power both on at the same time on the same network, and if it is a domain member, decide which one stays.
• Activation: the hardware change triggers reactivation; OEM licenses are not transferable to a VM under Microsoft’s terms.
• The 127 GB limit the documentation mentions is Virtual PC’s; Hyper-V and KVM do not have it (VHDX goes up to 64 TB).
• Linux is not converted with this; there it is dd, Clonezilla, or qemu-img over the disk.

See also

• Windows slow on Proxmox with CPU host
• cloud-init templates on Proxmox — the opposite path: new VMs from an image