Ubuntu – Add physical partition to QEMU/KVM virtual machine in virt-manager

kvmpartitioningqemuvirtualizationwindows

I followed the instructions in this answer to a related question: Add physical disk to KVM virtual machine

The resulting code in the .xml file for the VM is the following:

<disk type='block' device='disk'>
  <driver name='qemu' type='raw' cache='none'/>
  <source dev='/dev/disk/by-partuuid/d8b63353-34n6-6587-ac07-810dmf36d544'/>
  <target dev='vdb' bus='virtio'/>
  <boot order='2'/>
  <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
</disk>

Notice how I used /dev/disk/by-partuuid/d8b63353-34n6-6587-ac07-810dmf36d544 for the <source> element, instead of /dev/sda4.

What is bothering me is that my use case is to pass a partition to QEMU, instead of a disk. I installed Windows 10 on it, the Setup installer wouldn't recognize the storage so I had to load the viostor driver from the FedoraProject.

The Windows installation went fine, and the performance is amazing, but when the VM is turned off, the host system doesn't recognize the partition format.

I found it interesting that the Windows installer – with the viostor driver loaded – created the additional partitions normally required by Windows on a bare disk. In other words, it created partitions inside what's supposedly a partition. This shouldn't be possible, or so I thought.

/dev/sda4 is present in the host, but is not recognized as neither an NTFS filesystem (not expected, indeed), nor LVM, nor LDM (tested with ldmtool).

The VM is booting correctly in UEFI mode with the Q35 chipset.

Question: Is my procedure to add a partition to virt-manager correct, or should it only be done for disks – and not for partitions? Also, what partition type or format did I end up with?

Best Answer

The solution appears to be passing the whole block device, like /dev/sda or the equivalent from /dev/disk/by-id/, to the <source dev=''> setting.

This allows the Windows setup to see the existing partitions, including the root partition in the host.

There should not be any conflict, as long as:

  • you don't try to mount/modify a partition in the guest that is already mounted in the host; and

  • you don't mount/modify the partition currently in used by the guest from the host, while the VM is powered on.

Regarding the first point, it is of course necessary to unmount the ESP (EFI System Partition) from the host prior to launching the VM. I first wrote a script for that, and then came up with a better solution in the form of a QEMU automation hook. I'm making available at https://gitlab.com/ranolfi/rvirtesp.

What's cool about this is that you can also boot the virtualized OS natively, as in dual-booting, by selecting its new entry in the motherboard's boot menu.

I'm not exactly sure this is "supported". But been using it for almost a year now, without a problem.