Re: Proposal PCI/PCIe device placement on PAPR guests

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/12/2017 05:31 AM, Andrea Bolognani wrote:
On Mon, 2017-01-09 at 10:46 +1100, David Gibson wrote:
    * To allow for hotplugged devices, libvirt should also add a number
      of additional, empty vPHBs (the PAPR spec allows for hotplug of
      PHBs, but this is not yet implemented in qemu).

"A number" here will have to mean "one", same number of
empty PCIe Root Ports libvirt will add to a newly-defined
q35 guest.

Umm.. why?

Because some applications using libvirt would inevitably
start relying on the fact that such spare PHBs are
available, locking us into providing at least the same
number forever. In other words, increasing the amount at
a later time is always possible, but decreasing it isn't.
We did the same when we started automatically adding PCIe
Root Ports to q35 machines.

The rationale is that having a single spare hotpluggable
slot is extremely convenient for basic usage, eg. a simple
guest created by someone who's not necessarily very
familiar with virtualization; on the other hand, if you
are actually deploying in production you ought to conduct
proper capacity planning and figure out in advance how
many devices you're likely to need to hotplug throughout
the guest's life.

And of course the reason we don't want to add "too many" extra controllers by default is so that we don't end up with *all* guests burdened with extra hardware they don't need or want. The libguestfs appliance is one example of a libvirt consumer that definitely doesn't want extra baggage in its guests - guest startup time is very important to libguestfs, so any addition to the hardware list is looked upon with disappointment.


Of course this all will be moot once we can hotplug PHBs :)

Will the guest OSes handle that properly? I remember being told that Linux, for example, doesn't scan the new bus for devices when a new controller is added, making it pointless to hotplug a PCI controller (as usual, it could be that I'm remembering incorrectly...)

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux