--- 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