[Libvir] Re: Next features and target for development

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. 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? 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? 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. 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 :) -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms(a)us.ibm.com