Re: [Xen-users] Live Migration with different hardware

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

> > Compare the output of this command on your machines:
> > cat /proc/cpuinfo|grep flags
>
> That may well be the case. The "correct" test should really be something
> like:
>
> flags_new_cpu & ~flags_old_cpu != 0
>
> That means, no flags on the old cpu that doesn't exist on the new CPU.
>
> I'm not sure how much, if any, flags are actually tested on the
> migration path.

I don't think they are.

> The good thing is that if the migration fails due to incompatible CPU's
> (by testing flags) it should not "fail" the domain - that is, the domain
> should stay on the original machine and you should get an error message
> - at least that's how I understand it.

I don't think you can rely on this happening :-(

I'm not sure what the status is of not killing the origin domain if migration 
fails.  But regardless of this, mismatched CPUs is probably still dangerous.  
If you migrate a domain to a machine missing instructions that the domain is 
using, the /migration/ will succeed just fine - the execution state will all 
be transferred and the domain will successfully start running.  So the 
control tools will want to kill the origin domain so that they don't conflict 
over disk / network access.

Unfortunately, this doesn't stop the migrated guest from crashing a few cycles 
after the migration completes due to an undefined operation :-(

It'd be nice if more flag checking was done, but AFAIK at the moment it isn't.  
There's also not a generally easy way to see if a guest is using the extra 
features on a particular CPU or not, and thus it's hard to tell if migration 
would break anything.  Trapping the CPUID instruction and faking out a "least 
common denominator" has been discussed but not (as far as I know) actually 
implemented.  If it were possible to do this then you could sacrifice some 
machine-local optimisations and trade them off for the ability to migrate 
safely and freely within a cluster.

> Yes, as long as you don't use "pci-passtrhough" to make a PCI card (e.g.
> network card) available directly to the domain, the guest DOESN'T KNOW
> what the REAL network card is [this makes the domain a driver domain,
> and driver domains aren't allowed to be migrated anyways - that would be
> TERRIBLY hard to implement, as there's no real good way to transfer the
> internal state of the hardware owned on one domain to the next one].

Domains with PCI access shouldn't be migrated or saved/restored.  I think the 
tools might allow this at the moment, but that's a bug and should be fixed 
(note to self: consider fixing this bug!)

Cheers,
mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users