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