Bugzilla Bug 70161

Xen is a virtual machine monitor for x86 that supports execution of multiple
guest operating systems with unprecedented levels of performance and resource
isolation. Xen is Open Source software, released under the terms of the GNU
General Public License. We have a fully functional ports of Linux 2.4 and 2.6
running over Xen, and regularly use it for running demanding applications like
MySQL, Apache and PostgreSQL. Any Linux distribution (RedHat, SuSE, Debian,
Mandrake) should run unmodified over the ported OS.

Reproducible: Always
Steps to Reproduce:

'We' should be read as 'They'.

Are you requesting an ebuild, or do you already have one to share?

Best regards,
Stu

Requesting, to download the latest sources bitkeeper tools are needed. Plus,
XEN start downloading a kernel which is allready found on most systems in
distfiles.

I've got some almost-working ebuilds to build and install Xen (tentatively
named sys-apps/xen and sys-kernels/xen-sources); if nobody else is already
working on this, I should (hopefully) be able to finish them to a
generally-working state in the next several days.

I've uploaded my current attempts to http://people.pwf.cam.ac.uk/pjt47/xentoo/
- I wouldn't be surprised if I've done various things wrongly, but it appears
to work for me (as far as booting Gentoo using a XenLinux kernel and running
xend; I haven't tried actually running a virtual Gentoo machine).

Current problems include being limited to the 2.6 kernel, not handling
unprivileged domains (unless you manually use a different default kernel config
file), confusing etc-update by putting binary files in /etc (since I didn't
want to automatically mount /boot, and wasn't sure where else to put them), and
possibly other things that I've not noticed or remembered.

To build the docs, tgif (see bug 36185) is required.

inherit mount-boot should sort out the auto mounting of /boot for the ebuild.

Aha, thanks - I've updated it to use mount-boot and copy the files directly
into /boot. (Updated ebuilds at http://people.pwf.cam.ac.uk/pjt47/xentoo/
again.)

I'm not sure what the most convenient way of installing an unprivileged kernel
is; I currently provide manual instructions to cp /usr/src/linux-2.6.9-xen0 to
linux-2.6.9-xenU and then to switch the default config file. It seems a little
wasteful to devote half a gigabyte to two identical copies of the kernel
sources, but I don't know what else to do.

Use flag (xen0only)?  Seperate package?

I'd say unpack to two different directories in this ebuild.  A user who is low on space could always unmerge the sources once they've built the two kernels they require?

Created an attachment (id=43893) [edit]
xen-2.0.ebuild

clean up of the app-emulation/xen/xen-2.0.ebuild by Philip Taylor

Created an attachment (id=43894) [edit]
xend.rc

Gentoo-ified version of the /etc/init.d/xen script

if someone can create a Gentoo-ified version of the xendomains init.d script,
i'll add this package to portage ...

Created an attachment (id=43934) [edit]
`rm -f` instead of `rm`

this is not good :-)

rm: remove write-protected regular file
`/var/tmp/portage/xen-sources-2.6.9/work/linux-2.6.9-xen0/mkbuildtree'? 

xen looks very promising, btw the developers have released version 2.0.1, is
anyone able to create a Gentoo-ified version of the xendomains init.d script so
that this package can be added to the tree?

Created an attachment (id=44961) [edit]
Version bump to 2.0.1.

Have added the cam.ac.uk mirror as the sourceforge mirrors do not carry this
file yet.

(From update of attachment 44961 [edit])
Version bump to 2.0.1.

Created an attachment (id=44962) [edit]
xen-2.0.1.ebuild

Tested version :)

Added the cam.ac.uk mirror as sourceforge does not seem to have it on the
mirrors at present, and one of the mirrors hung for me. Added the cam.ac.uk
webpage also.

Had to use some 'trickery' to get it to compile, as the package is zipped in a
xen-2.0 directory, so I have a mv command. Hopefully this is a fair way to do
it, and should also mean that it is easy to update just by copying and
remnaming the ebuild as the version is bumped.

Will look at the init.d script to see if I can Gentoo-ify it so it can be
merged mainstream!

Created an attachment (id=44963) [edit]
xendomains

Gentoo-ified xendomains script.

There is plenty more that could be done to this script - restart and reload are
commented out from the original script.

Haven't played with Xen too much yet, but wondering if it might be worth
setting individual scripts for each domain, cf net.* scripts (eg xen.dom0,
xen.dom1 etc)

Created an attachment (id=44965) [edit]
xend

/etc/init.d/xend script, modified to represent that it is starting dom0 as
opposed to Xen in general. Should help remove confusion during boot with the
xenddomains script.

> /etc/init.d/xend script, modified to represent that it is starting dom0 as
opposed to Xen in general

you can't start dom0 as it is started by xen when it boots. stopping dom0 means halting the machine. xend is afaik xen control daemon for performing management tasks like starting/stopping other domains, resource usage control,...
and you'll need another daemon for live migration support. 

Good point. Now that I look closer at the script (Why didn't I read it earlier)
it is for starting the Control Daemon for the domains. Is it worth modifying
the xend script for that?

you'll have to compile glibc without nptl in USE flags, otherwise you'll get
this warning:

  ***************************************************************
  ***************************************************************
  ** WARNING: Currently emulating unsupported memory accesses  **
  **          in /lib/tls libraries. The emulation is very     **
  **          slow, and may not work correctly with all        **
  **          programs (e.g., some may 'Segmentation fault').  **
  **          TO ENSURE FULL PERFORMANCE AND CORRECT FUNCTION, **
  **          YOU MUST EXECUTE THE FOLLOWING AS ROOT:          **
  **          mv /lib/tls /lib/tls.disabled                    **
  ***************************************************************
  ***************************************************************

despite what it says, /lib/tls doesn't exist on my system, but see this message
from Ian Pratt (Rik is probably Rik van Riel from Red Hat):

NPTL is supported, but we're forced to take traps for almost
every attempt to access thread local storage, which is slow (I
think Rik said 12-15% on a kernel compile).

The only way to improve on this would be to have our own very
slightly modified version of libc that could be installed to
restore full performance. We're hoping to look into this at some
point.

Disabling NPTL works for most people.

Ian

ok, then if i understand this correctly, the xen init.d scripts are really only
meant to be used from inside of xen ?

if so, i'll have the ebuild stick them in /usr/share/xen/ instead of
/etc/init.d/ ...

It depends what you think "inside of xen" is. You need two types of a kernel; a
host kernel (Xen calls this domain 0) and guest kernel (you can assign any
number/name to this domain). When you boot your system with a Xen host kernel
you are already inside Xen (domain 0), however to start a guest kernel you need
to have xend running. I thinks /etc/init.d is the correct location for both
scripts.

ok, but the only files that should go into /etc/init.d/ are scripts that have
been 'gentoo-ified'

yep, only two scripts need to go to /etc/init.d; xend (to start/stop the
xen-interface) and xendomains (to start/stop the quest systems during
boot/shutdown).

if you use xen, you need at least two things - xen kernel itself and patched
linux  kernel (aka "domain0" in xen terminology). these two thing will provide
(almost) the same services as normal vanilla linux kernel, plus some xen stuff,
so you can run any distribution (including gentoo :-)) on the top of such
system.
but this setup is useless if you don't run any virtual domains (you don't have
to bother with xen just to run "one instance" of OS), so you'll probably want
to create another virtual machines. in order to do it, you'll need xend running
inside of domain0 (`/etc/init.d/xend start` is a good way, it is only shell
script to actually start xend daemon) and have prepared special kernel (linux,
netbsd, freebsd, winxp (well, not available due to licensing issues)) and root
fs. then you can start any number of other "machines", or, in Xen terminoology,
domains.
as you probably want to start all (or some of) these virtual machines at
bootup, xen has provided the "xendomains" init script, it looks into
/etc/xen/auto/ and starts domains specified there.

Michiel is right.

Hi All,

Thanks for the ebuild. Testing it now.
I got the following error:

cc1: warning: -fprefetch-loop-arrays not supported for this target (try -march switches)

I remember that it's possible to disable certain useflags and cflags for ebuilds (but forgot how). Might be wise to disable this one ?

Grtz Ramon

Just wanted to let you know that version 2.0.2 has been released.

Just wanted to let you know that version 2.0.3 has been released.

Question for the devs:
I don't want to be the impatient user but isn't it time to put these ebuilds in Portage? There are a lot of people interested if you look at the CC list but almost nothing happens here. I fear that people willing to try Xen might jump over to RHEL or SuSE.

Just my 2 euro

Question for the devs:
I don't want to be the impatient user but isn't it time to put these ebuilds in Portage? There are a lot of people interested if you look at the CC list but almost nothing happens here. I fear that people willing to try Xen might jump over to RHEL or SuSE.

Just my 2 euroçents of course, let's not start a flamewar on Gentoo VS ... please.

I don't know.  I would think not.  I have started to use those ebuilds, but I'm
ending up righting an ebuild of my own because these ones had hickups.

A link to this bug from the forums or elsewhere would help much more in getting
this tested and find a proper implementation for it.  Then release it to
Portage, unless it worked out of the box for everybody elses?!?

Ok, what is everybody's general status about this?

I have succesfuly builded and implemented Xen on a 2.4 kernel box here.  There's still issues to get this done properly thrue a ebuild, but I think I have a sufficient basic grasp of this to generate an ebuild.

The biggest issue I had was how to make it download a 2.4 or a 2.6 kernel.  As such, I think patching the kernels upstream would be a better approach (I'd even hope it would be directly included into the kernels at www.kernel.org).  Because of that, i had problems integrating my .config inside xen0.  But I think I can manage it on my next iteration.

My other issue is the fact the the vanilla Xen script will install the xenU kernel into /boot.  This is somewhet inappropriate because then it requires you to mount it to access the kernel.  As a simplification, I simply made the configuration file point directly at the bzImage inside the kernel's source hierarchy (arch/xen/boot/bzImage).

Another issue I encounter is the fact that xenU cannot absolutely not work properly if started with devfs.  So this caused problems when using Gentoo as a guest, which will complain if devfs is not enabled.  Insights about this would be appreciated.  I guess I should try to guest something else like Knoppix.

What about you guys?  Where are you at with this?

>Another issue I encounter is the fact that xenU cannot absolutely not work properly if started with devfs.  So this caused problems when using Gentoo as a guest, which will complain if devfs is not enabled.  Insights about this would be appreciated.

emerge udev

devfs at boot is a requirement of Gentoo.  In a Xen point of view, udev would
probably cause the same issue.  A Xen booted guest seems to need static device
nodes in /dev.

On monday, I will extract the build steps from the Makefiles to incoporate them
directly in the ebuild instead.  This will give the flexibility to use a
distinct xen patched kernel, instead of having to use "make kernel-bla" from
xen.

So, I guess that by the end of next week, I'll have a ebuild to submit here.  I
mainly wanted to know if others did work on this and avoid duplicating stuffs.

udev is supported as well, as a mather of fact it will be the default very soon
for architectures that support it, same goes for the 2.6 kernel which you need
when using udev, we use it on all our Xen-servers, I suggest you take a look at
Philip's webpage, he already made an ebuild for the Xen-sources.

We need to put this on 2.4 systems.  So the limitation is either because of
Gentoo's inhability to run with a static /dev, or xen's inhability to run with
a dynamic one.

I'm doing my second iteration install to check if the ebuilds works well, and I
always seem to have issues with the xenU kernel.  I'm unsure if xen is what we
really want.  For now, I'll admit I way prefer the vmware paradigm of
virtualization.

I mean, shouldnt it be the guest kernel who should get xenified, instead of
having a bunch of xenU kernels that are completely unrelated to the guest
kernel (that could have various patches applied).  I don't get it :(

Created an attachment (id=50718) [edit]
xen-2.0.4.ebuild

I wasn't able to get the ebuild in #37 to go.  First it would not find the file
to download.  I manually downloaded it from http://www.cl.cam.ac.uk and created
the digest.  When I went to install it I received the following error.

>>> emerge (1 of 1) sys-kernel/xen-2.0.4 to /
>>> md5 src_uri ;-) xen-2.0.4-src.tgz
>>> Unpacking source...
>>> Unpacking xen-2.0.4-src.tgz to /var/tmp/portage/xen-2.0.4/work
/usr/lib/portage/bin/ebuild.sh: line 33: cd:
/var/tmp/portage/xen-2.0.4/work/xen-2.0.4: No such file or directory
sed: can't read tools/libxc/Makefile: No such file or directory
sed: can't read tools/libxutil/Makefile: No such file or directory
sed: can't read tools/misc/miniterm/Makefile: No such file or directory
sed: can't read tools/misc/nsplitd/Makefile: No such file or directory
sed: can't read tools/misc/Makefile: No such file or directory
sed: can't read tools/xentrace/Makefile: No such file or directory
sed: can't read xen/arch/x86/Rules.mk: No such file or directory

!!! ERROR: sys-kernel/xen-2.0.4 failed.
!!! Function src_unpack, Line 39, Exitcode 2
!!! sed cflags

Apparently, ${S} and the contents of the tgz don't agree.

(From update of attachment 50718 [edit])
the ebuild looks dos encoded btw

Created an attachment (id=51453) [edit]
another ebuild

That isn't really a nice solution but at least build and install

when trying the latest ebuild, I get the following error.  as I posted on the
xen mailing list about an earlier version of this ebuild, I suspect the problem
is due to makefiles using $(DESTDIR} which is the getting wrong value from the
ebuild environment:

ACCESS DENIED  mkdir:     /usr/portage/distfiles/install
install: cannot create directory `/usr/portage/distfiles/install': Permission
denied

unset DISTDIR is present just to address that problem

tried the suggestion and the build process got a little further:

[ -d /usr/lib ] || install -d -m0755 -p /usr/lib
install -m0755 libxutil.so.2.0.0 /usr/lib
ACCESS DENIED  open_wr:   /usr/lib/libxutil.so.2.0.0
install: cannot create regular file `/usr/lib/libxutil.so.2.0.0': Permission denied
make[1]: *** [install] Error 1
make[1]: Leaving directory `/var/tmp/portage/xen-2.0.4/work/xen-2.0/tools/libxutil'

looked inside xen-2.0/tools/libxutil/Makefile and saw that it used $(DESTDIR) on installation.  I set DESTDIR to ${WORKDIR} but I got the same failure.  any suggestions for what I should try next?

Would it help if somebody (I) provide a rsync mirror for a portage overlay
including xen (and tgif)?

It seems that no dev wants that in the official tree at the moment...

Created an attachment (id=52423) [edit]
xen ebuild

Hi, here is another ebuild with patch to solve DISTDIR/DESTDIR problem.

Created an attachment (id=52424) [edit]
xen patch

Just wanted to let you know that version 2.0.5 has been released.

*** Bug 85211 has been marked as a duplicate of this bug. ***

The build fails for me for some reason. I get these 'asm' errors..

make[2]: Entering directory `/mnt/data/Gentoo-Tmp/portage/xen-2.0.4-r1/work/xen-2.0/xen/common'
gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Wall -Werror -pipe -I/mnt/data/Gentoo-Tmp/portage/xen-2.0.4-r1/work/xen-2.0/xen/include -Wno-pointer-arith -Wredundant-decls -O2 -march=pentium3 -fomit-frame-pointer -pipe -falign-functions=64 -mmmx -msse -msse2 -fomit-frame-pointer -msoft-float -m32 -march=i686 -DNDEBUG -c ac_timer.c -o ac_timer.o
gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Wall -Werror -pipe -I/mnt/data/Gentoo-Tmp/portage/xen-2.0.4-r1/work/xen-2.0/xen/include -Wno-pointer-arith -Wredundant-decls -O2 -march=pentium3 -fomit-frame-pointer -pipe -falign-functions=64 -mmmx -msse -msse2 -fomit-frame-pointer -msoft-float -m32 -march=i686 -DNDEBUG -c dom0_ops.c -o dom0_ops.o
gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Wall -Werror -pipe -I/mnt/data/Gentoo-Tmp/portage/xen-2.0.4-r1/work/xen-2.0/xen/include -Wno-pointer-arith -Wredundant-decls -O2 -march=pentium3 -fomit-frame-pointer -pipe -falign-functions=64 -mmmx -msse -msse2 -fomit-frame-pointer -msoft-float -m32 -march=i686 -DNDEBUG -c dom_mem_ops.c -o dom_mem_ops.o
gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Wall -Werror -pipe -I/mnt/data/Gentoo-Tmp/portage/xen-2.0.4-r1/work/xen-2.0/xen/include -Wno-pointer-arith -Wredundant-decls -O2 -march=pentium3 -fomit-frame-pointer -pipe -falign-functions=64 -mmmx -msse -msse2 -fomit-frame-pointer -msoft-float -m32 -march=i686 -DNDEBUG -c domain.c -o domain.o
gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Wall -Werror -pipe -I/mnt/data/Gentoo-Tmp/portage/xen-2.0.4-r1/work/xen-2.0/xen/include -Wno-pointer-arith -Wredundant-decls -O2 -march=pentium3 -fomit-frame-pointer -pipe -falign-functions=64 -mmmx -msse -msse2 -fomit-frame-pointer -msoft-float -m32 -march=i686 -DNDEBUG -c elf.c -o elf.o
dom_mem_ops.c: In function `free_dom_mem':
/mnt/data/Gentoo-Tmp/portage/xen-2.0.4-r1/work/xen-2.0/xen/include/asm/mm.h:160: error: can't find a register in class `BREG' while reloading `asm'

Created an attachment (id=53755) [edit]
2.0.5 ebuild for hypervisor and dom0 daemons

Created an attachment (id=53756) [edit]
xend init.d file

Created an attachment (id=53757) [edit]
/etc/conf.d/xendomains file

Created an attachment (id=53758) [edit]
init.d file for domU unprivilaged domains

Created an attachment (id=53759) [edit]
ebuild for 2.6.10 kernel with xen 2.0.5

I am rather suprised that it is taking so long to get xen ebuilds into portage.
 I guess the lack of any gentoo specific document explaining what is involved
in setting it up would be part of the problem.  These ebuilds are based on
Philip Taylor original ebuilds with some modifications.  They have been updated
since version 2.0 and are currently running on internal production servers. 
They will not work with hardened patches (i.e. -pie).

probably obvious but.

the xen ebuild goes into 
  apps-sys/xen
all associated files go into
  apps-sys/xen/files

the xen-sources ebuild goes into
  sys-kernel/xen-sources

Xen will not just work out of the box.  You need to create the environment for
the operating system instances (i.e. filesystems).  In that respect it is very
much like UML.  To install xen you will need to read the manual
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/user.html

Question: does Xen run on any architectures other than x86 and x86-64? Does it
work with 2.4.25?

> Question: does Xen run on any architectures other than x86 and x86-64?
No. Even the ia64 support is not very mature - see the xen-devel mailing list for details.

> Does it work with 2.4.25?
IIRC, dom0 (the domain which can controll another "virtual" domains) must be 2.6. Other domains could run 2.4 kernels or OpenBSD (maybe other BSD derivates, Kip Macy is developing FreeBSD port - consult the mailing list).

BTW, why does this bug depend on bug 36185? AFAIK the tgif is required only for building of docs.

I've just tried removing the tgif DEPEND line in the ebuild, then compile it
with USE=doc : it compiles just fine, and the docs are generated.

Is this dependency _really_ needed ?

Is there any status update available to this bug? Other distros already use
Xen, a lot of users want Xen but nothing seems to happen here.
I hope this is the right "noise" to make this bug active again...

I'm interested in this too, do we need testers?

It seems to me we have too much commotion and are lacking some verified working ebuilds, maybe if someone already au fait with this bug could write a short how-to, with links to what file(s) are needed, and we could go about testing them to help iron out the wrinkles.

I think if it was a little clearer and we had sane ebuilds it would be a good candidate for portage.

Created an attachment (id=56536) [edit]
sys-apps/xen-2.0.5

Added a few dies, since I had a few missing files. Did not change anything
else.

Created an attachment (id=57185) [edit]
init.d/xend

(From update of attachment 57185 [edit])

#!/sbin/runscript
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

opts="start stop status restart"

depend() {
	before xendomain
}

await_daemons_up() {
	for ((i=0; i<5; i++)); do
		sleep 1
		xend status && return 0
	done
	return 1
}

stop_all_xendomains(){
	einfo "Shutting down all Xen domains"
	xm list | cut -d' ' -f1 | grep -Ev "^(Name|Domain-0)$" |
	while read dom; do
		# Stop all running domains.
		ebegin "  Stopping domain $dom"
		xm shutdown --halt --wait $dom >/dev/null
		eend $?
	done
}

start() {
	ebegin "Starting Xen control daemon"
	xend start
	xend status || await_daemons_up
	eend $?

	if [ "$XENSV" = YES ] && xend status; then
		ebegin "Starting Xensv"
		xensv start
		eend $?
	fi	
}

stop() {
	if [ "$(xm list | wc -l)" -gt 2 ]; then
		stop_all_xendomains
	fi

	if [ "$XENSV" = YES ]; then
		ebegin "Stopping Xensv"
		xensv stop
		eend $?
	fi

	ebegin "Stopping Xen control daemon"
	xend stop
	eend $?
}

status() {
	xend status
}

(From update of attachment 57185 [edit])
#!/sbin/runscript
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

opts="start stop status restart"

depend() {
	before xendomain
}

await_daemons_up() {
	for ((i=0; i<5; i++)); do
		sleep 1
		xend status && return 0
	done
	return 1
}

stop_all_xendomains(){
	einfo "Shutting down all Xen domains"
	xm list | cut -d' ' -f1 | grep -Ev "^(Name|Domain-0)$" |
	while read dom; do
		# Stop all running domains.
		ebegin "  Stopping domain $dom"
		xm shutdown --halt --wait $dom >/dev/null
		eend $?
	done
}

start() {
	ebegin "Starting Xen control daemon"
	xend start
	xend status || await_daemons_up
	eend $?

	if [ "$XENSV" = YES ] && xend status; then
		ebegin "Starting Xensv"
		xensv start
		eend $?
	fi	
}

stop() {
	if [ "$(xm list | wc -l)" -gt 2 ]; then
		stop_all_xendomains
	fi

	if [ "$XENSV" = YES ]; then
		ebegin "Stopping Xensv"
		xensv stop
		eend $?
	fi

	ebegin "Stopping Xen control daemon"
	xend stop
	eend $?
}

status() {
	xend status
}

(From update of attachment 57185 [edit])
Sorry about the last two comments. I'm about to learn how to submit files to
bugzilla :-(

Created an attachment (id=57186) [edit]
init.d/xend

Created an attachment (id=57187) [edit]
conf.d/xend

Created an attachment (id=57188) [edit]
init.d/xendomains

Created an attachment (id=57189) [edit]
sys-apps/xen/xen-2.0.5.ebuild

new Attachments:

xend-init:
- support for starting xensv (via xend-conf)
- now shuts down all running domains before stopping xend
- removed lots of "

new Attachments:

xend-init:
- support for starting xensv (via xend-conf)
- now shuts down all running domains before stopping xend
- removed lots of "¦¦ die" statements (makes no sense in init scripts)

xend-conf:
- new file, used to enable xensv

xendomains-init:
- simplified a lot
- xendomains-conf removed, as it wasn't really neccessary

xen-2.0.5.ebuild:
- use emake instead of make
- newinitd & newconfd functions used instead of cp

all:
- gentoo conforming headers added

I would really like to see this in portage ASAP.
Could someone please test this new ebuild and init-files?

Created an attachment (id=57231) [edit]
sys-apps/xen/xen-2.0.5.ebuild

sys-apps/xen-2.0.5.ebuild
* removed tgif which does not seem to be necessary to compile the documentation

* added debug flag (needed for verbose debugging messages).
* re-added xendomains-conf which is needed, as explained below.

Created an attachment (id=57232) [edit]
sys-apps/xen/files/xendomains-init

/files/xendomains-init
* moved AUTODIR back into the config script.  This is needed for running groups
of domains, or domains with specific options based on the runlevel.
* added ${} around variables
* changed starting from auto -> ${AUTODIR}

Created an attachment (id=57233) [edit]
sys-apps/xen/files/xendomains-conf

/files/xendomains-conf -> /etc/conf.d/xendomains
* removed INITD and LOCKFILE variables as they are not used

Created an attachment (id=57234) [edit]
sys-apps/xen/files/xend-init

/files/xend-init -> /etc/init.d/xend
* added net dependency because xend needs network setup before starting.  The
default setup specifically require eth0 but as this is a setting it seemed like
a bad idea putting it in the init script.
* removed stop_all_xendomains function.  It is not necessary to step though all
domains when shutting down in xend.  This is just a safety/sanity check incase
a domain has been created outside the init scripts.

these are modifications to Christoph Gysin files above.  You will need the
conf.d/xend file above to use them.  The AUTODIR has been moved into a
configuration file because this allows the use of multiple groups of domains. 
This works in a similar way to /etc/init.d/net.eth0.

Old attachments made obsolete.

conf.d/xend renamed to sys-apps/xen/files/xend-conf

I've just tested Edward Middleton's modifications. Everything works as
expected.

Can anybody else confirm this, so we can put it into portage?

i've used the ebuild xen-sources-2.6.10.ebuild (id=53759) and did this steps:

make ARCH=xen menuconfig
make ARCH=xen
make ARCH=xen modules_install
make ARCH=xen install

but no /boot/xen.gz

something missing in the ebuild?
there's only xen.gz in the xen-2.0-install.tgz

* /boot/xen.gz is the hypervisor (mediates operating system access to the
hardware) installed with sys-apps/xen
* /boot/vmlinuz is a domain0-N kernel created from the sys-kernel/xen-sources

* these are not in the same ebuild because there are a number of operating
systems other then linux (various bsd's, plan9 etc) that will run under the
hypervisor so it does not make sense packaging them all in one