HyperV to PVE migration - Windows VM boot issues - local-lvm disk vs shared disk

[ikalafat]

Hi everyone,

I am in the process of migrating several HyperV VMs to PVE, and I have encountered weird behavior and Windows Server (2019 in my case) VM boot issues, depending on the storage where the VM disk is imported.

On PVE instance, I have several disks

- local-lvm
- shared storage (SAN-backed, thick LVM disk)
- SMB shared disk (for pulling the VHDXs)

When I migrate the VM/VHDx with the following command

qm importdisk <vmid> /mnt/pve/hv/<path-to-vhdx>.vhdx local-lvm
with output similar to ..
  Logical volume "vm-145-disk-1" created.
Logical volume pve/vm-145-disk-1 changed.
and progress..

the VM boots normally (after attaching the disk to SATA controller etc)

When i migrate the VM/VHDx to different/shared/SAN-backed storage

qm importdisk <vmid> /mnt/pve/hv/<path-to-vhdx>.vhdx san-vol01
with output similar to
Wiping PMBR signature on /dev/vg_san_vol03/vm-145-disk-2.
Logical volume "vm-145-disk-2" created.

and progress..

i get boot errors (Access denied to Windows Boot Manager). If i disable Secure boot, then I'm getting the
0xc0000428 ("Windows cannot verify the digital signature for this file") exception

I have also observed the following:
- after successfully booting the VM from local-lvm disks, I have migrated the disk storage with the VM being shut down - boot issues appeared
- after reverting to source disks (local-lvm) - VM boots normally
- after migrating the disk storage (again), but this time with VM running - no boot issues, even after shutdown and cold boot.

I have thought that the Wiping of PMBR signature could be the issue, however when migrating the disk (online) from local-lvm to san, i have following output

create full clone of drive scsi0 (local-lvm:vm-145-disk-0)
Wiping PMBR signature on /dev/vg_san_vol03/vm-145-disk-1.
Logical volume "vm-145-disk-1" created.

With progress (etc), and in this case the VM works as intended, so i am lost.

What can I do to prevent/avoid these boot issues without the extra step of migrating to local-lvm disks before migrating to shared disk?
FWIW: I am pretty sure that I managed to migrate 2-3 other Windows VMs directly to SAN volume without issues like this.
Running PVE 9.0.10 with all updates.

Thank you.

 

[bbgeek17]

Hi @ikalafat, welcome to the forum.


My suspicion is that in the failure cases, the underlying disk was not properly erased, allowing the VM’s OS to read residual or invalid data. After a few conversions, the VM disk was likely thick-provisioned, the blocks overwritten, and the issue effectively “masked.”

I know there is ongoing work to improve behavior in this area, though I’m not aware of its current status.

Cheers

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox