Am Donnerstag, 19. Januar 2006 16:42 schrieb Mark Williamson:
> > > > 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.
and that will not be the only problem...
I made a small console tool for our customers, so that they can start/halt,
reboot, and console to their domainU by their own (working on xen2&3 at the
moment). The customers simply start a ssh shell to the xen host (dom0) and
after logging in a small menu gets shown where they can choose what they want
to do. It's important to keep this "mangament console" safe, because the ssh
user who logs in has to get sudo right on "xm". if the console is not safe it
is possible to stop other domains... :)
But this is working very good for us at the moment (even if it's more a hack
than a solid solution), but in future this will get definitly a problem. If
domUs will get migrated, then this will not work anymore. The customer
doesn't know on which host his domain should run. And if he login in to the
wrong xen host and start the same domain (running on another host already)
would seriously brake the fs on the san. I have to think about a solution for
that (maybe that's where xensource's optimizer can help).
But maybe setting up a spererate managment host, which knows where which
domainU is executed right now, would solve this. But if the "managment
console" is not running on the local dom0, then I think I would have to use
the xend http stuff (which I ignored totally for now *g*). And what about a
console? For a console I always have to use dom0, if I got that correctly...
but neverless, thinking about such stuff makes fun, so it's a pleasure to work
with xen :)
--Ralph
> 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
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home