Jan Kundrát wrote:
> 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

Yes and no
Whenever possible we follow RHEL.  But we let people "sit on a release".  This 
means that if they want to stay at SL 5.0 they can, and they will get only the 
security errata, not the bug fixes.
This is because many times, bug fixes come with new features, or remove old 
features.  Many of the scientists want everything the exact same all the time, 
or at least as close to the exact same each time.
RedHat does not do that, or at least they didn't use to do that.  They are 
implementing something that is similiar to what we do.
But anyway.  Whenever they release a security update, that affects other 
packages, we then have to update those other packages, whether they are 
bugfix's or security updates.

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

The xen in SL 5.1 is only at version 3.0.3, not 3.1.  So, it's not too big of a 
jump.
And despite RedHat's marketing people announcing that RHEL 5.1 will do 32 bit 
paravirtual guest machines on 64 bit hosts, their engineers are quick to point 
out that it doesn't really do it.
In testing, I've found varied results.  I have not ever been able to install 32 
bit paravirtulized guest on a 64 bit machines, but I have been able to take one 
from a 32 bit machine and run it on a 64 bit machine.

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

Well, SL 5.1 is still in Beta, Beta 2 actually.  But for the most part, I 
believe all the packages are there and working.
Troy

-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/LCSI/CSI DSS Group
__________________________________________________