On 10/10/2016 05:27 AM, Andrea Bolognani wrote:
On Fri, 2016-10-07 at 12:11 -0400, Laine Stump wrote:
So instead of guaranteeing that there will always be an empty
slot available for hotplug during a single start/destroy
cycle of the guest, we would be guaranteeing that there will
be 3/4 empty slots available for either hotplug or coldplug
throughout the entire life of the guest.
A better way to put it is that we guarantee there will be "N" (3 or 4 or
whatever) slots available when the domain is originally defined. Once
any change has been made, all bets are off.
Okay, your alternative reading matches with my understanding
of your proposal :)
Sounds like a pretty good compromise to me.
The only problem I can think of is that there might be
management applications that add eg. a pcie-root in the XML
when first defining a guest, and after the change such guests
would get zero hotpluggable ports. Then again it's probably
okay to expect such management applications to add the
necessary number of pcie-root-ports themselves.
Yeah, if they know enough to be adding a root-port, then they know
enough to add extras.
Note that I wrote pcie-root, not pcie-root-port.
Maybe we could relax the wording on A) and ignore any
pci{,e}-root? Even though there is really no reason for
either a user or a management application to add them
explicitly when defining a guest, I feel like they might be
special enough to deserve an exception.
I thought about that; I'm not sure. In the case of libguestfs, even if
Rich added a pcie-root, I guess he would still be manually addressing
his pci devices, so that would be clue enough that he knew what he was
doing and didn't want any extra.
Yeah, I'm not sure about that either, I just felt like it
would be good to think about it. I don't really see problems
going one way or the other, and I guess your initial
proposal is slightly more strict, so we might as well go for
it and relax it later if a compelling use case is found.
I implemented this over the weekend, and it turns out that it's much
less disruptive to ignore whether the pcie-root controller was added by
the user or by libvirt. This is because pcie-root is added much earlier
(when we are adding the implicit/default devices for the domain), so by
the time we get to the function that assigns PCI addresses (which is
where we auto-add all the additional PCI controllers) we no longer have
any information about whether pcie-root was specified in the XML, or if
it was auto-added.
The way I have it implemented now is to add the extra controllers if the
initial controller count was <= 1 *and* any new PCI controllers were
auto-added during address assignment (which implies that an unaddressed
device needed an address, so we added a controller to satisfy it). I
suppose if I want to be pedantic, I need to actually keep track of
whether or not there were any unaddressed devices (in the case that the
only devices they requested were primary video + USB2 + SATA controller,
no new PCI controllers would be added).
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list