Dan Smith wrote:
AL> Processor revision is an artificial restriction. Just because
AL> you're going from an AMD rev F to a rev 10 doesn't mean that your
AL> application will stop working. In this particular case, it's
AL> actually pretty unlikely that it would stop working.
What I really meant was something along the lines of the "flags" field
in cpuinfo.
Okay, flags is a subset of the common cpuid features. This is not by
any means exhaustive of the features supported by a particular CPU but
it is a reasonable starting point.
Certainly you can say that it's not safe to migrate to
a processor that doesn't support a superset of the flags from the
source, right?
No, it may be safe. Consider the case where you're migrating from a
core duo to a core solo. This is the same chip with a few things
disabled including VT which will manifest as a lack of the "vmx" flag.
In this case, it's 100% safe to do the migration because a PV guest
cannot use that CPU feature.
Something a bit more tricky is the sse2 flag. Do most VMs really use
sse2? If no application in your VM is using sse2, then you should be
able to migrate from across CPUs that do not support sse2 right?
IMHO, this is not a decision you want to take away from an
administrator. Guiding them and helping them make an informed decision
is not a bad idea but just having a blind boolean isn't going to be all
that helpful.
AL> Further, there are certainly cases where an application could not
AL> just depend on a feature present in a family but in a particular
AL> model. An obvious example would be the presence of VT on core
AL> duos vs core solos (although that wouldn't be an issue for
AL> guests..).
Are you suggesting that comparing the flags would yield a false
positive?
Yes.
AL> I think it makes sense to separate hard compatibility where there
AL> *will* be an issue (Xen guests can't migrate to a KVM host)
Right, which could be enforced categorically, without increasing the
"matrix" of possibilities.
AL> and soft compatibility where there *may* be an issue (going from
AL> AMD => Intel). It would probably make sense to make soft
AL> compatibility some sort of threshold too. For instance, it's much
AL> more risky to go from an AMD rev F to a P3 than going from an AMD
AL> rev 10 to a rev F.
Wouldn't a comparison of the flags solve this though? Especially if
each driver can implement its own check... I expect native qemu quests
(i.e. not using kvm) could survive a migration across processor
families, but Xen paravirt guests certainly could not.
KVM guests all (in theory) expose a least-common subset of processor
features unless explicitly told to expose something that's specific to a
processor. Because of this, you can migrate not just across processor
families but from Intel to AMD and vice versa.
In certain circumstances, I do think a Xen PV guest could survive
migrations even across architectures.
AL> Better yet, just ignore soft compatibility altogether and let
AL> higher level tools make that decision :-)
I think the goal is to eliminate the need for every libvirt consumer
to implement the same type of checks and have each implementation be
slightly different. While it certainly won't cover all cases, it
seems like a reasonable thing to do, as long as it's not required to
perform a migration :)
Something that compared systems, and provided specific information about
potential incompatibilities would be useful. Then a higher level piece
of software could pick and choose what it cared about. A boolean
interface is only going to have one happy consumer and that's going to
be whoever decides what the policy should be :-)
Regards,
Anthony Liguori
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list