Re: [Xen-users] 2.0.7 -> 3.0.0 upgrade

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

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

> 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.

> 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.

> 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.  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.

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.

Out of interest for Xeon->Celeron migration did you see an immediate crash?  
Probably would be an invalid opcode exception of some kind.

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