Living guide · v1.2.9

Windows 11 → Proxmox

A physical-to-virtual migration workflow with explicit stop checks, rollback points, VHDX verification, and an optional EliteDesk 800 G3 / Intel HD 530 physical-console path.

36 steps8 phasesProxmox VE 9.2Offline-friendly
0 / 36 steps

Before you start

IMPORTANT: Use two different external devices. The migration drive keeps this guide, saved state, and the VHDX. The Proxmox installer USB is separate and will be erased.

WORKFLOW: Do everything in Windows on the source PC. Use the second PC only after Proxmox is installed.

RECOMMENDED STORAGE: Install Proxmox on a second internal SSD/NVMe and leave the original Windows drive intact. This gives you a firmware-level fallback/dual-boot path and avoids erasing the original Windows installation.

SAVE STATE: After every step, click Export saved state. Save it to the migration drive. After STEP 017, save it on the second PC.

Guide workspace values (saved only on this device)

Enter values as you discover them. Matching placeholders in commands and checks update automatically in this browser.

Local only: workspace values, step progress, and scratchpad notes are stored in this browser's local cache. Import and Export read or write a JSON file entirely on your device. Nothing is uploaded to JMGRIT.

Export creates a portable .json backup containing only this guide's local values, completed steps, and scratchpad notes.

Required hardware

What you need

PART 01

Source PC

  • Windows 11 Pro x86-64 PC.
  • UEFI/GPT required for this guide.
  • Hardware virtualization available.
  • Wired Ethernet.
  • Strongly recommended: second internal SSD/NVMe large enough for Proxmox and the imported Windows VM. Keeping the original Windows disk intact provides a firmware-level fallback/dual-boot path and avoids erasing it.
PART 02

Migration drive

  • External USB SSD/HDD large enough for the VHDX.
  • Holds the guide, saved state, and VHDX.
  • NTFS or exFAT.
  • Never used as the Proxmox installer.
PART 03

Proxmox installer USB

  • Separate 8 GB+ USB flash drive.
  • Erased when the Proxmox ISO is written.
  • Must not be the migration drive.
PART 04

Second PC

  • On the same LAN.
  • Used only after Proxmox is installed.
  • Opens this guide and the Proxmox web UI.
PART 05

Wired network

  • Ethernet cable and router/switch port.
PART 06

Local console

  • Monitor, keyboard, and mouse for firmware and Proxmox installation.

Architecture

Architecture

BEFORE
Source Windows 11 PC
  ├── guide + saved state → migration drive
  └── VHDX               → migration drive

SEPARATE DEVICE
Proxmox installer USB → erased and used only for installation

AFTER — RECOMMENDED TWO-DISK LAYOUT
Original Windows SSD/NVMe ── left intact for firmware boot-menu fallback
Second SSD/NVMe ──────────── Proxmox VE 9.2
Second PC ──HTTPS───────────> Proxmox VE 9.2
                               └── Windows 11 VM
                          ├── OVMF / UEFI
                          ├── TPM 2.0
                          ├── VirtIO SCSI
                          ├── VirtIO NIC
                          └── QEMU Guest Agent

Network

LAN:        {{NETWORK_CIDR}}
Gateway:    {{DEFAULT_GATEWAY}}
DHCP pool:  {{DHCP_START}} - {{DHCP_END}}
Proxmox:    {{PROXMOX_IP_CIDR}}
Windows VM: {{WINDOWS_VM_IP}}

Proxmox and Windows must use different IP addresses.

Storage

Original Windows disk
  → left intact on the recommended two-disk path

Windows volume
  → Disk2vhd
  → migration-drive VHDX
  → SHA-256 verified again on Proxmox
  → qm importdisk
  → secondary Proxmox disk / local-lvm
  → VirtIO SCSI boot

Keep the VHDX until a tested Proxmox backup exists. On the recommended two-disk path, also keep the original Windows disk untouched until the VM and backup have both been tested.

PHASE 0 · 1 step

Start on the source PC

STEP 000Put the guide on the migration drive

DO: On the source PC:

  1. Plug in the external migration drive.
  2. Copy the documentation ZIP to it.
  3. Extract the ZIP on the migration drive.
  4. Open p2v-windows-11\docs\index.html.
  5. Keep the ZIP as a fallback copy.

STOP CHECK: The guide is open from the migration drive.

SAVE STATE: Export saved state to the migration drive.

PHASE 1 · 2 steps

Record the source PC

STEP 001Make sure a local admin works

DO: If you already have a local administrator with a known password, use it and skip the commands below.

Otherwise open Terminal (Admin) and run:

net user P2VAdmin * /add
net localgroup Administrators P2VAdmin /add

Sign out once. Confirm P2VAdmin can sign in. Then return to your normal account.

STOP CHECK: A local administrator with a known password works.

SAVE STATE: Export saved state to the migration drive.

STEP 002Record the PC name and network

DO: Open PowerShell and run:

$o = ipconfig /all | Out-String
$o
$o | Set-Clipboard
Source network configuration — optional local scratchpad

STOP CHECK: The source hostname, IPv4 address, gateway, and subnet are detected.

SAVE STATE: Export saved state to the migration drive.

PHASE 2 · 7 steps

Prepare Windows

STEP 003Update and back up Windows

DO:

  1. Finish Windows Update.
  2. Reboot if requested.
  3. Back up anything important to storage other than the internal disk.

STOP CHECK: Windows is updated and important files are backed up.

SAVE STATE: Export saved state to the migration drive.

STEP 004Check Windows, activation, and firmware

DO:

  1. Open Settings → System → Activation.
  2. Confirm the edition is Windows 11 Pro and Windows is activated.
  3. If activation uses a digital license, recommended: confirm it is linked to your Microsoft account before the P2V. If you use a product key instead, make sure you know how you will reactivate Windows after the virtual hardware change.
  4. Run:
$o = Get-ComputerInfo | Select WindowsProductName,WindowsVersion,OsBuildNumber,OsArchitecture,BiosFirmwareType,CsManufacturer,CsModel | Format-List | Out-String
$d = Get-Partition -DriveLetter C | Get-Disk | Select Number,FriendlyName,PartitionStyle | Format-List | Out-String
$o = $o + "`r`n" + $d
$o
$o | Set-Clipboard
Windows and firmware — optional local scratchpad

STOP CHECK: Windows 11 Pro is activated, UEFI is detected, and the Windows system disk uses GPT. If you rely on a digital license, it is linked to your Microsoft account or you have another known reactivation method.

SAVE STATE: Export saved state to the migration drive.

STEP 005Decrypt BitLocker

DO: Run:

manage-bde -status C:

If C: is encrypted, run Terminal (Admin):

manage-bde -off C:

Wait until C: shows Fully Decrypted / 0%.

STOP CHECK: C: is fully decrypted.

SAVE STATE: Export saved state to the migration drive.

STEP 006Clean Windows

DO:

  1. Settings → System → Storage → Temporary files → remove what you do not need.
  2. Run Terminal (Admin):
powercfg /h off
DISM /Online /Cleanup-Image /StartComponentCleanup

STOP CHECK: Cleanup is complete and hibernation is off.

SAVE STATE: Export saved state to the migration drive.

STEP 007Shrink C:

DO: Run:

$p = Get-Partition -DriveLetter C
$s = Get-PartitionSupportedSize -DriveLetter C
$v = Get-Volume C
$o = @(
  "CurrentPartitionGB=$([math]::Round($p.Size / 1GB,1))"
  "MinimumSupportedGB=$([math]::Ceiling($s.SizeMin / 1GB))"
  "UsedGB=$([math]::Round(($v.Size-$v.SizeRemaining) / 1GB,1))"
  "FreeGB=$([math]::Round($v.SizeRemaining / 1GB,1))"
) -join "`n"
$o
$o | Set-Clipboard
C: sizing — optional local scratchpad

C: target

Open diskmgmt.msc → right-click C: → Shrink Volume → enter {{WINDOWS_SHRINK_AMOUNT_MB}} MB.

Do not change EFI or Recovery partitions.

STOP CHECK: C: is smaller and Windows still has comfortable free space.

SAVE STATE: Export saved state to the migration drive.

STEP 008Install VirtIO drivers

DO: Mount the VirtIO Windows ISO. Enter its drive letter.

VirtIO ISO

Run:

{{VIRTIO_ISO_DRIVE}}\virtio-win-guest-tools.exe

Then run Terminal (Admin):

pnputil /add-driver {{VIRTIO_ISO_DRIVE}}\vioscsi\w11\amd64\*.inf /subdirs
pnputil /add-driver {{VIRTIO_ISO_DRIVE}}\NetKVM\w11\amd64\*.inf /subdirs

STOP CHECK: VirtIO guest tools, storage driver, and network driver are installed/staged.

SAVE STATE: Export saved state to the migration drive.

STEP 009Final Windows check

DO: Reboot. Sign in normally. Open Device Manager and check for unexpected errors.

STOP CHECK: Windows boots normally.

SAVE STATE: Export saved state to the migration drive.

PHASE 3 · 4 steps

Create the VHDX

STEP 010Choose the Proxmox IP

DO: Open your router's DHCP settings. Enter the DHCP range and choose a free Proxmox address outside it.

Proxmox network

STOP CHECK: {{PROXMOX_IP}} is free, inside {{NETWORK_CIDR}}, and outside the DHCP range.

SAVE STATE: Export saved state to the migration drive.

STEP 011Confirm the migration drive

DO: Keep the migration drive plugged into the source PC. Enter its drive letter.

VHDX destination

The VHDX name is the source hostname in uppercase:

{{VHDX_WINDOWS_PATH}}

STOP CHECK: The path is the migration-drive root, for example E:\SOURCE-PC.vhdx.

SAVE STATE: Export saved state to the migration drive.

STEP 012Create the VHDX

DO: Open Disk2vhd as Administrator.

  1. Select the Windows disk's EFI/System, C:, and Recovery volumes.
  2. Check Use Vhdx.
  3. Save to {{VHDX_WINDOWS_PATH}}.
  4. Click Create.

If Volume Shadow Copy makes Disk2vhd crash, turn it off, close other apps, and run the capture again.

STOP CHECK: {{VHDX_WINDOWS_PATH}} exists and has a plausible size.

SAVE STATE: Export saved state to the migration drive.

STEP 013Hash the VHDX

DO: Run:

$o = Get-FileHash '{{VHDX_WINDOWS_PATH}}' -Algorithm SHA256 | Format-List Algorithm,Hash,Path | Out-String
$o
$o | Set-Clipboard
VHDX SHA-256 — optional local scratchpad

STOP CHECK: The VHDX path and SHA-256 are saved.

SAVE STATE: Export saved state to the migration drive.

PHASE 4 · 6 steps

Install Proxmox VE 9.2

STEP 014Create the Proxmox installer USB

DO: On the source PC:

  1. Plug in a second USB flash drive.
  2. Download the Proxmox VE 9.2 ISO.
  3. Use Rufus or another ISO writer to write the ISO to the installer USB.
  4. Do not select the migration drive.

STOP CHECK: The installer USB and migration drive are different devices.

SAVE STATE: Export saved state to the migration drive.

STEP 015Prepare the Proxmox target and boot installer

DO:

  1. Export saved state one more time.
  2. Safely eject and unplug the migration drive.
  3. Choose the Proxmox target-disk path:
    • Recommended — lowest data-loss risk: shut down the PC, install a second internal SSD/NVMe large enough for Proxmox and the imported Windows VM, and leave the original Windows drive intact. For the safest install, temporarily disconnect the original Windows drive while Proxmox is being installed.
    • Single-disk fallback: reuse the original Windows disk only if you accept that it will be erased and your VHDX plus important-file backup are already safe on other storage.
  4. Leave only the Proxmox installer USB attached externally.
  5. Reboot into UEFI/BIOS.
  6. Enable CPU virtualization if needed.
  7. Boot the Proxmox installer USB.

STOP CHECK: The Proxmox installer starts, the migration drive is unplugged, and you know exactly which internal disk will receive Proxmox.

SAVE STATE: Already exported before reboot.

STEP 016Install Proxmox

DO: Install Proxmox VE 9.2 to the selected target disk.

Recommended two-disk path: select the new secondary SSD/NVMe. Do not select or format the original Windows disk.

Single-disk fallback: selecting the original Windows disk will erase the physical Windows installation.

Use:

Hostname:  {{PROXMOX_HOSTNAME}}
Address:   {{PROXMOX_IP_CIDR}}
Gateway:   {{DEFAULT_GATEWAY}}
DNS:       {{PRIMARY_DNS}}

WARNING: The disk selected in the Proxmox installer will be erased.

After installation:

  1. Remove the installer USB and boot Proxmox.
  2. If you temporarily disconnected the original Windows drive, shut Proxmox down, reconnect that drive, and keep the Proxmox disk first in firmware boot order.
  3. Boot Proxmox again. The untouched Windows disk can remain available as a firmware boot-menu fallback. Do not add, format, or modify that physical Windows disk from Proxmox during this migration.

STOP CHECK: The console shows https://{{PROXMOX_IP}}:8006/. On the recommended two-disk path, the original Windows drive is still intact and Proxmox boots from the secondary SSD/NVMe.

SAVE STATE: Complete this after reopening the guide in STEP 017.

STEP 017Move to the second PC

DO: Now use the second PC for the first time.

  1. Plug the migration drive into the second PC.
  2. Copy the extracted documentation folder to the second PC.
  3. Open docs\index.html from that local copy.
  4. Click Import saved state and load the latest JSON from the migration drive.
  5. Open https://{{PROXMOX_IP}}:8006/ and sign in as root.

STOP CHECK: The guide and Proxmox web UI are open on the second PC.

SAVE STATE: Export saved state on the second PC.

STEP 018Check Proxmox and VM storage

DO: In Node → Shell, run:

pveversion
ip -4 addr show vmbr0
pvesm status

In Datacenter → Storage, confirm local-lvm exists and has enough free space for the imported Windows disk. Do not delete or resize the default Proxmox storage for this migration.

STOP CHECK: Proxmox is 9.2.x, vmbr0 has {{PROXMOX_IP_CIDR}}, local-lvm is active, and it has enough free space for the Windows VM.

SAVE STATE: Export saved state on the second PC.

STEP 019Confirm the Windows fallback disk

DO: Confirm your rollback path before importing Windows.

If you used the recommended second SSD/NVMe, run:

lsblk -o NAME,SIZE,MODEL,FSTYPE,MOUNTPOINTS

Identify:

  • the disk that contains Proxmox;
  • the untouched original Windows disk.

Leave the original Windows disk alone. It is your physical fallback and can be selected from the PC's firmware boot menu if you need to return to the original installation.

If you used the single-disk path, the physical Windows installation has already been erased; your rollback path is the migration-drive VHDX plus your separate file backup.

STOP CHECK: You can clearly identify your Proxmox disk and your rollback path. On the recommended two-disk path, the original Windows disk has not been modified.

SAVE STATE: Export saved state on the second PC.

PHASE 5 · 4 steps

Import Windows

STEP 020Mount and verify the migration VHDX

DO:

  1. Export saved state on the second PC.
  2. Copy the documentation folder with saved state from the migration drive to the second PC local disk.
  3. Safely eject the migration drive from the second PC.
  4. Plug it into the Proxmox PC.
  5. In Node → Shell, run:
lsblk -f

Enter the migration-drive partition, for example sdb1.

Migration drive on Proxmox

Mount it and find the VHDX:

mkdir -p /mnt/p2v
mount /dev/{{PVE_EXTERNAL_PARTITION}} /mnt/p2v
find /mnt/p2v -maxdepth 2 -type f -iname '*.vhdx'

VHDX on Proxmox

Before importing the disk, verify the copy that Proxmox can actually read:

sha256sum '{{PVE_VHDX_PATH}}'

Compare that value with the SHA-256 saved in STEP 013:

{{VHDX_SHA256}}

HARD STOP: If the hashes do not match exactly, do not import the VHDX. Recheck the selected file and migration drive first.

STOP CHECK: {{PVE_VHDX_PATH}} points to the expected VHDX and its SHA-256 matches {{VHDX_SHA256}}.

SAVE STATE: Export saved state on the second PC.

STEP 021Create the Windows VM

DO: In Proxmox click Create VM.

Use:

  • OS: Do not use any media
  • Machine: q35
  • BIOS: OVMF (UEFI)
  • EFI Disk: local-lvm + Pre-Enrolled Keys
  • TPM: 2.0 on local-lvm
  • SCSI Controller: VirtIO SCSI single
  • CPU: host
  • Network: VirtIO on vmbr0
  • QEMU Guest Agent: enabled

Remove the placeholder disk. Do not start the VM.

Windows VM

STOP CHECK: The empty VM exists with OVMF, TPM 2.0, VirtIO NIC, and VirtIO SCSI.

SAVE STATE: Export saved state on the second PC.

STEP 022Import the VHDX

DO: In Node → Shell, run:

qm importdisk {{VM_ID}} '{{PVE_VHDX_PATH}}' local-lvm

Wait for 100% and a successful import message.

STOP CHECK: The Windows disk appears under the VM as Unused Disk.

SAVE STATE: Export saved state on the second PC.

STEP 023Attach the disk and boot Windows

DO:

  1. VM → Hardware → Unused Disk → Edit/Add → attach as SCSI0.
  2. Put SCSI0 first in Boot Order.
  3. Start the VM.
  4. Open Console and sign in.

If Windows does not boot on SCSI, attach the Windows disk as SATA, boot once, add a small temporary SCSI disk, then move the Windows disk back to SCSI0.

STOP CHECK: Windows boots from SCSI0.

SAVE STATE: Export saved state on the second PC.

PHASE 6 · 4 steps

Finish and back up

STEP 024Check VirtIO and Guest Agent

DO: In the Windows VM, confirm:

  • VirtIO network works.
  • Windows disk is on VirtIO SCSI.
  • QEMU Guest Agent service is running.

STOP CHECK: Network, storage, and Guest Agent work.

SAVE STATE: Export saved state on the second PC.

STEP 025Check the Windows VM network

DO: In the Windows VM console, run:

ipconfig

Enter the VM IPv4 address below.

Windows VM

STOP CHECK: Windows and Proxmox have different IP addresses and both are reachable from the second PC.

SAVE STATE: Export saved state on the second PC.

STEP 026Remove the temporary admin and finish Windows

DO:

  1. Sign in with your normal Windows account.
  2. Confirm it works and has the access you expect.
  3. Run Windows Update.
  4. Check Settings → System → Activation. If Windows is no longer activated, use Troubleshoot → I changed hardware on this device recently with the Microsoft account linked in STEP 004, or enter the valid product key for this Windows license.
  5. Check Device Manager.

If you created P2VAdmin in STEP 001, open Terminal (Admin) and remove it:

net user P2VAdmin /delete

Do not remove an administrator account that existed before this guide.

STOP CHECK: Windows works normally, activation is confirmed or its reactivation path is known, and the temporary P2VAdmin account is removed if this guide created it.

SAVE STATE: Export saved state on the second PC.

STEP 027Back up the VM

DO: Create a full Proxmox backup to storage outside the internal system disk.

Keep the original VHDX until the backup is tested.

Final record:

Item Value
Source PC {{SOURCE_COMPUTER_NAME}}
Source Windows {{WINDOWS_PRODUCT_NAME}} build {{WINDOWS_BUILD}}
Firmware {{SOURCE_BIOS_MODE}}
Proxmox {{PROXMOX_HOSTNAME}} · {{PROXMOX_IP_CIDR}}
VM {{VM_ID}} · {{VM_NAME}}
VM IP {{WINDOWS_VM_IP}}
VHDX {{VHDX_WINDOWS_PATH}}
VHDX SHA-256 {{VHDX_SHA256}}

STOP CHECK: A tested external VM backup exists and the original VHDX is still available.

SAVE STATE: Export the final saved state on the second PC.

PHASE 7 · 8 steps

Optional: EliteDesk 800 G3 / Intel HD 530 physical console

STEP 028Prove remote access and save rollback

DO: From the second PC:

  1. Open https://{{PROXMOX_IP}}:8006 and confirm the Proxmox Web UI loads.
  2. Open PowerShell and run:
ssh root@{{PROXMOX_IP}}
  1. After SSH connects, run:
hostname
qm status {{VM_ID}}
  1. Keep this SSH window open.
  2. Shut down the Windows VM cleanly.
  3. In SSH, save the current VM configuration:
qm stop {{VM_ID}}
qm config {{VM_ID}} | tee /root/vm-{{VM_ID}}-before-igd.txt
cp /etc/pve/qemu-server/{{VM_ID}}.conf /root/{{VM_ID}}.conf.before-igd

STOP CHECK: The Web UI works from the second PC, SSH is connected and still available, the VM is stopped, and /root/{{VM_ID}}.conf.before-igd exists.

SAVE STATE: Export saved state on the second PC.

STEP 029Verify IOMMU and identify the HD 530

DO: In the open Proxmox SSH session, run:

dmesg | grep -Ei 'DMAR|IOMMU'
lspci -nnk | grep -A4 -Ei 'VGA compatible controller|Display controller'
pvesh get /nodes/$(hostname)/hardware/pci --pci-class-blacklist ""
grep -R "disable_vga=1" /etc/modprobe.d /etc/default/grub 2>/dev/null || true

Find the Intel HD Graphics 530 / Skylake entry. Record its full PCI address and vendor:device ID. Do not assume the address, even though 0000:00:02.0 is common.

Intel iGPU

Check its IOMMU group:

readlink -f /sys/bus/pci/devices/{{IGPU_PCI}}/iommu_group
ls -l /sys/bus/pci/devices/{{IGPU_PCI}}/iommu_group/devices

On Proxmox VE 9, do not add old intel_iommu=on instructions by default. If no DMAR/IOMMU is active, stop and enable Intel VT-d in the EliteDesk firmware first.

If the grep command finds disable_vga=1, stop and remove that setting before continuing; it conflicts with legacy IGD passthrough.

STOP CHECK: IOMMU is active, {{IGPU_PCI}} is the Intel HD 530, its IOMMU group is acceptable, and disable_vga=1 is not configured.

SAVE STATE: Export saved state on the second PC.

STEP 030Get the Skylake IGD ROM

DO: This ZIP does not bundle third-party Intel firmware. On the second PC, open the community project below and use its release/checksum information:

https://github.com/LongQT-sea/intel-igpu-passthru

For the EliteDesk 800 G3 / Skylake HD 530, use:

SKL_CML_GOPv9_igd.rom

Universal_noGOP_igd.rom is a last-resort fallback, not the normal Skylake choice.

Rename the selected Skylake ROM to igd.rom, then copy it to Proxmox:

scp .\igd.rom root@{{PROXMOX_IP}}:/usr/share/kvm/igd.rom

Back in SSH, verify the file and compare its SHA-256 with the checksum published by the ROM project's release page:

ls -lh /usr/share/kvm/igd.rom
sha256sum /usr/share/kvm/igd.rom

STOP CHECK: /usr/share/kvm/igd.rom is the Skylake SKL_CML_GOPv9_igd.rom file and its checksum matches the project's published checksum.

SAVE STATE: Export saved state on the second PC.

STEP 031Switch the VM to legacy Intel IGD mode

DO: This guide created the VM as q35 in STEP 021. QEMU legacy IGD requires the i440fx machine family, IGD at guest 00:02.0, no competing virtual VGA device, and a valid ROM.

Configure the stopped VM:

qm stop {{VM_ID}}
qm set {{VM_ID}} --machine pc
qm set {{VM_ID}} --vga none
qm set {{VM_ID}} --bios ovmf
qm set {{VM_ID}} --hostpci0 {{IGPU_PCI}},legacy-igd=1,romfile=igd.rom
qm config {{VM_ID}}

Do not add pcie=1 to the legacy IGD device.

Do not blacklist i915 yet. Current Proxmox/iGPU guidance does not require the old blanket VFIO preparation for this path; blacklist i915 is kept only as a troubleshooting fallback if it is actually needed.

The original q35 configuration is preserved in /root/{{VM_ID}}.conf.before-igd.

STOP CHECK: qm config {{VM_ID}} shows machine: pc, bios: ovmf, vga: none, and hostpci0 with legacy-igd=1,romfile=igd.rom.

SAVE STATE: Export saved state on the second PC.

STEP 032Test the iGPU before changing host drivers

DO: Connect a monitor to an onboard EliteDesk DisplayPort and start Windows from SSH:

qm start {{VM_ID}}

Watch the physical monitor. With the recommended GOP ROM, display output may appear early in VM startup. If Windows loads before the display appears, wait for the Intel graphics driver to initialize.

From SSH, confirm the VM remains running:

qm status {{VM_ID}}

At this point, do not blacklist i915 just because the host driver is present. If the physical display works, leave the host configuration alone.

If the VM immediately fails to start, Windows reports Code 43, or the DisplayPort remains black after Windows should be loaded, go to STEP 035 for diagnostics before changing host-driver binding.

When the display test is complete, shut the VM down from SSH before assigning the physical USB ports:

qm shutdown {{VM_ID}}

STOP CHECK: The iGPU passthrough starts without requiring a permanent i915 blacklist, or you have captured the failure and will use STEP 035.

SAVE STATE: Export saved state on the second PC.

STEP 033Pass through only the keyboard and mouse USB ports

DO: Keep the keyboard and mouse connected to the two EliteDesk USB ports you want Windows to own. In SSH, run:

lsusb
lsusb -t

Unplug and reconnect one device at a time to identify the physical port path for each port, such as 1-3 or 1-3.2.

Physical USB ports

Assign only those ports:

qm set {{VM_ID}} --usb0 host={{USB_KEYBOARD_PORT}}
qm set {{VM_ID}} --usb1 host={{USB_MOUSE_PORT}}
qm config {{VM_ID}}

This leaves the rest of the EliteDesk USB controller available to Proxmox.

STOP CHECK: qm config {{VM_ID}} shows only the selected keyboard and mouse physical USB ports under usb0 and usb1.

SAVE STATE: Export saved state on the second PC.

STEP 034Verify the physical Windows console

DO: Start the VM from SSH:

qm start {{VM_ID}}

Then confirm:

  1. Windows appears on the onboard EliteDesk DisplayPort.
  2. The keyboard and mouse work when connected to the two selected physical USB ports.
  3. Device Manager → Display adapters shows Intel HD Graphics 530 without Code 43.
  4. If Windows uses Microsoft Basic Display Adapter, install the appropriate Intel graphics driver or let Windows Update supply it, then reboot the VM.
  5. The Proxmox built-in VM console can be blank because vga: none is intentional.

If one onboard DisplayPort remains black after Windows finishes loading, test the other onboard DisplayPort before changing the VM configuration.

STOP CHECK: The Windows desktop is visible on the EliteDesk DisplayPort, Intel HD 530 has no Code 43, and the selected physical keyboard/mouse ports control the VM.

SAVE STATE: Export saved state on the second PC.

STEP 035Diagnose, use the VFIO fallback only if needed, or recover

DO: If the VM will not boot correctly, Windows shows Code 43, the physical display stays black, or the iGPU is unreliable, stay on the second PC and use SSH.

First collect diagnostics:

qm status {{VM_ID}}
qm config {{VM_ID}}
lspci -nnk -s {{IGPU_PCI}}
journalctl -b | grep -Ei 'vfio|IOMMU|DMAR|i915'

Optional VFIO/i915 fallback

Use this only after the normal legacy-IGD configuration has failed or the iGPU project guidance indicates the host i915 driver is preventing reliable output/resolution. This will usually remove the Proxmox host's local video console after reboot.

qm stop {{VM_ID}}
cat >/etc/modules-load.d/p2v-igd-vfio.conf <<'EOF'
vfio
vfio_iommu_type1
vfio_pci
EOF

cat >/etc/modprobe.d/p2v-igd-vfio.conf <<'EOF'
blacklist i915
options vfio-pci ids={{IGPU_PCI_ID}}
EOF

update-initramfs -u -k all
reboot

After Proxmox returns, reconnect with SSH and verify:

lspci -nnk -s {{IGPU_PCI}}

If you used the fallback, Kernel driver in use: vfio-pci is expected. Retry the VM.

Restore the original VM and host iGPU

To return the VM to its pre-passthrough q35 configuration and remove the optional host-driver fallback:

qm stop {{VM_ID}}
cp /root/{{VM_ID}}.conf.before-igd /etc/pve/qemu-server/{{VM_ID}}.conf
rm -f /etc/modprobe.d/p2v-igd-vfio.conf
rm -f /etc/modules-load.d/p2v-igd-vfio.conf
update-initramfs -u -k all
reboot

After reboot, verify the original VM configuration is restored. If you used the VFIO fallback, lspci -nnk -s {{IGPU_PCI}} should show i915 again when the host reclaims the iGPU.

STOP CHECK: Either the physical-console passthrough works, or the original q35 VM configuration and normal Proxmox iGPU ownership have been restored.

SAVE STATE: Export the final saved state on the second PC.

Sources

  • Disk2vhd — Microsoft Sysinternals: https://learn.microsoft.com/sysinternals/downloads/disk2vhd
  • Windows activation after a hardware change — Microsoft Support: https://support.microsoft.com/windows/activation/reactivating-windows-after-a-hardware-change
  • Proxmox VE documentation / administration guide — Proxmox: https://pve.proxmox.com/pve-docs/
  • Proxmox VE downloads — Proxmox: https://www.proxmox.com/en/downloads/proxmox-virtual-environment
  • VirtIO Windows drivers — Fedora/Red Hat VirtIO Windows: https://github.com/virtio-win/virtio-win-pkg-scripts
  • QEMU Guest Agent — Proxmox documentation: https://pve.proxmox.com/pve-docs/
  • QEMU Intel IGD assignment / legacy mode requirements — QEMU: https://gitlab.com/qemu-project/qemu/-/blob/master/docs/igd-assign.txt
  • Intel iGPU passthrough ROM guidance and checksums — LongQT-sea: https://github.com/LongQT-sea/intel-igpu-passthru