Am Donnerstag, 19. Januar 2006 14:50 schrieb Mark Williamson:
> > migration is working very well for us, but you have to be carefully on
> > some aspects before trying to migrate productions domU's...
> >
> > 1) you have to use the same xen version on all xen hosts that are
> > involved in migrating... so not 32bit xen on one machine and 32bit + pae
> > or even 64bit xen on the other...
>
> Have you ever tried this? Sounds like it could be quite entertaining :-)
no, but I think it will not even be possible to migrate, because xen detects
the missmatch, but that's just a guess. I have not tried it yet :)
If you try to boot a dom0 with a pae enabled kernel on a non pae hypervisor
(for example), then xen notices that and will not boot, so maybe it's the
same for migrating.
> > 2) you should use the absoulty exact kernel, or at least doesn't optimize
> > it for another architecture or something like that The kernel have to be
> > available at the same location at every xen host.
>
> Having the kernel in the same place on every host is only important for a
> reboot though - the migration itself should be fine. The long term
> solution to this should probably be to boot a kernel off the domain
> filesystem.
My long term solution is to have the kernel images on a san too, so that for
every xen host the very same kernels are available...
but your right, as long as you don't want to reboot you wouldn't need the
kernel on the second host, I guess... But the first time I tried the
migration I tried it from the xeon -> celeron and because the domain reboots
immidently I got a error: "kernel not available/file not found" or something
like this.
> > 3) you have to use a san (or at least something that works like a san)...
> > If you want a opensource solution which doesn't cost money and want to
> > use (maybe old) standard servers for providing blockdevices to the xen
> > machines, then I can recommend gnbd (from redhat's cluster tools) for
> > exporting block devices to more then one xen host at the same time (but
> > as long as you don't use gfs as fs, you should not try to mount it more
> > than once).
>
> Yep.
I had a testsetup like this:
GNBD Server1: hdd <--> drbd <--> lvm <--> gnbd
|
| (sync via network)
|
GNBD Server2: hdd <--> drbd (<--> lvm <--> gnbd)
together with heartbeat for a failover if the master gnbd hosts fails...
I imported the gnbd devices in two xen hosts for testing live migration.
I was really impressed, it worked almost out of the box...
live migration in about 5-10 seconds with a downtime definitly <100ms. and
that statefull... xen is great ;-P
I can even turn off the gnbd master (and having heartbeat detecting that and
making the failover in under 1 sec.) and having a live migration running in
the very same moment. no problem at all... that even impressed my boss :-)
> > 4) you cannot migrate a domU from for example a xen to a celeron without
> > that the domU has to be restartet. But you can migrate the very same domU
> > from a celeron to xeon. (After you migrated it from a celeron to a xeon,
> > you will be able to migrate it back to celeron)...
> >
> > I am not quite sure why the effect from my number 4 exists. I guess
> > because the celeron has not as many instruction sets (for example mmx,
> > sse, nx, and so on) but the domU needs the same sets to keep running
> > after migrating.
>
> Linux enables more optimisations if it detects it's booting on a newer
> processor. If you boot it on something where it can use these
> optimisations and then move it to a machine where it can't, things will
> break nastily.
yeah, the domU gets restarted immidently, or at least very very fast...
> Of course if you disable this (never done it, so not sure
> how to) then it won't be an issue, at the expense of losing some efficiency
> on the more modern machines.
I really would like to know how...
We will probablly not have the very exact cpu in all xen hosts in future, so
at the moment I would need to start a domU on the "oldest" machine and
migrating it to the final host where it should run, but that is not very
elegant, but needed if you want to be sure that you can move the domU later
on to every other available host.
> The features of the Celeron are a strict subset of the Xeon, so if Linux
> boots on the Celeron it will only ever use things that the Celeron has -
> hence the behaviour you're seeing.
I already was quite sure that exactly this was the problem. But now I can be
sure, thanks...
Btw... it's the very same for a celeron and a sempron... you can migrate from
celeron to sempron, but not the otherway around (if the domain was initially
started on the sempron)...
> Out of interest for Xeon->Celeron migration did you see an immediate crash?
> Probably would be an invalid opcode exception of some kind.
no... on the target host it looks like the domain was just started... in the
moment the migration is finished the domain gets restarted...
it's to fast to have a "xm console" running on the target host... xm dmesg
doesn't show anything interessting... but I have not looked
in /var/log/xend.log... Next time I try I will check that and let you know.
> Cheers,
> Mark
--Ralph
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home