Migrating WindowsVM from qemu to incus. Can't find hard drive?

Incus
,
1

I’m trying to import a legacy Window7 Professional x64 Virtual Machine (runs a legacy application) on a KVM/qemu server to an incus 6.0.1-LTS server.

The KVM/Qemu VM has a qcow2 file for a hard drive. The XML for it is

<devices>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/path/to/file.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>
 ...
</devices>

I found some discussions about importing: Importing VM to Incus

Docs: How to import VMs to Incus

It seems like I have choices of

  • Original format: qemu/qcow or raw
  • io.bus: nvme, virtio-blk, virtio-scsi
  • security.csm: true/false
  • security.secureboot: true/false
  • using bin.linux.incus-migrate.x86_64 to migrate from server 1-> 2 or copying over the file and using incus-migrate

I’ve been trying many many many different combinations but none have worked.

What I’ve tried:

  • bin.linux.incus-migrate.x86_64 from the qemu server to the incus server with and without UEFI and by specifying io.bus:

With

config:
  security.csm: true
  security.secureboot: false
...
devices:
  root:
    path: /
    pool: incusp1
    type: disk

I get

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

If I try the same bin.linux.incus-migrate.x86_64 with

config:
  security.csm: false
  security.secureboot: false
...
devices:
  root:
    #virtio-blk, virtio-scsi, nvme all tried for io.bus
    io.bus:  virtio-blk
    path: /
    pool: incusp1
    type: disk

I get

BdsDxe: failed to load Boot0001 "UEFI Misc Device" from PciRoot (0x0/Pci (0x1, 0x5)/Pci (0x0,0x0): Not found.

or if changing io.bus to virtio-scsi

BdsDxe: failed to load Boot0001 "UEFI QEMU QEMU HARDDISK" from PciRoot (0x0/Pci (0x1, 0x1)/Pci (0x0,0x0)/Scsi (0x0,0x1): Not found.

If I try

  • incus-migrate on the incus server with the raw file converted
    qemu-img convert -O raw myVM.qemu ./myVM.raw

with

  io.bus=virtio-blk
  security.csm=true
  security.secureboot=false

It forces one into system recovery with access to drive “X:” but no access to any hard drives

the command
X:> bootrec /scanos
finds no Windows installations
the command
X:>bootrec /fixmbr
says “The system cannot find the path specified”

the command
X:> diskpart
DISKPART> list disk
gives
“There are no fixed disks to show”

With
io.bus=virtio-blk
security.csm=false
security.secureboot=false

You get the same “failed to load the Boot001” error as above.

I created a Windows Repair file but I’m not sure if I should (or how) I’d create it as an incus mount if that would help.

Everything works great on the old qemu/kvm server, but the migrated machine won’t boot and/or find the migrated drive.

Any advice would be welcome.

Thanks!

2

Okay, so you did do the right steps:

  • qemu-img convert from qcow2 to raw
  • incus-migrate to import raw
  • set io.bus on root disk to be virtio-blk

That should get you about as close to the libvirt config as you’re going to get.
I’m actually surprised that this doesn’t straight up work. It may be an issue with the disk identifier having changed maybe? Kinda hard to tell.

What I’d suggest if you can easily access the source VM is boot it back up and install the latest virtio drivers Index of /groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.248-1

I’d just run the installer and let it install all drivers. If installing manually, make sure you have the scsi and blk drivers. On modern Windows, I’d recommend going the NVME route as that usually doesn’t require special drivers, but Windows 7 is probably a bit old for that.

3

I’ll give that a shot.

I’m not finding any signatures or hashes for the files at Index of /groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.248-1

or at GitHub - virtio-win/kvm-guest-drivers-windows: Windows paravirtualized drivers for QEMU\KVM

Are they not releasing signed/hashed stuff or am I missing something?

4

Apparently not… the drivers should be signed though.

5

The .exe reported “Only Windows 10 or newer is supported” unfortunately.

Is the reason I can’t take a virtualized disk from a qemu/kvm VM system and just load it into incus is that the “KVM is a Type 1 hypervisor” and Incus is type 2? ( How to run an Incus VM inside an Incus VM (nested virtualization) – Mi blog lah! , What's the difference between Type 1 vs. Type 2 hypervisor? | TechTarget )

Do people run kvm/qemu VMs and incus containers on the same server?

6

Incus uses KVM and is type-1, it’s using the exact same software stack as something like libvirt (QEMU driving KVM).

7

QEMU is both a hypervisor (Type 2) and emulator. In the case of Incus, only the emulator part of QEMU is used.

Incus uses KVM for the hypervisor task. KVM is a Type 1 hypervisor.

Therefore, Incus uses KVM as a hypervisor (Type 1) and QEMU specifically for the emulator task.