Hello, I see that as part of libvirt's documentation [0] the q35 machine type will feature at most 1 hotplugged PCIe device - default - and users must prepare in advance according to their expectations of how many ifaces will be hotplugged: """ Slots on the pcie-root controller do not support hotplug, so the device will be hotplugged into the pcie-root-port controller. If you plan to hotplug more than a single PCI Express device, you should add a suitable number of pcie-root-port controllers when defining the guest: for example, add ```xml <controller type='pci' model='pcie-root'/> <controller type='pci' model='pcie-root-port'/> <controller type='pci' model='pcie-root-port'/> <controller type='pci' model='pcie-root-port'/> ``` if you expect to hotplug up to three PCI Express devices, either emulated or assigned from the host. """ Is there any alternative to this ? For our use case, I'm considering mimicking Openstack's implementation - [1] - and expose a knob that indicates what is the number of PCIe root ports to be used upon the domain definition. I wonder how open would the community be to having a machine type alias that would provide a "better" default - in the sense that it would have more root port controllers. [0] - https://libvirt.org/pci-hotplug.html#x86_64-q35 [1] - https://blueprints.launchpad.net/nova/+spec/configure-amount-of-pcie-ports -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20220112/3a0fc43b/attachment.htm>
On Wed, Jan 12, 2022 at 12:37:12PM +0100, Miguel Duarte de Mora Barroso wrote:> For our use case, I'm considering mimicking Openstack's implementation - > [1] - and expose a knob that indicates what is the number of PCIe root > ports to be used upon the domain definition. > > I wonder how open would the community be to having a machine type alias > that would provide a "better" default - in the sense that it would have > more root port controllers.The problem with this suggestion is that the definition of "better" varies depending on who you ask :) There is no one-size-fits-all solution. libvirt follows the "mechanism, not policy" principle: the mechanism is already available, as documented in the page you were quoting, and the policy is better implemented in your application. OpenStack is a good example to follow in this regard. -- Andrea Bolognani / Red Hat / Virtualization