[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[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 :-)


Anthony Liguori

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]