WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

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

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] 2.0.7 -> 3.0.0 upgrade
From: Ralph Passgang <ralph@xxxxxxxxxxxxx>
Date: Thu, 19 Jan 2006 14:40:49 +0100
Delivery-date: Thu, 19 Jan 2006 13:48:46 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <43CE92BD.1080509@xxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <200601171040.53123.matthew@xxxxxxxxxxx> <43CE92BD.1080509@xxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.1
Am Mittwoch, 18. Januar 2006 20:10 schrieb Per Andreas Buer:
> Matthew Walster wrote:
> > Hey all,
> >
> > I'm thinking about moving my 2.0.7 install over to 3.0.0 for eventual use
> > in a production environment.
> >
> > Two questions:
> >
> > 1) Do people think 3.0.0 is ready for production - or is it just a
> > testing/unstable playpen?
>
> We've seen some strange behavior with migration and one incident where
> we could not create new XenU's. As long as you stay away from migration
> I'd guess you're safe.

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

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

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.

> Per.

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