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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list