Bug 1326420

Any more context on this?

Bumping the priority of this.

We're currently actively reducing the devices we build for qemu-kvm-rhev and have now lost the ability to manage our guests on ARM with libvirt, because libvirt expects certain PCI bridges to be available. Here's the error you get when attempting a virt-install

ERROR    unsupported configuration: the dmi-to-pci-bridge (i82801b11-bridge) controller is not supported in this QEMU binary

We need to determine what's necessary for the AArch64 build in order to support PCIe and PCIe hotplug, and then also make sure libvirt (bug 1244151) only adds those devices/bridges by default.

(In reply to Andrew Jones from comment #2)
> Bumping the priority of this.
> 
> We're currently actively reducing the devices we build for qemu-kvm-rhev and
> have now lost the ability to manage our guests on ARM with libvirt, because
> libvirt expects certain PCI bridges to be available. Here's the error you
> get when attempting a virt-install
> 
> ERROR    unsupported configuration: the dmi-to-pci-bridge (i82801b11-bridge)
> controller is not supported in this QEMU binary
> 
> We need to determine what's necessary for the AArch64 build in order to
> support PCIe and PCIe hotplug, and then also make sure libvirt (bug 1244151)
> only adds those devices/bridges by default.

What parameters you used in virt-install? I want to reproduce it myself.

(In reply to Wei Huang from comment #3)
> What parameters you used in virt-install? I want to reproduce it myself.

virt-install -n rhelsa -l $PATH_TO_REPO --vcpus=4 --memory 4096 --disk size=6 --network default --boot uefi

Since RHELSA 7.2, we have been pretty strict about the supported devices. Going forward we want to keep the same rule, in the meanwhile we also want to expand the scope of supported devices to cover new features (e.g. hotplug). 

So I expand the scope of this BZ to cover the following two items:
* add necessary devices to qemu to support new features
* trim the devices we don't want to make sure the list is as minimal as possible

-Wei

Fix included in qemu-kvm-rhev-2.6.0-5.el7

Um. Maybe not? I'm seeing the following whenever I try to create a new domain:

ERROR    unsupported configuration: the dmi-to-pci-bridge (i82801b11-bridge) controller is not supported in this QEMU binary

[root@mustang ~]# virt-install --name rhelsa72_test1 --location "http://kickstart.bos.jonmasters.org/rhelsa/latest/Server/aarch64/os/" --vcpus=2 --memory 2048 --disk size=10 --network default --boot uefi

Starting install...
Retrieving file vmlinuz...                               |  11 MB     00:00 !!! 
Retrieving file initrd.img...                            |  61 MB     00:01 !!! 
Allocating 'rhelsa72_test1-2.qcow2'                      |  10 GB     00:00     
ERROR    unsupported configuration: the dmi-to-pci-bridge (i82801b11-bridge) controller is not supported in this QEMU binary
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
  virsh --connect qemu:///system start rhelsa72_test1
otherwise, please restart your installation.

You removed the arm-softmmu inclusion in the aarch64 default-config via a patch you're carrying in qemu-kvm-rhev, which means that i82801b11-bridge isn't included (but it is if you build upstream). I've got a scratch build going that re-adds it.

https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=11189510

Created attachment 1168560 [details]
kvm-Add-i82801b11-bridge-device-for-AArch64.patch

(In reply to Jon Masters from comment #10)
> You removed the arm-softmmu inclusion in the aarch64 default-config via a
> patch you're carrying in qemu-kvm-rhev, which means that i82801b11-bridge
> isn't included (but it is if you build upstream). I've got a scratch build
> going that re-adds it.

We don't want it. We need to patch libvirt, not qemu.

The problem you're seeing is a known issue, caused by the
fact that libvirt insists on adding the dmi-to-pci-bridge
and pci-bridge to each and every mach-virt guest.

We're working on lifting that restriction[1]; after doing
so, everything will work without adding any more devices
to our QEMU configuration.


[1] https://www.redhat.com/archives/libvir-list/2016-June/msg01017.html