Re: [Xen-users] Best way to get Xen into Ubuntu Natty/64bit

["Fajar A. Nugraha" <list@xxxxxxxxx>]

On Tue, Nov 15, 2011 at 11:03 PM, Florian Heigl <florian.heigl@xxxxxxxxx> wrote:
> And I pretty much guess CentOS/RHEL 5 will also not boot if the
> CentOS-binary-compatible OVM 2.2.2 panics upon disk detection.

I wouldn't be so sure about that. Redhat adds drivers on every point
release. And OVM 3 uses kernel 2.6.32, so both might actually work.

>
> It definitely needs to be something less 2006'ish than CentOS,

RHEL 5.7 is less than 6 monts old :D

> Anyway.
> If I summarize this thread (in my always positive way) then I'm down to:
> - Use manual build of Xen on Ubuntu or Debian

... or RHEL/Centos

> - Use CentOS 5 (can't since it wont work)

it might if your kernel is new enough

> - Use CentOS 6 + GitCo (maybe?)

I think gitco is for RHEL/Centos5. Might work for 6 though (or at
least you can rebuild its SRPM).

> - Fedora 16 (how about that!?)

might work. haven't tried. I needed a distro that lasts longer than 1 year.

> - Stuff FC16 kernel into CentOS6 (uh. that's not how we run servers out here?)

News flash: Oracle grabs kernel 2.6.32, put in on their RHEL5 clone,
and markets it as "unbreakable enterprise kernel" :)

Personally I'm much more comfortable using latest vanilla kernel
(packaged as RPM, of course) on top of RHEL6. At least for the life
time of the server (usually about 3 years) I know that I only have to
update xen and the kernel manually, and not having to worry about
backporting openssl or sendmail (or any one of the hundreds of
packages normally present on a linux distro) bug fixes myself.

Then again if the next Ubuntu LTS properly supports Xen, i might be
tempted to use that as base instead.

> - Stop trying all of that and put my time into the Alpine Linux Xen
> port. Meaning I'll have to fix anything I encounter and there's no
> googling for issues.

... or stop trying to treat Xen as a software you install on top of
existing OS, and use an appliance: Xenserver, XCP, OVM. Real
time-saver for certain situations.

And if neither of them fits your needs, then perhaps xen is simply not
the right tool for the job. In the end of they it's getting the job
done that really counts, isn't it?

>
> Footnote:
> Using some build like the xen testing one for RHEL6 is a road to hell.
> I've done that a few times for RHEL5/RHEL6 and know well enough these
> builds get rarely bugfixed, but never updated.
> If something stops working then you're left on your own.

I have several systems running RHEL5 + stock kernel and xen, has been
running for several years, works just fine.
I have other system running  RHEL5 + custom version of kernel and xen
(all from package, either gitco or self-built) because I needed some
new features (e.g. ability to run opensolaris domU, and pygrub that
supports zfs). They're also managable (as long as you remember to
build/update the custom packages). If the "testing" package isn't
updated fast enough (e.g. Gitco is usually behind by a few weeks or
month) then I just build it myself using the last available SRPM as
base.

-- 
Fajar

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users