Several months ago I had a client that was migrating from ESXi to Proxmox. I was unable to rebuild some of their servers due to them being older Windows servers that were definitely out of support. Note that I don’t recommend running in this configuration but these machines are air-gapped and are being upgraded over time as the equipment they support is being replaced.

Initially, I tried to import the VMs into Proxmox by way of the web interface but there was severe latency. Something to the order of 2-3Mbps and then it would eventually time out. After some research it was discovered that exports with this particular version of ESXi were single threaded. The only path forward was to (slowly) export the VMs from ESXi and then manually import them into Proxmox.

This was easy enough initially. I took the images from ESXi and converted them to a more appropriate format using qemu-img: qemu-img convert -p -f vmdk -O raw disk-0.vmdk disk-0.img I could then import them into an exsiting VM that I configured in the web interface: qm importdisk 101 /root/incoming/unifi/disk-0.img local-lvm -format raw

At this point, I figured I’d be able to simply start the VM and have it run but I was very wrong. The VM simply refused to boot and refused to recognize that it had any disks at all. I started by fetching the Windows Server 2019 installation media and used diskpart to locate and assign a letter to the disk. After that I was able to use bootrec to rebuild the boot configuration of the disk with the following commands:

bootrec /fixmbr
bootrec /fixboot
bootrec /scanos
bootrec /rebuildbcd

I was still having boot issues so the next step was to create a new BCD store, replacing the old one that didn’t seem to be functional:

ren C:\Boot\BCD BCD.old
bcdboot C:\Windows /s C: /f ALL

After this, I ran all of my bootrec commands again to (hopefully) ensure that the boot configuration was correct but I ended upw ith an “Access is denied” error when I ran bootrec /fixboot. To get around this, I tried to use bcdboot directly again, working my way in circles. However, it managed to successfully create the boot files this time. I am still confused as to why this happened. I am writing this based on my notes so it’s possible that I missed a step in my frustration.

Stepping through the rest of the bootrec commands again eventually landed me in a situation where windows was convinced my disk was not a fixed MBR disk and I thought this might be an EFI issue. After heavy use of searching Kagi, old Microsoft Technet articles, and ServerFault, I used bcdedit to manually recreate the BCD store after some enumeration with diskpart:

diskpart              # i used list disk, select disk, and list partition here
select partition 1
assign letter=S
exit

bcdboot C:\Windows /s S: /f UEFI

cd /d S:\EFI\Microsoft\Boot\
bcdedit /createstore BCD
bcdedit /store BCD /create {bootmgr} /d "Windows Boot Manager"
bcdedit /store BCD /set {bootmgr} device partition=S:
bcdedit /store BCD /create {default} /d "Windows Server 2019"
bcdedit /store BCD /set {default} device partition=C:
bcdedit /store BCD /set {default} osdevice partition=C:
bcdedit /store BCD /set {default} path \Windows\system32\winload.efi
bcdedit /store BCD /set {bootmgr} default {default}

bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum

From here I ran exit on the command window and stopped the VM in the Proxmox web interface. I went back into the VM configuration and set the BIOS setting in the hardare tab to “OVMF (UEFI)” and verified that the hard disk was in the correct boot order. I also detached the Windows ISO from the machine and started the VM back up.

This resolved the issue for me on the VMs I had that only used a single disk but I had other issues with VMs that had multiple disks. For those, I had to inject the VirtIO drivers offline with dism but those steps will be a post for another day. I need to better organize my notes and write it up.