[libvirt] [PATCH v3 6/8] qemu: use virDomainPCIAddressIsMulti() to determine multifunction setting

[Daniel P. Berrange]

On Tue, Dec 20, 2016 at 04:19:35PM +0100, Andrea Bolognani wrote:
> On Mon, 2016-12-19 at 10:23 -0500, Laine Stump wrote:
> > If the multifunction attribute isn't set in the config for the device
> > at function 0 of a slot used for multifunction, it would previously
> > have been an error. This patch will instead automatically correct the
> > omission (but only if it hasn't been set at all - if someone
> > explicitly has "multifunction='off'" on function 0, or
> > "multifunction='on'" when function != 0, we have to assume they have a
> > reason for that).
> > 
> > This effectively obsoletes the requirement of specifying
> > multifunction='on' in the config, although you're still free to do
> > so. Note that if you migrate a domain that needs an implied
> > "multifunction='on'" back to any older libvirt that doesn't have it,
> > the migration will fail. (Note that this would only be an issue with a
> > domain config that was *created* on a newer libvirt; any config
> > created on an older libvirt and then later migrated to a newer libvirt
> > would necessarily have multifunction explicitly set in the config, and
> > that will not be lost during migration).
> 
> I keep forgetting our official stance on migrating to older
> libvirt versions...

We need to be able to migrate new -> old, as apps like oVirt and
OpenStack can be running a mix of old & new libvirt & QEMU versions
and may migrate between the two in both directions. 

> As far as I'm concerned, the only reason you would want to do
> that is because you are upgrading your hypervisor pool and,
> at some point during the process, you realize there are issues
> with the upgrade and need to roll back. As you mention, that
> use case would work just fine because the guests have been
> defined using an older libvirt versions.

If you have 1000's of hypervisor nodes deployed, upgrading all
of them may take a non-trivial amount of time (days, or even
weeks). During this time you may need to use live migration
and so the possible target host may be running new or old
libvirt / QEMU - particularly during early stages of a rolling
upgrade the majority of nodes will be old libvirt.  Hence it
is not uncommon to need to migrate old to new

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|