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.
--
Andrea Bolognani / Red Hat / Virtualization