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
smime.p7s
Description: S/MIME Cryptographic Signature
