| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
Re: [Xen-users] Live Migration with different hardware
> > 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
|
|
|
| |
|
Home