Troy Dawson wrote:
> The options I see are to either fix the old xen to work with the new
> kernel, or to update the xen in SL 5.0 to match the xen in SL 5.1.
> 
> Personally, after using the xen on SL 5.1, my vote it to move 5.0 up to
> that version of xen.  It fixes *alot* of the bugs and troubles I was
> having on xen.  But I don't know how that is going to affect SL 5.0
> machines that are currently running xen.  But, by pushing out that
> kernel, we've aready affected them.
> 
> I'm going to be testing a bunch of things, but while I am, any ideas or
> preferences?

Funnily enough, I installed that machine just few days ago and as it's a
64bit one, I decided to go with 64bit SL. I was surprised a bit when I
found out that I can't use 32bit guests with 64bit Xen 3.0; this feature
was added in 3.1.

I have very little understanding about how SL works, but isn't it
supposed to mirror RHEL's decisions as closely as possible? If this is
true, I propose to do the same as what they do. If this is not possible,
isn't a simple rebuild of the "xen" package enough (if xen-kernel uses
patches from xen-3.0.x and not 3.1.x)? If everything else fails and
nobody maintains 3.0 series of xen (no idea if this is the case), then
announcing "Xen is totally broken on 5.0, use 5.1 instead" is perfectly
reasonable for me.

I have no problems upgrading to 5.1 if you recommend me to do so. Is
that a good idea? Can I safely go to 64bit version (given that we use
that box exclusively for hosting other Xen machines)?

Cheers,
-jkt