call for testing: xen 4.1 packages

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

Hi,

I have packaged xen 4.1.

Get the packages from
http://www.netbsd.org/~cegger/xenkernel41.tar.gz
http://www.netbsd.org/~cegger/xentools41.tar.gz

Unpack them in pkgsrc/sysutils/

Get the file http://www.netbsd.org/~cegger/buildlink3.mk
and put it in pkgsrc/devel/ocaml-findlib/
before you install the xentools41 package.

In /etc/rc.conf add:

xend=YES

Differences to earlier xen versions:

xenbackendd=YES is no longer needed in rc.conf.


I highly recommend the use of 'xl'. xl is basically 'xm' rewritten in C.
The syntax and usage of xl is equivalent to xm.

xl does not require xend to run.
xl requires xenstored and xenconsoled to run.
xend no longer starts them automatically.
The xencommon start script starts xenstored, xenconsoled and xenbackendd.

xm is marked as supported but deprecated in Xen 4.1.
Future versions of Xen no longer support xm (it will be removed).

xl uses qemu-dm to handle accesses to the disks for both HVM and PV
guests. qemu-dm uses aio internally. vnd(4) is no longer needed.


Known-Bugs:

* xm still invokes the scripts to make guests images available via
  vnd(4). Now when starting an HVM guest, qemu's aio and vnd(4)
  conflict and this results in a EBUSY error message from open(2). The
  guests boots because whoever wins the race (either vnd or qemu) makes
  the image available to the guest. If you run a DEBUG or DIAGNOSTIC
  dom0 kernel then it panics on guest shutdown when it tries to
  close(2) the image.
  Note: This issue is related to xm only. User of xl don't have this
  problem.

* I put my focus in making xl to work on NetBSD.
  xm hasn't got much testing because of that and you may find bugs.

* xl is well tested to run HVM guests and is supposed to work
  out-of-the box. This is not the case for PV guests and you may find
  bugs.

* When booting a HVM guest and the boot menu on the serial console
  may not be shown. This is a longstanding bug in the xen tools and
  has been only exposed with xl because it is much faster than xm.
  The problem is that there is no communication infrastructure that
  allows the guest to inform the tools when it is ready to start the
  boot. If the guest is ready before the tools are then the boot menu
  appears. If the tools are faster than the guest then output is
  dropped. This is not fixable w/o deep infrastructure changes and is
  planned to be fixed in future Xen versions.
  A workaround is to refresh the boot menu manually in the guest.
  BTW: How do I refresh the boot menu in NetBSD's bootloader?


Christoph