--- wikisrc/ports/xen/howto.mdwn 2014/12/23 23:08:37 1.10 +++ wikisrc/ports/xen/howto.mdwn 2014/12/24 00:06:01 1.16 @@ -1,61 +1,135 @@ - - - - - - - -

Table Of Contents

-
    -
  • Introduction
    • -
  • Installing NetBSD as privileged domain (Dom0)
    • -
  • Creating an unprivileged NetBSD domain (DomU)
    • -
  • Creating an unprivileged Linux domain (DomU)
    • -
  • Creating an unprivileged Solaris domain (DomU)
    • -
  • Using PCI devices in guest domains
    • -
  • Links and further information
    • -
- Introduction ------------- +============ [![[Xen screenshot]](http://www.netbsd.org/gallery/in-Action/hubertf-xens.png)](../../gallery/in-Action/hubertf-xen.png) -Xen is a virtual machine monitor for x86 hardware (requires i686-class -CPUs), which supports running multiple guest operating systems on a -single machine. Guest OSes (also called “domains”) require a modified -kernel which supports Xen hypercalls in replacement to access to the -physical hardware. At boot, the Xen kernel (also known as the Xen -hypervisor) is loaded (via the bootloader) along with the guest kernel -for the first domain (called *domain0*). The Xen kernel has to be loaded -using the multiboot protocol. You would use the NetBSD boot loader for -this, or alternatively the `grub` boot loader (`grub` has some -limitations, detailed below). *domain0* has special privileges to access -the physical hardware (PCI and ISA devices), administrate other domains -and provide virtual devices (disks and network) to other domains that -lack those privileges. For more details, see [](http://www.xen.org/). - -NetBSD can be used for both *domain0 (Dom0)* and further, unprivileged -(DomU) domains. (Actually there can be multiple privileged domains -accessing different parts of the hardware, all providing virtual devices -to unprivileged domains. We will only talk about the case of a single -privileged domain, *domain0*). *domain0* will see physical devices much -like a regular i386 or amd64 kernel, and will own the physical console -(VGA or serial). Unprivileged domains will only see a character-only -virtual console, virtual disks (`xbd`) and virtual network interfaces -(`xennet`) provided by a privileged domain (usually *domain0*). xbd -devices are connected to a block device (i.e., a partition of a disk, -raid, ccd, ... device) in the privileged domain. xennet devices are -connected to virtual devices in the privileged domain, named -xvif\.\, e.g., xvif1.0. Both -xennet and xvif devices are seen as regular Ethernet devices (they can -be seen as a crossover cable between 2 PCs) and can be assigned -addresses (and be routed or NATed, filtered using IPF, etc ...) or be -added as part of a bridge. +Xen is a virtual machine monitor or hypervisor for x86 hardware +(i686-class or higher), which supports running multiple guest +operating systems on a single physical machine. With Xen, one uses +the Xen kernel to control the CPU, memory and console, a dom0 +operating system which mediates access to other hardware (e.g., disks, +network, USB), and one or more domU operating systems which operate in +an unprivileged virtualized environment. IO requests from the domU +systems are forwarded by the hypervisor (Xen) to the dom0 to be +fulfilled. + +Xen supports two styles of guests. The original is Para-Virtualized +(PV) which means that the guest OS does not attempt to access hardware +directly, but instead makes hypercalls to the hypervisor. This is +analogous to a user-space program making system calls. (The dom0 +operating system uses PV calls for some functions, such as updating +memory mapping page tables, but has direct hardware access for disk +and network.) PV guests must be specifically coded for Xen. + +The more recent style is HVM, which means that the guest does not have +code for Xen and need not be aware that it is running under Xen. +Attempts to access hardware registers are trapped and emulated. This +style is less efficient but can run unmodified guests. + +At boot, the dom0 kernel is loaded as module with Xen as the kernel. +The dom0 can start one or more domUs. (Booting is explained in detail +in the dom0 section.) + +NetBSD supports Xen in that it can serve as dom0, be used as a domU, +and that Xen kernels and tools are available in pkgsrc. This HOWTO +attempts to address both the case of running a NetBSD dom0 on hardware +and running NetBSD as a domU in a VPS. + +Prerequisites +------------- + +Installing NetBSD/Xen is not extremely difficult, but it is more +complex than a normal installation of NetBSD. +In general, this HOWTO is occasionally overly restrictive about how +things must be done, guiding the reader to stay on the established +path when there are no known good reasons to stray. + +This HOWTO presumes a basic familiarity with the Xen system +architecture. This HOWTO presumes familiarity with installing NetBSD +on i386/amd64 hardware and installing software from pkgsrc. + +See also the [Xen website](http://www.xen.org/). + +Versions of Xen and NetBSD +========================== + +Most of the installation concepts and instructions are independent of +Xen version. This section gives advice on which version to choose. +Versions not in pkgsrc and older unsupported versions of NetBSD are +inentionally ignored. + +Xen +--- + +In NetBSD, xen is provided in pkgsrc, via matching pairs of packages +xenkernel and xentools. We will refer only to the kernel versions, +but note that both packages must be installed together and must have +matching versions. + +xenkernel3 and xenkernel33 provide Xen 3.1 and 3.3. These no longer +receive security patches and should not be used. + +xenkernel41 provides Xen 4.1. This is no longer maintained by Xen, +but as of 2014-12 receives backported security patches. It is a +reasonable although trailing-edge choice. + +xenkernel42 provides Xen 4.2. This is maintained by Xen, but old as +of 2014-12. + +Ideally newer versions of Xen will be added to pkgsrc. + +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. + +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 +need SMP; the lack of support is really a problem when using a dom0 as +a normal computer.) + +Recommendation +-------------- + +Therefore, this HOWTO recommends running xenkernel42 (and xentools42) +and NetBSD 6 stable branch. + +NetBSD as a dom0 +================ + +NetBSD can be used as a dom0 and works very well. The following +sections address installation, updating NetBSD, and updating Xen. + +Styles of dom0 operation +------------------------ + +There are two basic ways to use Xen. The traditional method is for +the dom0 to do absolutely nothing other than providing support to some +number of domUs. Such a system was probably installed for the sole +purpose of hosting domUs, and sits in a server room on a UPS. + +The other way is to put Xen under a normal-usage computer, so that the +dom0 is what the computer would have been without Xen, perhaps a +desktop or laptop. Then, one can run domUs at will. Purists will +deride this as less secure than the previous approach, and for a +computer whose purpose is to run domUs, they are right. But Xen and a +dom0 (without domUs) is not meaingfully less secure than the same +things running without Xen. One can boot Xen or boot regular NetBSD +alternately with little problems, simply refraining from starting the +Xen daemons when not running Xen. -Installing NetBSD as privileged domain (Dom0) ---------------------------------------------- +Note that NetBSD as dom0 does not support multiple CPUs. This will +limit the performance of the Xen/dom0 workstation approach. + +Installation of NetBSD and Xen +------------------------------ + +Note that it doesn't make sense to talk about installing a dom0 OS +without also installing Xen itself. First do a NetBSD/i386 or NetBSD/amd64 [installation](../../docs/guide/en/chap-inst.html) of the 5.1 release @@ -211,7 +285,29 @@ Install grub with the following command: Done. -Creating an unprivileged NetBSD domain (DomU) +Updating NetBSD in a dom0 +------------------------- + +This is just like updating NetBSD on bare hardware, assuming the new +version supports the version of Xen you are running. Generally, one +replaces the kernel and reboots, and then overlays userland binaries +and adjusts /etc. + +Note that one must update both the non-Xen kernel typically used for +rescue purposes and the DOM0 kernel used with Xen. + +Updating Xen versions +--------------------- + +TODO: write + +Creating unprivileged domains (domU) +==================================== + +Creating domUs is almost entirely independent of operating system. We +first explain NetBSD, and then differences for Linux and Solaris. + +Creating an unprivileged NetBSD domain (domU) --------------------------------------------- Once you have *domain0* running, you need to start the xen tool daemon @@ -354,7 +450,7 @@ working vif-bridge is also provided with #!/bin/sh #============================================================================ - # $NetBSD: howto.mdwn,v 1.9 2014/12/23 23:04:29 gdt Exp $ + # $NetBSD: howto.mdwn,v 1.15 2014/12/24 00:04:47 gdt Exp $ # # /usr/pkg/etc/xen/vif-bridge # @@ -478,7 +574,7 @@ in rc.conf. This way, the domain will be Your domain should be now ready to work, enjoy. -Creating an unprivileged Linux domain (DomU) +Creating an unprivileged Linux domain (domU) -------------------------------------------- Creating unprivileged Linux domains isn't much different from @@ -522,7 +618,7 @@ To get the linux console right, you need to your configuration since not all linux distributions auto-attach a tty to the xen console. -Creating an unprivileged Solaris domain (DomU) +Creating an unprivileged Solaris domain (domU) ---------------------------------------------- Download an Opensolaris [release](http://opensolaris.org/os/downloads/) @@ -659,7 +755,7 @@ Restart the guest to verify it works cor Using PCI devices in guest domains -================================== +---------------------------------- The domain0 can give other domains access to selected PCI devices. This can allow, for example, a non-privileged domain to have access to a