[Libvir] Re: Next features and target for development
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.