VM doesn't boot after qemu-img convert from VMDK to RAW/QCOW2

[David Leon]

I'm trying to migrate a Windows Server (2016/2019) VM from vSphere/VMWare to OpenStack (KVM-QEMU). I followed these instructions: https://platform9.com/docs/openstack/tutorials-migrate-windows-vm-vmware-kvm without success.

After downloading the VMDK file vCenter/vSphere in an Ubuntu Server with GUI installed (a server used for this purpose), I used this command:

```
~# qemu-img convert -O qcow2 win2016-copy-flat.vmdk win2016.qcow2

~# qemu-img convert -O raw win2016-copy-flat.vmdk win2016.qcow2

```

I tried with both formats, RAW and QCOW2, and after importing into my controller node that image with the next command:

```
~# openstack image create --insecure --container-format bare "win2016-raw" --disk-format raw --file /tmp/win2016.qcow2

~# openstack image create --insecure --container-format bare "win2016-qcow2" --disk-format qcow2 --file /tmp/win2016.qcow2

```

Finally, I tested creating a new instance and I obtain this error message:

Booting from Hard Disk...
Boot failed: not a bootable disk

No bootable device.

(Exactly like this issue: https://github.com/cloudbase/windows-imaging-tools/issues/324)

After googling a lot and a couple of days, I tried another way, to change the chipset of the image from i440fx to q35, also, enabling the boot menu and secure boot, like in this link: https://bugzilla.redhat.com/show_bug.cgi?id=1663212 following the documentation about the properties of images (https://docs.openstack.org/ocata/cli-reference/glance-property-keys.html).

Then, my instance continues without booting, with a different message but with the same result, something link this: https://github.com/ipxe/pipxe/issues/14 and a similar screenshot of this thread https://forums.freebsd.org/threads/i-got-error-bdsdxe-failed-to-load-boot0001-when-i-boot-kali-linux-vm-via-uefi-firmware.82773/

Also, I explored the possibility of the partition table being corrupted and I tried to repair it with `gdisk` command; with the same result. So, which other way can I test?

Context, I have my services of OpenStack running over a Ubuntu Servers cluster with 3 nodes and 1 controller, deployed with kolla-ansible over docker to have high availability, and CEPH as storage, configured with rbd (rados) to work with Glance/Cinder.

I have tested different Windows Server editions from scratch, installing the S.O. locally with KVM and VirtManager, then uploading the QCOW2 disk to OpenStack, and works fine, and other Linux distributions. But this specific scenario migrating with Windows Server from vSphere to OpenStack crashes on that point, with the bootable device.

Thank you for reading and for your time.

[sean mooney (sean-k-mooney)]

this issue is outside the scope of nova.

# qemu-img convert -O qcow2 win2016-copy-flat.vmdk win2016.qcow2

this should work provided the vmdk is not referencing a backing file or that file is locally accessabvle

qemu-img convert -O raw win2016-copy-flat.vmdk win2016.qcow

will write a raw image over the qcow created in the previous step
if you did it in that order then you would have cupproted the file effectively
this should be

qemu-img convert -O raw win2016-copy-flat.vmdk win2016.img

this would be the correct way to upload the raw file
~# openstack image create --insecure --container-format bare "win2016-raw" --disk-format raw --file /tmp/win2016.img

and this would correctly upload the qcow2
~# openstack image create --insecure --container-format bare "win2016-qcow2" --disk-format qcow2 --file /tmp/win2016.qcow

assuming that you didn't acidently override the file and this was just a typo in the bug report

what i would advice checking is how was the VM created in vshpere.

for example
https://platform9.com/docs/openstack/tutorials-migrate-windows-vm-vmware-kvm

assumes the VM is using scsi

to use the same with libvirt/kvm you would have to set hw_disk_bus=scsi as an image property.

we default to virtio-blk and its possible the windows instance you are using do not have virtio drivers if they were installed in vsphere with a scsi bus.

you might also want to set os_type=windows in the image

wether you use i440fx or q35 depend on what you are trying to achieve

if the vm was installed using secure boot then you will need uefi and that will force you to use q35 however I'm not sure if secure boot will cause issues since the nvram data is not going to be present.

changing form i440fx to q35 will not enable uefi by default you need to do that by setting
hw_firmware_type=uefi as an image property.

hw_firmware_type=uefi requires hw_machine_type=q35 to be set on the image or set in the nova.conf as the default machine type

the default in kolla and nova is to use libvirt default which is the PC machine type.

so to summarise you probably need to set
os_type=windows, hw_machine_type=q35, hw_firmware_type=uefi and hw_disk_bus=scsi

on the image if the vm was originally booted with uefi and SCSI disks on vmware.
you should also check the format fo the converted disk that you uploaded to make sure that they are the format you expect and that you did not overwrite the qcow with a raw file.

you should also check your source image to make sure that it is not a delta disk and if it is that you cal locally access the backing file of the vmdk when you are doing the conversion.

beyond that i don't think there is much more the nova project can do here as this is not a nova probelm.

[Dan Smith (danms)]

Yeah, agree this is not a valid nova issue. The qemu-img convert process is a very low-level thing, and depending on how your disk is laid out on the vmdk, it may not create an image that is usable directly. You should be testing with qemu or kvm directly to see if you can get it to boot. If you do, we might be able to help you figure out what flavor config you need to make nova configure kvm properly for it (but not in a bug).

[David Leon (davidlorius)]

Thank you so much for the help. I started to support an OpenStack implementation in Mexico since 9 months ago, and I don't understand all the organization of the community; I will try your advices.

Also, which should be the correct place for this kind of "issue"? I commented the same in the IRC channel, but this is the unique answer I got.

[Dan Smith (danms)]

Well, a vendor's support contract will be your best bet, of course. Beyond that. for community support, the mailing list is probably your best bet for actual openstack help.

But like I said, qemu, kvm, and qemu-img are not openstack tools, so you should look to those (or other) communities for support with such things. As I noted, however, qemu-img is a very low-level tool, which converts one disk format to another. That's a far cry from "turn a working VM image from vmware into a working one for kvm". It's a tool, but you will very probably need to apply more attention than just the application of that tool to make things work. A hammer can help you build a house, but it won't assemble it for you :)