[Libvir] Re: Next features and target for development

Anthony Liguori anthony at codemonkey.ws
Wed Jul 11 03:59:54 UTC 2007


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




More information about the libvir-list mailing list