[Libvir] Re: Next features and target for development

[Dan Smith]

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 at us.ibm.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070710/8b88dc1f/attachment-0001.sig>