XEN4.1测试（已经进入pkgsrc）
发表于 : 2011-04-07 21:01
http://mail-index.netbsd.org/port-xen/2 ... 06529.html
NetBSD需要更新到当前版。
经测试我的电脑在bios中关闭apic可启动Dom0，用的XEN3内核。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
NetBSD需要更新到当前版。