Thanks for your reply Brian,
looks like you are doing some great work with Debianizing Xen (or Xenifying
Debian!). I thank you from the bottom of my heart :o)
Actually, I am hoping to replace our current LAMP server infrastructure with a
Xen cluster of around 8 machines. My ambition is to get to the point where I
can run them stably for 24hrs at a time with no corruption to the actual
images, at which point our developers can start working on the VMs. Hopefully
the releases Sarge and Xen 2.0 will coincide with this!
I'd be very interested in helping with any Debian related stuff you are doing
(so please keep on doing it!), though it will take time for me to get up to
speed with everything.
Could I ask the list members if they have had any issues with the stability of
the VM images themselves? That is, if I tell our developers they can start
working on VMs, will their work be safe (even if VM uptimes aren't that
great)? Naturally I'll have backup systems in place, so I'm kind of wondering
where the potential dangers lie. Initially by the way the servers will only
be hosting a few sites, perhaps four per server, so the work load (and disk
IO, and network IO..) will be pretty low.
Thanks for your contributions and time!
Regards,
Paul
On Tuesday 21 September 2004 03:44 am, Brian Wolfe wrote:
> Personally I found it a bit tough to manage configs with the curent
> kernel building phase of the xen sources. As a result I wrote the
> beginings of a kernel builder for xenlinux images and modules.
>
> If youi hit http://www.terrabox.com/debian/binary you shouyld see a
> package called xenlinuxbuilder. It's a simplified method for specificly
> building xenlinux kernels based on the installed version of
> xen-kernel-packages. To build a specific configuration of a kernel I do:
> debian/rules clean menuconfig tarball PRIV=[yes|no]
> LIN_VER=[2.4.27|2.6.8] EXTRA=[whatever extraversion label]
>
> note: you MUST specify clean prior to tarball curently IF you apply any
> 3rd party patches to the source. It doens't handle detecting extra
> patches, yet. My goal is to create a mak-kpkg like system specificly for
> debian initially, later for general use. It will save your individual
> configs into configs/ for reuse after you have fully configured the
> individual kernel.
>
> It will produce a single tarball for /boot and /lib/modules for
> privileged kernels, and separate /boot and /lib/modules tarballs for
> unpriv kernels. This has made it a bit easier for myself to generate and
> maintain separate and easilly built kernels for my various xenlinux
> images.
>
> If you are managing more than just 1 or 2 kernel versions then this may
> be a smoother method for compiling and packaging since *eventually* it
> will produce .deb packages that will verify which xen version it is that
> you are running on the underlying xen kernel.
>
> I have also packaged up the xen distro as pre-compiled binaries for xen
> on Debian Sarge. I'm close to having a nightly export run that will bk
> update, debian patch, compile, and package them automagically. :) I'm
> willing to share my custom makefile for doing this if you want to
> maintain a local repository of xen packages.
>
> I stil have a good bit of work to do before I can send the debian/* tree
> upstream for inclusion into xen proper if the gang will accept them. :)
>
> I also need ideas on how best to tie the debs into the netbsd vhost disk
> image so that I can build netbsd server images dynamicly. Right now i'm
> taking a look at the xenoboot software to see if I can't package it up
> for debian to keep from reproducing a lot of the work that has already
> been done.
>
>
> as far as number of images that I run per machine, a friend of mine runs
> ~20 images on a 4GB dual p4 machine at his offices. I run 6 athlon xp
> 2000+ machines, each with 1GB ram that run from 2 to 10 images each. So
> far not a single beta client has complained of any kind of CPU or
> performance issues. So far it appears that memory is more of an issue
> here than anything else due to the amazingly low overhead of xen when
> using NAS or SAN based storage. :)
>
> As far as selling vhosts using xenlinux kernels, I wouldn't make it an
> official product just yet. It's stable for local disks, and in general,
> however I have run into various issues that have poped up related to
> iSCSI and other momentary glitches as I do semi-daily updates of the
> cluster. I would let the xen team get to an official 2.0 release before
> truly pushing vhosts out as a paid-service (unless you get a few clients
> to sign up for them with the understanding that they aren't guaranteed
> stable yet).
>
> If you go lok at http://xen.terrabox.com there is a page for companies
> to list themselves on that offer xen based virtual hosts that I started.
>
> Hope this helps from the business perspective for you. :)
>
> Brian
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home