> > > 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 :)
The tools *might* disallow a migration, I've never checked. I hope they
do :-D
> 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.
It's a slightly different mechanism since dom0 is a special case.
> 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.
Yep, it'd be because of the immediate reboot showing the lack of kernel file,
without the crash / reboot, you'd have been fine.
> 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 :-)
Now *that's* a cool demo :-)
> > 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)...
Could be the use of AMD specific instructions. For instance, the AMD supports
all the Celeron's media instructions, but the Celeron doesn't have 3DNow.
The software RAID checksumming code uses these. I guess the memcpy
implementation *might* use them if available (???). There are also various
other optimisations the kernel uses, depending on what system it boots on.
> > 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...
Yep, that's what I meant.
You may find that selecting your processor to be something like "Pentium
Pro" (or anything that implements a subset of what you have!) will be enough
to make Linux behave right, but without having tried it I can't be certain.
Bear in mind that even if you start virtual machines on the CPU with least
capabilities you'll still find that once they've rebooted they can't migrate
back there. It's best to try and keep your cluster as homogenous as
possible.
Cheers,
Mark
> 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
--
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