[Libvir] Re: Next features and target for development

[Anthony Liguori]

Dan Smith wrote:
> DL> This question comes up in other contexts than migration, too, for
> DL> example, when you want to start an image you just downloaded. I
> DL> think it would make sense if there was a common baseline in
> DL> libvirt that could tell you if a VM has any chance of running at
> DL> all - otherwise that logic will be scattered across lots of apps.
> 
> The migration case is significantly more strict, though, at least for
> Xen.  A domain image may start up on two machines that are different,
> but the same domain would not migrate from one to the other.
> 
> On that note, how about a libvirt function that allows you to compare
> the capabilities of two hypervisors for varying levels of
> compatibility?  A given implementation such as Xen could analyze the
> hypervisor and machine characteristics to provide a "compatible for
> migration" result, as well as a "can run on" result (and perhaps
> others).  Something like the following:
> 
>   virIsCompatible(hyp1, hyp2, COMPAT_MIGRATION);
>   virIsCompatible(hyp1, hyp3, COMPAT_MIGRATION | COMPAT_RUN);


> The former would return true (in the Xen case) only if both machines
> were the same bitness, processor revision, etc.

Processor revision is an artificial restriction.  Just because you're 
going from an AMD rev F to a rev 10 doesn't mean that your application 
will stop working.  In this particular case, it's actually pretty 
unlikely that it would stop working.

Further, there are certainly cases where an application could not just 
depend on a feature present in a family but in a particular model.  An 
obvious example would be the presence of VT on core duos vs core solos 
(although that wouldn't be an issue for guests..).

I think it makes sense to separate hard compatibility where there *will* 
be an issue (Xen guests can't migrate to a KVM host) and soft 
compatibility where there *may* be an issue (going from AMD => Intel). 
It would probably make sense to make soft compatibility some sort of 
threshold too.  For instance, it's much more risky to go from an AMD rev 
F to a P3 than going from an AMD rev 10 to a rev F.

Better yet, just ignore soft compatibility altogether and let higher 
level tools make that decision :-)

Regards,

Anthony Liguori


> The latter could, potentially, return true for a given domain across
> Xen and qemu, if that domain is fully-virtualized.
> 
>