--- wikisrc/ports/xen/howto.mdwn 2014/12/24 16:06:38 1.37 +++ wikisrc/ports/xen/howto.mdwn 2014/12/26 14:20:27 1.44 @@ -301,6 +301,11 @@ is using xm or xl. Note that xend is fo only be used if you plan on using "xm". Do NOT enable xend if you plan on using "xl" as it will cause problems. +The installation of NetBSD should already have created devices for xen +(xencons, xenevt), but if they are not present, create them: + + cd /dev && sh MAKEDEV xen + TODO: Give 3.1 advice (or remove it from pkgsrc). For 3.3 (and thus xm), add to rc.conf (but note that you should have @@ -329,13 +334,47 @@ For 4.2 with xl (preferred), add to rc.c TODO: Recommend for/against xen-watchdog. -After you have configured the daemons and rebooted, run the following -to inspect Xen's boot messages, available resources, and running -domains: - - xm dmesg - xm info - xm list +After you have configured the daemons and either started them or +rebooted, run the following (or use xl) to inspect Xen's boot +messages, available resources, and running domains: + + # xm dmesg + [xen's boot info] + # xm info + [available memory, etc.] + # xm list + Name Id Mem(MB) CPU State Time(s) Console + Domain-0 0 64 0 r---- 58.1 + +anita (for testing NetBSD) +-------------------------- + +With the setup so far, one should be able to run anita (see +pkgsrc/sysutils/py-anita) to test NetBSD releases, by doing (as root, +because anita must create a domU): + + anita --vmm=xm test file:///usr/obj/i386/ + +Alternatively, one can use --vmm=xl to use xl-based domU creation instead. +TODO: check this. + +Xen-specific NetBSD issues +-------------------------- + +There are (at least) two additional things different about NetBSD as a +dom0 kernel compared to hardware. + +One is that modules are not usable in DOM0 kernels, so one must +compile in what's needed. It's not really that modules cannot work, +but that modules must be built for XEN3_DOM0 because some of the +defines change and the normal module builds don't do this. Basically, +enabling Xen changes the kernel ABI, and the module build system +doesn't cope with this. + +The other difference is that XEN3_DOM0 does not have exactly the same +options as GENERIC. While it is debatable whether or not this is a +bug, users should be aware of this and can simply add missing config +items if desired. Updating NetBSD in a dom0 ------------------------- @@ -411,7 +450,10 @@ improves performance. The other is that failed to work. TODO: give working/notworking NetBSD versions for sparse vnd. Note that the use of file/vnd for Xen is not really different than creating a file-backed virtual disk for some other -purpose, except that xentools handles the vnconfig commands. +purpose, except that xentools handles the vnconfig commands. To +create an empty 4G virtual disk, simply do + + dd if=/dev/zero of=foo-xbd0 bs=1m count=4096 With the lvm style, one creates logical devices. They are then used similarly to vnds. @@ -444,6 +486,22 @@ create a new file and vnconfig it (or lv just like updating physical disks, but without having to be there and without those pesky connectors. +domU kernels +------------ + +On a physical computer, the BIOS reads sector 0, and a chain of boot +loaders finds and loads a kernel. Normally this comes from the root +filesystem. With Xen domUs, the process is totally different. The +normal path is for the domU kernel to be a file in the dom0's +filesystem. At the request of the dom0, Xen loads that kernel into a +new domU instance and starts execution. While domU kernels can be +anyplace, reasonable places to store domU kernels on the dom0 are in / +(so they are near the dom0 kernel), in /usr/pkg/etc/xen (near the +config files), or in /u0/xen (where the vdisks are). + +See the VPS section near the end for discussion of alternate ways to +obtain domU kernels. + Config files ------------ @@ -464,27 +522,12 @@ Creating specific unprivileged domains ( Creating domUs is almost entirely independent of operating system. We first explain NetBSD, and then differences for Linux and Solaris. +Note that you must have already completed the dom0 setup so that "xm +list" (or "xl list") works. Creating an unprivileged NetBSD domain (domU) --------------------------------------------- -Once you have *domain0* running, you need to start the xen tool daemon -(`/usr/pkg/share/examples/rc.d/xend start`) and the xen backend daemon -(`/usr/pkg/share/examples/rc.d/xenbackendd start` for Xen3\*, -`/usr/pkg/share/examples/rc.d/xencommons start` for Xen4.\*). Make sure -that `/dev/xencons` and `/dev/xenevt` exist before starting `xend`. You -can create them with this command: - - # cd /dev && sh MAKEDEV xen - -xend will write logs to `/var/log/xend.log` and -`/var/log/xend-debug.log`. You can then control xen with the xm tool. -'xm list' will show something like: - - # xm list - Name Id Mem(MB) CPU State Time(s) Console - Domain-0 0 64 0 r---- 58.1 - 'xm create' allows you to create a new domain. It uses a config file in PKG\_SYSCONFDIR for its parameters. By default, this file will be in `/usr/pkg/etc/xen/`. On creation, a kernel has to be specified, which @@ -608,7 +651,7 @@ working vif-bridge is also provided with #!/bin/sh #============================================================================ - # $NetBSD: howto.mdwn,v 1.36 2014/12/24 16:02:49 gdt Exp $ + # $NetBSD: howto.mdwn,v 1.43 2014/12/26 13:15:32 gdt Exp $ # # /usr/pkg/etc/xen/vif-bridge # @@ -998,3 +1041,12 @@ TODO: Perhaps reference panix, prmgr, am TODO: Somewhere, discuss pvgrub and py-grub to load the domU kernel from the domU filesystem. + +Using npf +--------- + +In standard kernels, npf is a module, and thus cannot be loadeed in a +DOMU kernel. + +TODO: explain how to compile npf into a custom kernel, answering: +http://mail-index.netbsd.org/netbsd-users/2014/12/26/msg015576.html