I’ve gotten most of the way though setting up PCI passthrough but stuck at setting up the storage pool for the VM…
This is what I get when trying to create it:
Error creating pool: Could not build storage pool: Storage pool already built: Format of device '/dev/sda' does not match the expected format 'unknown', forced overwrite is necessary
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 88, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/createpool.py", line 446, in _async_pool_create
poolobj = self._pool.install(create=True, meter=meter, build=build)
File "/usr/share/virt-manager/virtinst/storage.py", line 544, in install
RuntimeError: Could not build storage pool: Storage pool already built: Format of device '/dev/sda' does not match the expected format 'unknown', forced overwrite is necessary
I’ve already tried formatting the /dev/sda device to unallocated (no partitions) & cleared/Unknown. I’ve re-created the table as GPT.
I’ve tried running virt-manager with sudo - no luck.
At this moment, the drive is mounted via virt-manager and fully functional but I’m pretty sure if I reboot, it will fail to re-mount (it has once already anyway).
If possible, I’d like to verify that it will in fact be re-mounting automatically at startup before rebooting the host as I don’t want to have to format the drive and start over.
Storage Pools in Virtual Machine Manager
Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x2fb0da7b
Device Boot Start End Sectors Size Id Type
/dev/sda1 63 467668214 467668152 223G 83 Linux
As for the virt-manager config stuff, this is the only info I’ve been able to gather on my own (practically zero experience with command line kvm/qemu stuff):
:/etc/libvirt/storage$ sudo cat SPCC.xml
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
virsh pool-edit SPCC
or other application using the libvirt API.
Which doesn’t seem to totally line up with the virsh pool-edit SPCC contents:
If you want to pass through a raw disk device, you don’t create a storage pool. Storage pools store images.
In the storage selection step, select “Select or create custom storage”, then type /dev/sda in the entry field. Click Forward.
Actually, it’s better if you don’t use the /dev/sd* entries for this, use the link to the device in the /dev/disk/by-id directory. This way, if the name of the device changes (because you plugged in a usb drive or whatever), it’ll still work.
It is peculiar you say that given that there is a "Physical Disk Device" option:
But since it doesn’t seem fully functional I’m happy to oblige. I did locate the full by-id path: /dev/disk/by-id/ata-SPCC_Solid_State_Disk_0043000140 which I tried adding as described but failed to boot.
Just to test locally I removed the existing vdisk and tried adding it as recommended. I turned off and removed the old storage pool as seen by virt-manager.
All the disk by-id entries
:~$ ls -l /dev/disk/by-id/
lrwxrwxrwx 1 root root 9 Jan 31 13:48 ata-Kingston_SHPM2280P2_240G_50026B727200513E -> ../../sdb
lrwxrwxrwx 1 root root 10 Jan 31 13:48 ata-Kingston_SHPM2280P2_240G_50026B727200513E-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Jan 31 13:48 ata-Kingston_SHPM2280P2_240G_50026B727200513E-part2 -> ../../sdb2
lrwxrwxrwx 1 root root 10 Jan 31 13:48 ata-Kingston_SHPM2280P2_240G_50026B727200513E-part3 -> ../../sdb3
lrwxrwxrwx 1 root root 9 Jan 31 13:48 ata-SPCC_Solid_State_Disk_0043000140 -> ../../sda
lrwxrwxrwx 1 root root 10 Feb 2 23:50 ata-SPCC_Solid_State_Disk_0043000140-part1 -> ../../sda1
This one appears to work as described /dev/disk/by-id/ata-SPCC_Solid_State_Disk_0043000140-part1 would be the alternative.
Works locally, going to test rebooting with auto-start of the VM. Works perfectly. Thanks a bunch!
I’m noticing less than bare metal for sure however. Entirely separate issue but on bare metal, the 390x could handle tomb raider maxed out no problem. Can’t quite get there with PCI pass-through.
You can try passing through a HDD of the Win10 bare metal install instead. I have a R9 390 passed through with almost bare metal performance. Only when I did my setup like this, did I have close to bare metal performance.
To pass through the HDD using virt manager, just go about creating a VM like normal, creating a qcow2 image to get you through the VM creation process. Once you are able to edit the VM afterwards, delete the qcow2 image then head to add hardware to pass through your HDD, which should work without requiring you to create a storage pool.
*I suggest you install your windows to bare metal while having you other OS drives disconnected do that it doesn’t mess with the boot-loader.