Re: [libvirt] [PATCH v3 6/8] qemu: use virDomainPCIAddressIsMulti() to determine multifunction setting
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...
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.
That said, is there any reason why this code can't be moved
to the PostParse callback, so that the multifunction property
will show up in the guest configuration and the issue will be
side-stepped entirely?
--
Andrea Bolognani / Red Hat / Virtualization