--- wikisrc/ports/xen/howto.mdwn 2014/12/24 08:32:49 1.27 +++ wikisrc/ports/xen/howto.mdwn 2014/12/24 16:06:38 1.37 @@ -27,11 +27,12 @@ code for Xen and need not be aware that Attempts to access hardware registers are trapped and emulated. This style is less efficient but can run unmodified guests. -Generally any amd64 machine will work with Xen and PV guests. For -HVM guests, the VT or VMX cpu feature (Intel) or SVM/HVM/VT (amd64) -is needed; "cpuctl identify 0" will show this. Xen 4.2 is the last -version for support for using i386 as a host. TODO: Clean up and -check the above features. +Generally any amd64 machine will work with Xen and PV guests. In +theory i386 computers without amd64 support can be used for Xen <= +4.2, but we have no recent reports of this working (this is a hint). +For HVM guests, the VT or VMX cpu feature (Intel) or SVM/HVM/VT +(amd64) is needed; "cpuctl identify 0" will show this. TODO: Clean up +and check the above features. At boot, the dom0 kernel is loaded as a module with Xen as the kernel. The dom0 can start one or more domUs. (Booting is explained in detail @@ -89,7 +90,7 @@ matching versions. xenkernel3 and xenkernel33 provide Xen 3.1 and 3.3. These no longer receive security patches and should not be used. Xen 3.1 supports PCI -passthrough. +passthrough. Xen 3.1 supports non-PAE on i386. xenkernel41 provides Xen 4.1. This is no longer maintained by Xen, but as of 2014-12 receives backported security patches. It is a @@ -117,7 +118,9 @@ NetBSD The netbsd-5, netbsd-6, netbsd-7, and -current branches are all reasonable choices, with more or less the same considerations for non-Xen use. Therefore, netbsd-6 is recommended as the stable version -of the most recent release. +of the most recent release for production use. For those wanting to +learn Xen or without production stability concerns, netbsd-7 is likely +most appropriate. As of NetBSD 6, a NetBSD domU will support multiple vcpus. There is no SMP support for NetBSD as dom0. (The dom0 itself doesn't really @@ -127,20 +130,45 @@ a normal computer.) Architecture ------------ -Xen is basically amd64 only at this point. One can either run i386 -domains or amd64 domains. If running i386, PAE versions are required, -for both dom0 and domU. These versions are built by default in NetBSD -releases. While i386 dom0 works fine, amd64 is recommended as more -normal. (Note that emacs (at least) fails if run on i386 with PAE when -built without, and vice versa, presumably due to bugs in the undump -code.) +Xen itself can run on i386 or amd64 machines. (Practically, almost +any computer where one would want to run Xen supports amd64.) If +using an i386 NetBSD kernel for the dom0, PAE is required (PAE +versions are built by default). While i386 dom0 works fine, amd64 is +recommended as more normal. + +Xen 4.2 is the last version to support i386 as a host. TODO: Clarify +if this is about the CPU having to be amd64, or about the dom0 kernel +having to be amd64. + +One can then run i386 domUs and amd64 domUs, in any combination. If +running an i386 NetBSD kernel as a domU, the PAE version is required. +(Note that emacs (at least) fails if run on i386 with PAE when built +without, and vice versa, presumably due to bugs in the undump code.) Recommendation -------------- Therefore, this HOWTO recommends running xenkernel42 (and xentools42), -xl, the NetBSD 6 stable branch, and to use amd64 as the dom0. Either -the i386 or amd64 of NetBSD may be used as domUs. +xl, the NetBSD 6 stable branch, and to use an amd64 kernel as the +dom0. Either the i386 or amd64 of NetBSD may be used as domUs. + +Build problems +-------------- + +Ideally, all versions of Xen in pkgsrc would build on all versions of +NetBSD on both i386 and amd64. However, that isn't the case. Besides +aging code and aging compilers, qemu (included in xentools for HVM +support) is difficult to build. The following are known to fail: + + xenkernel3 netbsd-6 i386 + xentools42 netbsd-6 i386 + +The following are known to work: + + xenkernel41 netbsd-5 amd64 + xentools41 netbsd-5 amd64 + xenkernel41 netbsd-6 i386 + xentools41 netbsd-6 i386 NetBSD as a dom0 ================ @@ -241,34 +269,73 @@ beginning of your root filesystem, /boot See boot.cfg(5) for an example. The basic line is -"menu=Xen:load /netbsd-XEN3_DOM0.gz console=pc;multiboot /xen.gz dom0_mem=256M" + menu=Xen:load /netbsd-XEN3_DOM0.gz console=pc;multiboot /xen.gz dom0_mem=256M which specifies that the dom0 should have 256M, leaving the rest to be -allocated for domUs. +allocated for domUs. In an attempt to add performance, one can also +add + + dom0_max_vcpus=1 dom0_vcpus_pin + +to force only one vcpu to be provided (since NetBSD dom0 can't use +more) and to pin that vcpu to a physical cpu. TODO: benchmark this. As with non-Xen systems, you should have a line to boot /netbsd (a kernel that works without Xen) and fallback versions of the non-Xen kernel, Xen, and the dom0 kernel. +The [HowTo on Installing into +RAID-1](http://mail-index.NetBSD.org/port-xen/2006/03/01/0010.html) +explains how to set up booting a dom0 with Xen using grub with +NetBSD's RAIDframe. (This is obsolete with the use of NetBSD's native +boot.) + Configuring Xen --------------- Now, you have a system that will boot Xen and the dom0 kernel, and just run the dom0 kernel. There will be no domUs, and none can be -started because you still have to configure the dom0 tools. +started because you still have to configure the dom0 tools. The +daemons which should be run vary with Xen version and with whether one +is using xm or xl. Note that xend is for supporting "xm", and should +only be used if you plan on using "xm". Do NOT enable xend if you +plan on using "xl" as it will cause problems. + +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 +installed 4.1 or 4.2): + + xend=YES + xenbackendd=YES + +For 4.1 (and thus xm; xl is believed not to work well), add to rc.conf: + + xend=YES + xencommons=YES -For 3.3 (and probably 3.1), add to rc.conf (but note that you should -have installed 4.2): - xend=YES - xenbackendd=YES - -For 4.1 and 4.2, add to rc.conf: - xend=YES - xencommons=YES - -Note that xend is for supporting "xm", and should only be used if -you plan on using "xm". Do NOT enable xend if you plan on using -"xl" as it will cause problems. +TODO: Explain why if xm is preferred on 4.1, rc.d/xendomains has xl. +Or fix the package. + +For 4.2 with xm, add to rc.conf + + xend=YES + xencommons=YES + +For 4.2 with xl (preferred), add to rc.conf: + + TODO: explain if there is a xend replacement + xencommons=YES + +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 Updating NetBSD in a dom0 ------------------------- @@ -298,8 +365,102 @@ Ensure that the contents of /etc/rc.d/xe correct set of daemons. Ensure that the domU config files are valid for the new version. -Creating unprivileged domains (domU) -==================================== + +Unprivileged domains (domU) +=========================== + +This section describes general concepts about domUs. It does not +address specific domU operating systems or how to install them. The +config files for domUs are typically in /usr/pkg/etc/xen, and are +typically named so that the file anme, domU name and the domU's host +name match. + +The domU is provided with cpu and memory by Xen, configured by the +dom0. The domU is provided with disk and network by the dom0, +mediated by Xen, and configured in the dom0. + +Entropy in domUs can be an issue; physical disks and network are on +the dom0. NetBSD's /dev/random system works, but is often challenged. + +CPU and memory +-------------- + +A domain is provided with some number of vcpus, less than the +number of cpus seen by the hypervisor. For a dom0, this is controlled +by the boot argument "dom0_max_vcpus=1". For a domU, it is controlled +from the config file. + +A domain is provided with memory, In the straightforward case, the sum +of the the memory allocated to the dom0 and all domUs must be less +than the available memory. + +Xen also provides a "balloon" driver, which can be used to let domains +use more memory temporarily. TODO: Explain better, and explain how +well it works with NetBSD. + +Virtual disks +------------- + +With the file/vnd style, typically one creates a directory, +e.g. /u0/xen, on a disk large enough to hold virtual disks for all +domUs. Then, for each domU disk, one writes zeros to a file that then +serves to hold the virtual disk's bits; a suggested name is foo-xbd0 +for the first virtual disk for the domU called foo. Writing zeros to +the file serves two purposes. One is that preallocating the contents +improves performance. The other is that vnd on sparse files has +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. + +With the lvm style, one creates logical devices. They are then used +similarly to vnds. + +Virtual Networking +------------------ + +TODO: explain xvif concept, and that it's general. + +There are two normal styles: bridging and NAT. + +With bridging, the domU perceives itself to be on the same network as +the dom0. For server virtualization, this is usually best. + +With NAT, the domU perceives itself to be behind a NAT running on the +dom0. This is often appropriate when running Xen on a workstation. + +One can construct arbitrary other configurations, but there is no +script support. + +Sizing domains +-------------- + +Modern x86 hardware has vast amounts of resources. However, many +virtual servers can function just fine on far less. A system with +256M of RAM and a 4G disk can be a reasonable choice. Note that it is +far easier to adjust virtual resources than physical ones. For +memory, it's just a config file edit and a reboot. For disk, one can +create a new file and vnconfig it (or lvm), and then dump/restore, +just like updating physical disks, but without having to be there and +without those pesky connectors. + +Config files +------------ + +TODO: give example config files. Use both lvm and vnd. + +TODO: explain the mess with 3 arguments for disks and how to cope (0x1). + +Starting domains +---------------- + +TODO: Explain "xm start" and "xl start". Explain rc.d/xendomains. + +TODO: Explain why 4.1 rc.d/xendomains has xl, when one should use xm +on 4.1. + +Creating specific unprivileged domains (domU) +============================================= Creating domUs is almost entirely independent of operating system. We first explain NetBSD, and then differences for Linux and Solaris. @@ -447,7 +608,7 @@ working vif-bridge is also provided with #!/bin/sh #============================================================================ - # $NetBSD: howto.mdwn,v 1.26 2014/12/24 01:38:26 gdt Exp $ + # $NetBSD: howto.mdwn,v 1.36 2014/12/24 16:02:49 gdt Exp $ # # /usr/pkg/etc/xen/vif-bridge # @@ -824,13 +985,16 @@ to use PCI devices in a domU. Here's a k sd* at scsibus? target ? lun ? # SCSI disk drives cd* at scsibus? target ? lun ? # SCSI CD-ROM drives -Links and further information -============================= -- The [HowTo on Installing into RAID-1](http://mail-index.NetBSD.org/port-xen/2006/03/01/0010.html) - explains how to set up booting a dom0 with Xen using grub - with NetBSD's RAIDframe. (This is obsolete with the use of - NetBSD's native boot.) -- An example of how to use NetBSD's native bootloader to load - NetBSD/Xen instead of Grub can be found in the i386/amd64 boot(8) - and boot.cfg(5) manpages. +NetBSD as a domU in a VPS +========================= + +The bulk of the HOWTO is about using NetBSD as a dom0 on your own +hardware. This section explains how to deal with Xen in a domU as a +virtual private server where you do not control or have access to the +dom0. + +TODO: Perhaps reference panix, prmgr, amazon as interesting examples. + +TODO: Somewhere, discuss pvgrub and py-grub to load the domU kernel +from the domU filesystem.