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 [EMAIL PROTECTED] (630)840-6468
Fermilab ComputingDivision/LCSI/CSI DSS Group
__________________________________________________
