--- wikisrc/ports/xen/howto.mdwn 2014/12/24 15:31:36 1.32 +++ wikisrc/ports/xen/howto.mdwn 2014/12/24 16:06:38 1.37 @@ -152,6 +152,24 @@ Therefore, this HOWTO recommends running 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 ================ @@ -251,10 +269,16 @@ 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 @@ -285,20 +309,34 @@ installed 4.1 or 4.2): xend=YES xenbackendd=YES -For 4.1 (and thus xm), add to rc.conf: +For 4.1 (and thus xm; xl is believed not to work well), add to rc.conf: xend=YES xencommons=YES 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, add to rc.conf: +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 ------------------------- @@ -332,19 +370,51 @@ Unprivileged domains (domU) =========================== This section describes general concepts about domUs. It does not -address specific domU operating systems or how to install them. - -Provided Resources for PV domains ---------------------------------- - -TODO: Explain that domUs get cpu, memory, disk and network. -Explain that randomness can be an issue. +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 ------------- -TODO: Explain how to set up files for vnd and that one should write all zeros to preallocate. -TODO: Explain in what NetBSD versions sparse vnd files do and don't work. +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 ------------------ @@ -362,6 +432,18 @@ dom0. This is often appropriate when ru 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 ------------ @@ -526,7 +608,7 @@ working vif-bridge is also provided with #!/bin/sh #============================================================================ - # $NetBSD: howto.mdwn,v 1.31 2014/12/24 15:30:45 gdt Exp $ + # $NetBSD: howto.mdwn,v 1.36 2014/12/24 16:02:49 gdt Exp $ # # /usr/pkg/etc/xen/vif-bridge #