|
version 1.4, 2013/10/31 14:14:13
|
version 1.15, 2014/12/24 00:04:47
|
|
Line 1
|
Line 1
|
| NetBSD/xen Howto |
Introduction |
| ================ |
============ |
| |
|
| [](../../about/disclaimer.html#bsd-daemon) |
screenshot]](http://www.netbsd.org/gallery/in-Action/hubertf-xens.png)](../../gallery/in-Action/hubertf-xen.png) |
| |
|
| Table Of Contents |
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. |
| |
|
| |
For more details on Xen, see [](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.) |
| |
|
| - [Introduction](#introduction) |
Recommendation |
| - [Installing NetBSD as privileged domain (Dom0)](#netbsd-dom0) |
-------------- |
| - [Creating an unprivileged NetBSD domain (DomU)](#netbsd-domU) |
|
| - [Creating an unprivileged Linux domain (DomU)](#linux-domU) |
|
| - [Creating an unprivileged Solaris domain (DomU)](#solaris-domU) |
|
| - [Using PCI devices in guest domains](#pci-pass-through) |
|
| - [Links and further information](#links-and-more) |
|
| |
|
| * * * * * |
Therefore, this HOWTO recommends running xenkernel42 (and xentools42) |
| |
and NetBSD 6 stable branch. |
| |
|
| ### Introduction |
NetBSD as a dom0 |
| |
================ |
| |
|
| [![[Xen |
NetBSD can be used as a dom0 and works very well. The following |
| screenshot]](../../gallery/in-Action/hubertf-xens.png)](../../gallery/in-Action/hubertf-xen.png) |
sections address installation, updating NetBSD, and updating Xen. |
| |
|
| |
Styles of dom0 operation |
| |
------------------------ |
| |
|
| Xen is a virtual machine monitor for x86 hardware (requires i686-class |
There are two basic ways to use Xen. The traditional method is for |
| CPUs), which supports running multiple guest operating systems on a |
the dom0 to do absolutely nothing other than providing support to some |
| single machine. Guest OSes (also called <E2><80><9C>domains<E2><80><9D>) require a modified |
number of domUs. Such a system was probably installed for the sole |
| kernel which supports Xen hypercalls in replacement to access to the |
purpose of hosting domUs, and sits in a server room on a UPS. |
| physical hardware. At boot, the Xen kernel (also known as the Xen |
|
| hypervisor) is loaded (via the bootloader) along with the guest kernel |
The other way is to put Xen under a normal-usage computer, so that the |
| for the first domain (called *domain0*). The Xen kernel has to be loaded |
dom0 is what the computer would have been without Xen, perhaps a |
| using the multiboot protocol. You would use the NetBSD boot loader for |
desktop or laptop. Then, one can run domUs at will. Purists will |
| this, or alternatively the **grub** boot loader (**grub** has some |
deride this as less secure than the previous approach, and for a |
| limitations, detailed below). *domain0* has special privileges to access |
computer whose purpose is to run domUs, they are right. But Xen and a |
| the physical hardware (PCI and ISA devices), administrate other domains |
dom0 (without domUs) is not meaingfully less secure than the same |
| and provide virtual devices (disks and network) to other domains that |
things running without Xen. One can boot Xen or boot regular NetBSD |
| lack those privileges. For more details, see |
alternately with little problems, simply refraining from starting the |
| [http://www.xen.org/](http://www.xen.org/). |
Xen daemons when not running Xen. |
| |
|
| 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`{.code}) and virtual network |
|
| interfaces (`xennet`{.code}) 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\<domain number\>.\<if number for this domain\>, 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. |
|
| |
|
| * * * * * |
Note that NetBSD as dom0 does not support multiple CPUs. This will |
| ### Installing NetBSD as privileged domain (Dom0) |
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 |
First do a NetBSD/i386 or NetBSD/amd64 |
| [installation](../../docs/guide/en/chap-inst.html) of the 5.1 release |
[installation](../../docs/guide/en/chap-inst.html) of the 5.1 release |
| (or newer) as you usually do on x86 hardware. The binary releases are |
(or newer) as you usually do on x86 hardware. The binary releases are |
| available from |
available from [](ftp://ftp.NetBSD.org/pub/NetBSD/). Binary snapshots |
| [ftp://ftp.NetBSD.org/pub/NetBSD/](ftp://ftp.NetBSD.org/pub/NetBSD/). |
for current and the stable branches are available on daily autobuilds. |
| Binary snapshots for current and the stable branches are available on |
If you plan to use the `grub` boot loader, when partitioning the disk |
| [daily autobuilds](http://nyftp.NetBSD.org/pub/NetBSD-daily/). If you |
you have to make the root partition smaller than 512Mb, and formatted as |
| plan to use the **grub** boot loader, when partitioning the disk you |
|
| have to make the root partition smaller than 512Mb, and formatted as |
|
| FFSv1 with 8k block/1k fragments. If the partition is larger than this, |
FFSv1 with 8k block/1k fragments. If the partition is larger than this, |
| uses FFSv2 or has different block/fragment sizes, grub may fail to load |
uses FFSv2 or has different block/fragment sizes, grub may fail to load |
| some files. Also keep in mind that you'll probably want to provide |
some files. Also keep in mind that you'll probably want to provide |
|
Line 80 packages. See [the pkgsrc
|
Line 153 packages. See [the pkgsrc
|
| documentation](http://www.NetBSD.org/docs/pkgsrc/) if you are unfamiliar |
documentation](http://www.NetBSD.org/docs/pkgsrc/) if you are unfamiliar |
| with pkgsrc and/or handling of binary packages. Xen 3.1, 3.3, 4.1 and |
with pkgsrc and/or handling of binary packages. Xen 3.1, 3.3, 4.1 and |
| 4.2 are available. 3.1 supports PCI pass-through while other versions do |
4.2 are available. 3.1 supports PCI pass-through while other versions do |
| not. You'll need either |
not. You'll need either `sysutils/xentools3` and `sysutils/xenkernel3` |
| [`sysutils/xentools3`{.filename}](http://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/sysutils/xentools3/README.html) |
for Xen 3.1, `sysutils/xentools33` and `sysutils/xenkernel33` for Xen |
| and |
3.3, `sysutils/xentools41` and `sysutils/xenkernel41` for Xen 4.1. or |
| [`sysutils/xenkernel3`{.filename}](http://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/sysutils/xenkernel3/README.html) |
`sysutils/xentools42` and `sysutils/xenkernel42` for Xen 4.2. You'll |
| for Xen 3.1, |
also need `sysutils/grub` if you plan do use the grub boot loader. If |
| [`sysutils/xentools33`{.filename}](http://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/sysutils/xentools33/README.html) |
using Xen 3.1, you may also want to install `sysutils/xentools3-hvm` |
| and |
|
| [`sysutils/xenkernel33`{.filename}](http://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/sysutils/xenkernel33/README.html) |
|
| for Xen 3.3, |
|
| [`sysutils/xentools41`{.filename}](http://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/sysutils/xentools41/README.html) |
|
| and |
|
| [`sysutils/xenkernel41`{.filename}](http://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/sysutils/xenkernel41/README.html) |
|
| for Xen 4.1. or |
|
| [`sysutils/xentools42`{.filename}](http://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/sysutils/xentools42/README.html) |
|
| and |
|
| [`sysutils/xenkernel42`{.filename}](http://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/sysutils/xenkernel42/README.html) |
|
| for Xen 4.2. You'll also need |
|
| [`sysutils/grub`{.filename}](http://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/sysutils/grub/README.html) |
|
| if you plan do use the grub boot loader. If using Xen 3.1, you may also |
|
| want to install |
|
| [`sysutils/xentools3-hvm`{.filename}](http://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/sysutils/xentools3-hvm/README.html) |
|
| which contains the utilities to run unmodified guests OSes using the |
which contains the utilities to run unmodified guests OSes using the |
| *HVM* support (for later versions this is included in |
*HVM* support (for later versions this is included in |
| [`sysutils/xentools`{.filename}](http://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/sysutils/xentools/README.html)). |
`sysutils/xentools`). Note that your CPU needs to support this. Intel |
| Note that your CPU needs to support this. Intel CPUs must have the 'VT' |
CPUs must have the 'VT' instruction, AMD CPUs the 'SVM' instruction. You |
| instruction, AMD CPUs the 'SVM' instruction. You can easily find out if |
can easily find out if your CPU support HVM by using NetBSD's cpuctl |
| your CPU support HVM by using NetBSD's cpuctl command: |
command: |
| |
|
| # cpuctl identify 0 |
# cpuctl identify 0 |
| cpu0: Intel Core 2 (Merom) (686-class), id 0x6f6 |
cpu0: Intel Core 2 (Merom) (686-class), id 0x6f6 |
| cpu0: features 0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR> |
cpu0: features 0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR> |
| cpu0: features 0xbfebfbff<PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX> |
cpu0: features 0xbfebfbff<PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX> |
| cpu0: features 0xbfebfbff<FXSR,SSE,SSE2,SS,HTT,TM,SBF> |
cpu0: features 0xbfebfbff<FXSR,SSE,SSE2,SS,HTT,TM,SBF> |
| cpu0: features2 0x4e33d<SSE3,DTES64,MONITOR,DS-CPL,VMX,TM2,SSSE3,CX16,xTPR,PDCM,DCA> |
cpu0: features2 0x4e33d<SSE3,DTES64,MONITOR,DS-CPL,,TM2,SSSE3,CX16,xTPR,PDCM,DCA> |
| cpu0: features3 0x20100800<SYSCALL/SYSRET,XD,EM64T> |
cpu0: features3 0x20100800<SYSCALL/SYSRET,XD,EM64T> |
| cpu0: "Intel(R) Xeon(R) CPU 5130 @ 2.00GHz" |
cpu0: "Intel(R) Xeon(R) CPU 5130 @ 2.00GHz" |
| cpu0: I-cache 32KB 64B/line 8-way, D-cache 32KB 64B/line 8-way |
cpu0: I-cache 32KB 64B/line 8-way, D-cache 32KB 64B/line 8-way |
|
Line 129 Depending on your CPU, the feature you a
|
Line 187 Depending on your CPU, the feature you a
|
| SVM or VMX. |
SVM or VMX. |
| |
|
| Next you need to copy the selected Xen kernel itself. pkgsrc installed |
Next you need to copy the selected Xen kernel itself. pkgsrc installed |
| them under `/usr/pkg/xen*-kernel/`{.filename}. The file you're looking |
them under `/usr/pkg/xen*-kernel/`. The file you're looking for is |
| for is `xen.gz`{.filename}. Copy it to your root file system. |
`xen.gz`. Copy it to your root file system. `xen-debug.gz` is a kernel |
| `xen-debug.gz`{.filename} is a kernel with more consistency checks and |
with more consistency checks and more details printed on the serial |
| more details printed on the serial console. It is useful for debugging |
console. It is useful for debugging crashing guests if you use a serial |
| crashing guests if you use a serial console. It is not useful with a VGA |
console. It is not useful with a VGA console. |
| console. |
|
| |
|
| You'll then need a NetBSD/Xen kernel for *domain0* on your root file |
You'll then need a NetBSD/Xen kernel for *domain0* on your root file |
| system. The XEN3PAE\_DOM0 kernel or XEN3\_DOM0 provided as part of the |
system. The XEN3PAE\_DOM0 kernel or XEN3\_DOM0 provided as part of the |
| i386 or amd64 binaries is suitable for this, but you may want to |
i386 or amd64 binaries is suitable for this, but you may want to |
| customize it. Keep your native kernel around, as it can be useful for |
customize it. Keep your native kernel around, as it can be useful for |
| recovery. *Note:* the *domain0* kernel must support KERNFS and |
recovery. *Note:* the *domain0* kernel must support KERNFS and `/kern` |
| `/kern`{.filename} must be mounted because *xend* needs access to |
must be mounted because *xend* needs access to `/kern/xen/privcmd`. |
| `/kern/xen/privcmd`{.filename}. |
|
| |
Next you need to get a bootloader to load the `xen.gz` kernel, and the |
| Next you need to get a bootloader to load the `xen.gz`{.filename} |
NetBSD *domain0* kernel as a module. This can be `grub` or NetBSD's boot |
| kernel, and the NetBSD *domain0* kernel as a module. This can be |
loader. Below is a detailled example for grub, see the boot.cfg(5) |
| **grub** or NetBSD's boot loader. Below is a detailled example for grub, |
manual page for an example using the latter. |
| see the boot.cfg(5) manual page for an example using the latter. |
|
| |
|
| This is also where you'll specify the memory allocated to *domain0*, the |
This is also where you'll specify the memory allocated to *domain0*, the |
| console to use, etc ... |
console to use, etc ... |
| |
|
| Here is a commented `/grub/menu.lst`{.filename} file: |
Here is a commented `/grub/menu.lst` file: |
| |
|
| #Grub config file for NetBSD/xen. Copy as /grub/menu.lst and run |
#Grub config file for NetBSD/xen. Copy as /grub/menu.lst and run |
| # grub-install /dev/rwd0d (assuming your boot device is wd0). |
# grub-install /dev/rwd0d (assuming your boot device is wd0). |
| # |
# |
| # The default entry to load will be the first one |
# The default entry to load will be the first one |
| default=0 |
default=0 |
| |
|
| # boot the default entry after 10s if the user didn't hit keyboard |
# boot the default entry after 10s if the user didn't hit keyboard |
| timeout=10 |
timeout=10 |
| |
|
| # Configure serial port to use as console. Ignore if you'll use VGA only |
# Configure serial port to use as console. Ignore if you'll use VGA only |
| serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1 |
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1 |
| |
|
| # Let the user select which console to use (serial or VGA), default |
# Let the user select which console to use (serial or VGA), default |
| # to serial after 10s |
# to serial after 10s |
| terminal --timeout=10 serial console |
terminal --timeout=10 serial console |
| |
|
| # An entry for NetBSD/xen, using /netbsd as the domain0 kernel, and serial |
# An entry for NetBSD/xen, using /netbsd as the domain0 kernel, and serial |
| # console. Domain0 will have 64MB RAM allocated. |
# console. Domain0 will have 64MB RAM allocated. |
| # Assume NetBSD is installed in the first MBR partition. |
# Assume NetBSD is installed in the first MBR partition. |
|
Line 177 Here is a commented `/grub/menu.lst`{.fi
|
Line 233 Here is a commented `/grub/menu.lst`{.fi
|
| root(hd0,0) |
root(hd0,0) |
| kernel (hd0,a)/xen.gz dom0_mem=65536 com1=115200,8n1 |
kernel (hd0,a)/xen.gz dom0_mem=65536 com1=115200,8n1 |
| module (hd0,a)/netbsd bootdev=wd0a ro console=ttyS0 |
module (hd0,a)/netbsd bootdev=wd0a ro console=ttyS0 |
| |
|
| # Same as above, but using VGA console |
# Same as above, but using VGA console |
| # We can use console=tty0 (Linux syntax) or console=pc (NetBSD syntax) |
# We can use console=tty0 (Linux syntax) or console=pc (NetBSD syntax) |
| title Xen 3 / NetBSD (hda0, vga) |
title Xen 3 / NetBSD (hda0, vga) |
| root(hd0,0) |
root(hd0,0) |
| kernel (hd0,a)/xen.gz dom0_mem=65536 |
kernel (hd0,a)/xen.gz dom0_mem=65536 |
| module (hd0,a)/netbsd bootdev=wd0a ro console=tty0 |
module (hd0,a)/netbsd bootdev=wd0a ro console=tty0 |
| |
|
| # NetBSD/xen using a backup domain0 kernel (in case you installed a |
# NetBSD/xen using a backup domain0 kernel (in case you installed a |
| # nonworking kernel as /netbsd |
# nonworking kernel as /netbsd |
| title Xen 3 / NetBSD (hda0, backup, serial) |
title Xen 3 / NetBSD (hda0, backup, serial) |
|
Line 195 Here is a commented `/grub/menu.lst`{.fi
|
Line 251 Here is a commented `/grub/menu.lst`{.fi
|
| root(hd0,0) |
root(hd0,0) |
| kernel (hd0,a)/xen.gz dom0_mem=65536 |
kernel (hd0,a)/xen.gz dom0_mem=65536 |
| module (hd0,a)/netbsd.backup bootdev=wd0a ro console=tty0 |
module (hd0,a)/netbsd.backup bootdev=wd0a ro console=tty0 |
| |
|
| #Load a regular NetBSD/i386 kernel. Can be useful if you end up with a |
#Load a regular NetBSD/i386 kernel. Can be useful if you end up with a |
| #nonworking /xen.gz |
#nonworking /xen.gz |
| title NetBSD 5.1 |
title NetBSD 5.1 |
| root (hd0,a) |
root (hd0,a) |
| kernel --type=netbsd /netbsd-GENERIC |
kernel --type=netbsd /netbsd-GENERIC |
| |
|
| #Load the NetBSD bootloader, letting it load the NetBSD/i386 kernel. |
#Load the NetBSD bootloader, letting it load the NetBSD/i386 kernel. |
| #May be better than the above, as grub can't pass all required infos |
#May be better than the above, as grub can't pass all required infos |
| #to the NetBSD/i386 kernel (e.g. console, root device, ...) |
#to the NetBSD/i386 kernel (e.g. console, root device, ...) |
| title NetBSD chain |
title NetBSD chain |
| root (hd0,0) |
root (hd0,0) |
| chainloader +1 |
chainloader +1 |
| |
|
| ## end of grub config file. |
## end of grub config file. |
| |
|
| |
|
| Install grub with the following command: |
Install grub with the following command: |
| |
|
| # grub --no-floppy |
# grub --no-floppy |
| |
|
| grub> root (hd0,a) |
grub> root (hd0,a) |
| Filesystem type is ffs, partition type 0xa9 |
Filesystem type is ffs, partition type 0xa9 |
| |
|
| grub> setup (hd0) |
grub> setup (hd0) |
| Checking if "/boot/grub/stage1" exists... no |
Checking if "/boot/grub/stage1" exists... no |
| Checking if "/grub/stage1" exists... yes |
Checking if "/grub/stage1" exists... yes |
|
Line 228 Install grub with the following command:
|
Line 285 Install grub with the following command:
|
| Running "install /grub/stage1 (hd0) (hd0)1+14 p (hd0,0,a)/grub/stage2 /grub/menu.lst"... |
Running "install /grub/stage1 (hd0) (hd0)1+14 p (hd0,0,a)/grub/stage2 /grub/menu.lst"... |
| succeeded |
succeeded |
| Done. |
Done. |
| |
|
| |
|
| |
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) |
Creating an unprivileged NetBSD domain (domU) |
| |
--------------------------------------------- |
| |
|
| Once you have *domain0* running, you need to start the xen tool daemon |
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/xend start`) and the xen backend daemon |
| (**/usr/pkg/share/examples/rc.d/xenbackendd start** for Xen3\*, |
(`/usr/pkg/share/examples/rc.d/xenbackendd start` for Xen3\*, |
| **/usr/pkg/share/examples/rc.d/xencommons start** for Xen4.\*). Make |
`/usr/pkg/share/examples/rc.d/xencommons start` for Xen4.\*). Make sure |
| sure that `/dev/xencons`{.filename} and `/dev/xenevt`{.filename} exist |
that `/dev/xencons` and `/dev/xenevt` exist before starting `xend`. You |
| before starting **xend**. You can create them with this command: |
can create them with this command: |
| |
|
| # cd /dev && sh MAKEDEV xen |
# cd /dev && sh MAKEDEV xen |
| |
|
| xend will write logs to `/var/log/xend.log`{.filename} and |
xend will write logs to `/var/log/xend.log` and |
| `/var/log/xend-debug.log`{.filename}. You can then control xen with the |
`/var/log/xend-debug.log`. You can then control xen with the xm tool. |
| xm tool. 'xm list' will show something like: |
'xm list' will show something like: |
| |
|
| # xm list |
# xm list |
| Name Id Mem(MB) CPU State Time(s) Console |
Name Id Mem(MB) CPU State Time(s) Console |
|
Line 252 xm tool. 'xm list' will show something l
|
Line 331 xm tool. 'xm list' will show something l
|
| |
|
| 'xm create' allows you to create a new domain. It uses a config file in |
'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 |
PKG\_SYSCONFDIR for its parameters. By default, this file will be in |
| `/usr/pkg/etc/xen/`{.filename}. On creation, a kernel has to be |
`/usr/pkg/etc/xen/`. On creation, a kernel has to be specified, which |
| specified, which will be executed in the new domain (this kernel is in |
will be executed in the new domain (this kernel is in the *domain0* file |
| the *domain0* file system, not on the new domain virtual disk; but |
system, not on the new domain virtual disk; but please note, you should |
| please note, you should install the same kernel into *domainU* as |
install the same kernel into *domainU* as `/netbsd` in order to make |
| `/netbsd`{.filename} in order to make your system tools, like |
your system tools, like MAN.SAVECORE.8, work). A suitable kernel is |
| [savecore(8)](http://netbsd.gw.com/cgi-bin/man-cgi?savecore+8+NetBSD-6.0+i386), |
provided as part of the i386 and amd64 binary sets: XEN3\_DOMU. |
| work). A suitable kernel is provided as part of the i386 and amd64 |
|
| binary sets: XEN3\_DOMU. |
|
| |
|
| Here is an /usr/pkg/etc/xen/nbsd example config file: |
Here is an /usr/pkg/etc/xen/nbsd example config file: |
| |
|
|
Line 268 Here is an /usr/pkg/etc/xen/nbsd example
|
Line 345 Here is an /usr/pkg/etc/xen/nbsd example
|
| # Python defaults setup for 'xm create'. |
# Python defaults setup for 'xm create'. |
| # Edit this file to reflect the configuration of your system. |
# Edit this file to reflect the configuration of your system. |
| #============================================================================ |
#============================================================================ |
| |
|
| #---------------------------------------------------------------------------- |
#---------------------------------------------------------------------------- |
| # Kernel image file. This kernel will be loaded in the new domain. |
# Kernel image file. This kernel will be loaded in the new domain. |
| kernel = "/home/bouyer/netbsd-XEN3_DOMU" |
kernel = "/home/bouyer/netbsd-XEN3_DOMU" |
| #kernel = "/home/bouyer/netbsd-INSTALL_XEN3_DOMU" |
#kernel = "/home/bouyer/netbsd-INSTALL_XEN3_DOMU" |
| |
|
| # Memory allocation (in megabytes) for the new domain. |
# Memory allocation (in megabytes) for the new domain. |
| memory = 128 |
memory = 128 |
| |
|
| # A handy name for your new domain. This will appear in 'xm list', |
# A handy name for your new domain. This will appear in 'xm list', |
| # and you can use this as parameters for xm in place of the domain |
# and you can use this as parameters for xm in place of the domain |
| # number. All domains must have different names. |
# number. All domains must have different names. |
| # |
# |
| name = "nbsd" |
name = "nbsd" |
| |
|
| # The number of virtual CPUs this domain has. |
# The number of virtual CPUs this domain has. |
| # |
# |
| vcpus = 1 |
vcpus = 1 |
| |
|
| #---------------------------------------------------------------------------- |
#---------------------------------------------------------------------------- |
| # Define network interfaces for the new domain. |
# Define network interfaces for the new domain. |
| |
|
| # Number of network interfaces (must be at least 1). Default is 1. |
# Number of network interfaces (must be at least 1). Default is 1. |
| nics = 1 |
nics = 1 |
| |
|
| # Define MAC and/or bridge for the network interfaces. |
# Define MAC and/or bridge for the network interfaces. |
| # |
# |
| # The MAC address specified in ``mac'' is the one used for the interface |
# The MAC address specified in ``mac'' is the one used for the interface |
|
Line 309 Here is an /usr/pkg/etc/xen/nbsd example
|
Line 386 Here is an /usr/pkg/etc/xen/nbsd example
|
| # ``network'' script or using a /etc/ifconfig.bridge0 file. |
# ``network'' script or using a /etc/ifconfig.bridge0 file. |
| # |
# |
| vif = [ 'mac=aa:00:00:50:02:f0, bridge=bridge0' ] |
vif = [ 'mac=aa:00:00:50:02:f0, bridge=bridge0' ] |
| |
|
| #---------------------------------------------------------------------------- |
#---------------------------------------------------------------------------- |
| # Define the disk devices you want the domain to have access to, and |
# Define the disk devices you want the domain to have access to, and |
| # what you want them accessible as. |
# what you want them accessible as. |
| # |
# |
| # Each disk entry is of the form: |
# Each disk entry is of the form: |
| # |
# |
| # phy:DEV,VDEV,MODE |
# phy:DEV,VDEV,MODE |
| # |
# |
| # where DEV is the device, VDEV is the device name the domain will see, |
# where DEV is the device, VDEV is the device name the domain will see, |
| # and MODE is r for read-only, w for read-write. You can also create |
# and MODE is r for read-only, w for read-write. You can also create |
| # file-backed domains using disk entries of the form: |
# file-backed domains using disk entries of the form: |
| # |
# |
| # file:PATH,VDEV,MODE |
# file:PATH,VDEV,MODE |
| # |
# |
| # where PATH is the path to the file used as the virtual disk, and VDEV |
# where PATH is the path to the file used as the virtual disk, and VDEV |
| # and MODE have the same meaning as for ``phy'' devices. |
# and MODE have the same meaning as for ``phy'' devices. |
|
Line 335 Here is an /usr/pkg/etc/xen/nbsd example
|
Line 412 Here is an /usr/pkg/etc/xen/nbsd example
|
| # on domain0, with the major/minor from Linux :( |
# on domain0, with the major/minor from Linux :( |
| # Alternatively it's possible to specify the device number in hex, |
# Alternatively it's possible to specify the device number in hex, |
| # e.g. 0x301 for /dev/hda1, 0x302 for /dev/hda2, etc ... |
# e.g. 0x301 for /dev/hda1, 0x302 for /dev/hda2, etc ... |
| |
|
| disk = [ 'phy:/dev/wd0e,0x1,w' ] |
disk = [ 'phy:/dev/wd0e,0x1,w' ] |
| #disk = [ 'file:/var/xen/nbsd-disk,0x01,w' ] |
#disk = [ 'file:/var/xen/nbsd-disk,0x01,w' ] |
| #disk = [ 'file:/var/xen/nbsd-disk,0x301,w' ] |
#disk = [ 'file:/var/xen/nbsd-disk,0x301,w' ] |
| |
|
| #---------------------------------------------------------------------------- |
#---------------------------------------------------------------------------- |
| # Set the kernel command line for the new domain. |
# Set the kernel command line for the new domain. |
| |
|
| # Set root device. This one does matter for NetBSD |
# Set root device. This one does matter for NetBSD |
| root = "xbd0" |
root = "xbd0" |
| # extra parameters passed to the kernel |
# extra parameters passed to the kernel |
| # this is where you can set boot flags like -s, -a, etc ... |
# this is where you can set boot flags like -s, -a, etc ... |
| #extra = "" |
#extra = "" |
| |
|
| #---------------------------------------------------------------------------- |
#---------------------------------------------------------------------------- |
| # Set according to whether you want the domain restarted when it exits. |
# Set according to whether you want the domain restarted when it exits. |
| # The default is False. |
# The default is False. |
| #autorestart = True |
#autorestart = True |
| |
|
| # end of nbsd config file ==================================================== |
# end of nbsd config file ==================================================== |
| |
|
| When a new domain is created, xen calls the |
When a new domain is created, xen calls the |
| `/usr/pkg/etc/xen/vif-bridge`{.filename} script for each virtual network |
`/usr/pkg/etc/xen/vif-bridge` script for each virtual network interface |
| interface created in *domain0*. This can be used to automatically |
created in *domain0*. This can be used to automatically configure the |
| configure the xvif?.? interfaces in *domain0*. In our example, these |
xvif?.? interfaces in *domain0*. In our example, these will be bridged |
| will be bridged with the bridge0 device in *domain0*, but the bridge has |
with the bridge0 device in *domain0*, but the bridge has to exist first. |
| to exist first. To do this, create the file |
To do this, create the file `/etc/ifconfig.bridge0` and make it look |
| `/etc/ifconfig.bridge0`{.filename} and make it look like this: |
like this: |
| |
|
| create |
create |
| !brconfig $int add ex0 up |
!brconfig $int add ex0 up |
| |
|
| (replace `ex0`{.literal} with the name of your physical interface). Then |
(replace `ex0` with the name of your physical interface). Then bridge0 |
| bridge0 will be created on boot. See the |
will be created on boot. See the MAN.BRIDGE.4 man page for details. |
| [bridge(4)](http://netbsd.gw.com/cgi-bin/man-cgi?bridge+4+NetBSD-6.0+i386) |
|
| man page for details. |
|
| |
|
| So, here is a suitable `/usr/pkg/etc/xen/vif-bridge`{.filename} for |
So, here is a suitable `/usr/pkg/etc/xen/vif-bridge` for xvif?.? (a |
| xvif?.? (a working vif-bridge is also provided with xentools20) |
working vif-bridge is also provided with xentools20) configuring: |
| configuring: |
|
| |
|
| |
#!/bin/sh |
| #!/bin/sh |
|
| #============================================================================ |
#============================================================================ |
| # $NetBSD: howto.mdwn,v 1.3 2013/10/31 12:43:04 mspo Exp $ |
# $NetBSD: howto.mdwn,v 1.14 2014/12/23 23:43:27 gdt Exp $ |
| # |
# |
| # /usr/pkg/etc/xen/vif-bridge |
# /usr/pkg/etc/xen/vif-bridge |
| # |
# |
|
Line 391 configuring:
|
Line 464 configuring:
|
| # Usage: vif-bridge up|down [var=value ...] |
# Usage: vif-bridge up|down [var=value ...] |
| # |
# |
| # Actions: |
# Actions: |
| # up Adds the vif interface to the bridge. |
# up Adds the vif interface to the bridge. |
| # down Removes the vif interface from the bridge. |
# down Removes the vif interface from the bridge. |
| # |
# |
| # Variables: |
# Variables: |
| # domain name of the domain the interface is on (required). |
# domain name of the domain the interface is on (required). |
| # vifq vif interface name (required). |
# vifq vif interface name (required). |
| # mac vif MAC address (required). |
# mac vif MAC address (required). |
| # bridge bridge to add the vif to (required). |
# bridge bridge to add the vif to (required). |
| # |
# |
| # Example invocation: |
# Example invocation: |
| # |
# |
| # vif-bridge up domain=VM1 vif=xvif1.0 mac="ee:14:01:d0:ec:af" bridge=bridge0 |
# vif-bridge up domain=VM1 vif=xvif1.0 mac="ee:14:01:d0:ec:af" bridge=bridge0 |
| # |
# |
| #============================================================================ |
#============================================================================ |
| |
|
| # Exit if anything goes wrong |
# Exit if anything goes wrong |
| set -e |
set -e |
| |
|
| echo "vif-bridge $*" |
echo "vif-bridge $*" |
| |
|
| # Operation name. |
# Operation name. |
| OP=$1; shift |
OP=$1; shift |
| |
|
| # Pull variables in args into environment |
# Pull variables in args into environment |
| for arg ; do export "${arg}" ; done |
for arg ; do export "${arg}" ; done |
| |
|
| # Required parameters. Fail if not set. |
# Required parameters. Fail if not set. |
| domain=${domain:?} |
domain=${domain:?} |
| vif=${vif:?} |
vif=${vif:?} |
| mac=${mac:?} |
mac=${mac:?} |
| bridge=${bridge:?} |
bridge=${bridge:?} |
| |
|
| # Optional parameters. Set defaults. |
# Optional parameters. Set defaults. |
| ip=${ip:-''} # default to null (do nothing) |
ip=${ip:-''} # default to null (do nothing) |
| |
|
| # Are we going up or down? |
# Are we going up or down? |
| case $OP in |
case $OP in |
| up) brcmd='add' ;; |
up) brcmd='add' ;; |
| down) brcmd='delete' ;; |
down) brcmd='delete' ;; |
| *) |
*) |
| echo 'Invalid command: ' $OP |
echo 'Invalid command: ' $OP |
| echo 'Valid commands are: up, down' |
echo 'Valid commands are: up, down' |
| exit 1 |
exit 1 |
| ;; |
;; |
| esac |
esac |
| |
|
| # Don't do anything if the bridge is "null". |
# Don't do anything if the bridge is "null". |
| if [ "${bridge}" = "null" ] ; then |
if [ "${bridge}" = "null" ] ; then |
| exit |
exit |
| fi |
fi |
| |
|
| # Don't do anything if the bridge doesn't exist. |
# Don't do anything if the bridge doesn't exist. |
| if ! ifconfig -l | grep "${bridge}" >/dev/null; then |
if ! ifconfig -l | grep "${bridge}" >/dev/null; then |
| exit |
exit |
| fi |
fi |
| |
|
| # Add/remove vif to/from bridge. |
# Add/remove vif to/from bridge. |
| ifconfig x${vif} $OP |
ifconfig x${vif} $OP |
| brconfig ${bridge} ${brcmd} x${vif} |
brconfig ${bridge} ${brcmd} x${vif} |
|
Line 455 Now, running
|
Line 528 Now, running
|
| |
|
| xm create -c /usr/pkg/etc/xen/nbsd |
xm create -c /usr/pkg/etc/xen/nbsd |
| |
|
| should create a domain and load a NetBSD kernel in it. (Note: |
should create a domain and load a NetBSD kernel in it. (Note: `-c` |
| `-c`{.code} causes xm to connect to the domain's console once created.) |
causes xm to connect to the domain's console once created.) The kernel |
| The kernel will try to find its root file system on xbd0 (i.e., wd0e) |
will try to find its root file system on xbd0 (i.e., wd0e) which hasn't |
| which hasn't been created yet. wd0e will be seen as a disk device in the |
been created yet. wd0e will be seen as a disk device in the new domain, |
| new domain, so it will be 'sub-partitioned'. We could attach a ccd to |
so it will be 'sub-partitioned'. We could attach a ccd to wd0e in |
| wd0e in *domain0* and partition it, newfs and extract the NetBSD/i386 or |
*domain0* and partition it, newfs and extract the NetBSD/i386 or amd64 |
| amd64 tarballs there, but there's an easier way: load the |
tarballs there, but there's an easier way: load the |
| `netbsd-INSTALL_XEN3_DOMU`{.filename} kernel provided in the NetBSD |
`netbsd-INSTALL_XEN3_DOMU` kernel provided in the NetBSD binary sets. |
| binary sets. Like other install kernels, it contains a ramdisk with |
Like other install kernels, it contains a ramdisk with sysinst, so you |
| sysinst, so you can install NetBSD using sysinst on your new domain. |
can install NetBSD using sysinst on your new domain. |
| |
|
| If you want to install NetBSD/Xen with a CDROM image, the following line |
If you want to install NetBSD/Xen with a CDROM image, the following line |
| should be used in the `/usr/pkg/etc/xen/nbsd`{.filename} file: |
should be used in the `/usr/pkg/etc/xen/nbsd` file: |
| |
|
| disk = [ 'phy:/dev/wd0e,0x1,w', 'phy:/dev/cd0a,0x2,r' ] |
disk = [ 'phy:/dev/wd0e,0x1,w', 'phy:/dev/cd0a,0x2,r' ] |
| |
|
| After booting the domain, the option to install via CDROM may be |
After booting the domain, the option to install via CDROM may be |
| selected. The CDROM device should be changed to **xbd1d**. |
selected. The CDROM device should be changed to `xbd1d`. |
| |
|
| Once done installing, **halt -p** the new domain (don't reboot or halt, |
Once done installing, `halt -p` the new domain (don't reboot or halt, it |
| it would reload the INSTALL\_XEN3\_DOMU kernel even if you changed the |
would reload the INSTALL\_XEN3\_DOMU kernel even if you changed the |
| config file), switch the config file back to the XEN3\_DOMU kernel, and |
config file), switch the config file back to the XEN3\_DOMU kernel, and |
| start the new domain again. Now it should be able to use **root on |
start the new domain again. Now it should be able to use `root on xbd0a` |
| xbd0a** and you should have a second, functional NetBSD system on your |
and you should have a second, functional NetBSD system on your xen |
| xen installation. |
installation. |
| |
|
| When the new domain is booting you'll see some warnings about *wscons* |
When the new domain is booting you'll see some warnings about *wscons* |
| and the pseudo-terminals. These can be fixed by editing the files |
and the pseudo-terminals. These can be fixed by editing the files |
| `/etc/ttys`{.filename} and `/etc/wscons.conf`{.filename}. You must |
`/etc/ttys` and `/etc/wscons.conf`. You must disable all terminals in |
| disable all terminals in `/etc/ttys`{.filename}, except *console*, like |
`/etc/ttys`, except *console*, like this: |
| this: |
|
| |
|
| console "/usr/libexec/getty Pc" vt100 on secure |
console "/usr/libexec/getty Pc" vt100 on secure |
| ttyE0 "/usr/libexec/getty Pc" vt220 off secure |
ttyE0 "/usr/libexec/getty Pc" vt220 off secure |
|
Line 493 this:
|
Line 565 this:
|
| ttyE2 "/usr/libexec/getty Pc" vt220 off secure |
ttyE2 "/usr/libexec/getty Pc" vt220 off secure |
| ttyE3 "/usr/libexec/getty Pc" vt220 off secure |
ttyE3 "/usr/libexec/getty Pc" vt220 off secure |
| |
|
| Finally, all screens must be commented out from |
Finally, all screens must be commented out from `/etc/wscons.conf`. |
| `/etc/wscons.conf`{.filename}. |
|
| |
|
| It is also desirable to add |
It is also desirable to add |
| |
|
| powerd=YES |
powerd=YES |
| |
|
| in rc.conf. This way, the domain will be properly shut down if **xm |
in rc.conf. This way, the domain will be properly shut down if |
| shutdown -R** or **xm shutdown -H** is used on the domain0. |
`xm shutdown -R` or `xm shutdown -H` is used on the domain0. |
| |
|
| Your domain should be now ready to work, enjoy. |
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 |
Creating unprivileged Linux domains isn't much different from |
| unprivileged NetBSD domains, but there are some details to know. |
unprivileged NetBSD domains, but there are some details to know. |
|
Line 534 To install the Linux system on the parti
|
Line 604 To install the Linux system on the parti
|
| domain, the following method can be used: install sysutils/e2fsprogs |
domain, the following method can be used: install sysutils/e2fsprogs |
| from pkgsrc. Use mke2fs to format the partition that will be the root |
from pkgsrc. Use mke2fs to format the partition that will be the root |
| partition of your Linux domain, and mount it. Then copy the files from a |
partition of your Linux domain, and mount it. Then copy the files from a |
| working Linux system, make adjustments in `/etc`{.filename} (fstab, |
working Linux system, make adjustments in `/etc` (fstab, network |
| network config). It should also be possible to extract binary packages |
config). It should also be possible to extract binary packages such as |
| such as .rpm or .deb directly to the mounted partition using the |
.rpm or .deb directly to the mounted partition using the appropriate |
| appropriate tool, possibly running under NetBSD's Linux emulation. Once |
tool, possibly running under NetBSD's Linux emulation. Once the |
| the filesystem has been populated, umount it. If desirable, the |
filesystem has been populated, umount it. If desirable, the filesystem |
| filesystem can be converted to ext3 using tune2fs -j. It should now be |
can be converted to ext3 using tune2fs -j. It should now be possible to |
| possible to boot the Linux guest domain, using one of the |
boot the Linux guest domain, using one of the vmlinuz-\*-xenU kernels |
| vmlinuz-\*-xenU kernels available in the Xen binary distribution. |
available in the Xen binary distribution. |
| |
|
| To get the linux console right, you need to add: |
To get the linux console right, you need to add: |
| |
|
|
Line 550 To get the linux console right, you need
|
Line 620 To get the linux console right, you need
|
| to your configuration since not all linux distributions auto-attach a |
to your configuration since not all linux distributions auto-attach a |
| tty to the xen console. |
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/) |
Download an Opensolaris [release](http://opensolaris.org/os/downloads/) |
| or [development snapshot](http://genunix.org/) DVD image. Attach the DVD |
or [development snapshot](http://genunix.org/) DVD image. Attach the DVD |
| image to a |
image to a MAN.VND.4 device. Copy the kernel and ramdisk filesystem |
| [vnd(4)](http://netbsd.gw.com/cgi-bin/man-cgi?vnd+4+NetBSD-6.0+i386) |
image to your dom0 filesystem. |
| device. Copy the kernel and ramdisk filesystem image to your dom0 |
|
| filesystem. |
|
| |
|
| dom0# mkdir /root/solaris |
dom0# mkdir /root/solaris |
| dom0# vnconfig vnd0 osol-1002-124-x86.iso |
dom0# vnconfig vnd0 osol-1002-124-x86.iso |
| dom0# mount /dev/vnd0a /mnt |
dom0# mount /dev/vnd0a /mnt |
| |
|
| ## for a 64-bit guest |
## for a 64-bit guest |
| dom0# cp /mnt/boot/amd64/x86.microroot /root/solaris |
dom0# cp /mnt/boot/amd64/x86.microroot /root/solaris |
| dom0# cp /mnt/platform/i86xpv/kernel/amd64/unix /root/solaris |
dom0# cp /mnt/platform/i86xpv/kernel/amd64/unix /root/solaris |
| |
|
| ## for a 32-bit guest |
## for a 32-bit guest |
| dom0# cp /mnt/boot/x86.microroot /root/solaris |
dom0# cp /mnt/boot/x86.microroot /root/solaris |
| dom0# cp /mnt/platform/i86xpv/kernel/unix /root/solaris |
dom0# cp /mnt/platform/i86xpv/kernel/unix /root/solaris |
| |
|
| dom0# umount /mnt |
dom0# umount /mnt |
| |
|
| Keep the |
|
| [vnd(4)](http://netbsd.gw.com/cgi-bin/man-cgi?vnd+4+NetBSD-6.0+i386) |
Keep the MAN.VND.4 configured. For some reason the boot process stalls |
| configured. For some reason the boot process stalls unless the DVD image |
unless the DVD image is attached to the guest as a "phy" device. Create |
| is attached to the guest as a "phy" device. Create an initial |
an initial configuration file with the following contents. Substitute |
| configuration file with the following contents. Substitute */dev/wd0k* |
*/dev/wd0k* with an empty partition at least 8 GB large. |
| with an empty partition at least 8 GB large. |
|
| |
|
| memory = 640 |
memory = 640 |
| name = 'solaris' |
name = 'solaris' |
|
Line 593 with an empty partition at least 8 GB la
|
Line 659 with an empty partition at least 8 GB la
|
| extra = '/platform/i86xpv/kernel/amd64/unix - nowin -B install_media=cdrom' |
extra = '/platform/i86xpv/kernel/amd64/unix - nowin -B install_media=cdrom' |
| # for a 32-bit guest |
# for a 32-bit guest |
| #extra = '/platform/i86xpv/kernel/unix - nowin -B install_media=cdrom' |
#extra = '/platform/i86xpv/kernel/unix - nowin -B install_media=cdrom' |
| |
|
| |
|
| Start the guest. |
Start the guest. |
| |
|
| dom0# xm create -c solaris.cfg |
dom0# xm create -c solaris.cfg |
|
Line 608 Start the guest.
|
Line 675 Start the guest.
|
| WARNING: emlxs: ddi_modopen drv/fct failed: err 2 |
WARNING: emlxs: ddi_modopen drv/fct failed: err 2 |
| Preparing live image for use |
Preparing live image for use |
| Done mounting Live image |
Done mounting Live image |
| |
|
| |
|
| Make sure the network is configured. Note that it can take a minute for |
Make sure the network is configured. Note that it can take a minute for |
| the xnf0 interface to appear. |
the xnf0 interface to appear. |
|
Line 619 the xnf0 interface to appear.
|
Line 686 the xnf0 interface to appear.
|
| jack@opensolaris:~$ pfexec sh |
jack@opensolaris:~$ pfexec sh |
| sh-3.2# ifconfig -a |
sh-3.2# ifconfig -a |
| sh-3.2# exit |
sh-3.2# exit |
| |
|
| |
|
| Set a password for VNC and start the VNC server which provides the X11 |
Set a password for VNC and start the VNC server which provides the X11 |
| display where the installation program runs. |
display where the installation program runs. |
|
Line 629 display where the installation program r
|
Line 696 display where the installation program r
|
| Verify: solaris |
Verify: solaris |
| jack@opensolaris:~$ cp .Xclients .vnc/xstartup |
jack@opensolaris:~$ cp .Xclients .vnc/xstartup |
| jack@opensolaris:~$ vncserver :1 |
jack@opensolaris:~$ vncserver :1 |
| |
|
| |
|
| From a remote machine connect to the VNC server. Use **ifconfig xnf0** |
From a remote machine connect to the VNC server. Use `ifconfig xnf0` on |
| on the guest to find the correct IP address to use. |
the guest to find the correct IP address to use. |
| |
|
| remote$ vncviewer 172.18.2.99:1 |
remote$ vncviewer 172.18.2.99:1 |
| |
|
| |
|
| It is also possible to launch the installation on a remote X11 display. |
It is also possible to launch the installation on a remote X11 display. |
| |
|
| jack@opensolaris:~$ export DISPLAY=172.18.1.1:0 |
jack@opensolaris:~$ export DISPLAY=172.18.1.1:0 |
| jack@opensolaris:~$ pfexec gui-install |
jack@opensolaris:~$ pfexec gui-install |
| |
|
| |
|
| After the GUI installation is complete you will be asked to reboot. |
After the GUI installation is complete you will be asked to reboot. |
| Before that you need to determine the ZFS ID for the new boot filesystem |
Before that you need to determine the ZFS ID for the new boot filesystem |
|
Line 651 console.
|
Line 719 console.
|
| bootfs = 43 |
bootfs = 43 |
| ^C |
^C |
| jack@opensolaris:~$ |
jack@opensolaris:~$ |
| |
|
| |
|
| The final configuration file should look like this. Note in particular |
The final configuration file should look like this. Note in particular |
| the last line. |
the last line. |
| |
|
| |
|
| memory = 640 |
memory = 640 |
| name = 'solaris' |
name = 'solaris' |
| disk = [ 'phy:/dev/wd0k,0,w' ] |
disk = [ 'phy:/dev/wd0k,0,w' ] |
|
Line 664 the last line.
|
Line 731 the last line.
|
| kernel = '/root/solaris/unix' |
kernel = '/root/solaris/unix' |
| ramdisk = '/root/solaris/x86.microroot' |
ramdisk = '/root/solaris/x86.microroot' |
| extra = '/platform/i86xpv/kernel/amd64/unix -B zfs-bootfs=rpool/43,bootpath="/xpvd/xdf@0:a"' |
extra = '/platform/i86xpv/kernel/amd64/unix -B zfs-bootfs=rpool/43,bootpath="/xpvd/xdf@0:a"' |
| |
|
| |
|
| Restart the guest to verify it works correctly. |
Restart the guest to verify it works correctly. |
| |
|
|
Line 685 Restart the guest to verify it works cor
|
Line 752 Restart the guest to verify it works cor
|
| Mounting ZFS filesystems: (6/6) |
Mounting ZFS filesystems: (6/6) |
| Creating new rsa public/private host key pair |
Creating new rsa public/private host key pair |
| Creating new dsa public/private host key pair |
Creating new dsa public/private host key pair |
| |
|
| osol console login: |
osol console login: |
| |
|
| |
|
| Using PCI devices in guest domains |
Using PCI devices in guest domains |
| ---------------------------------- |
---------------------------------- |
|
Line 707 and domU. If the domain0 is NetBSD, it h
|
Line 774 and domU. If the domain0 is NetBSD, it h
|
| support has not been ported to later versions at this time. |
support has not been ported to later versions at this time. |
| |
|
| For a PCI device to be exported to a domU, is has to be attached to the |
For a PCI device to be exported to a domU, is has to be attached to the |
| `pciback`{.literal} driver in domain0. Devices passed to the domain0 via |
`pciback` driver in domain0. Devices passed to the domain0 via the |
| the pciback.hide boot parameter will attach to `pciback`{.literal} |
pciback.hide boot parameter will attach to `pciback` instead of the |
| instead of the usual driver. The list of devices is specified as |
usual driver. The list of devices is specified as `(bus:dev.func)`, |
| `(bus:dev.func)`{.literal}, where bus and dev are 2-digit hexadecimal |
where bus and dev are 2-digit hexadecimal numbers, and func a |
| numbers, and func a single-digit number: |
single-digit number: |
| |
|
| pciback.hide=(00:0a.0)(00:06.0) |
pciback.hide=(00:0a.0)(00:06.0) |
| |
|
| pciback devices should show up in the domain0's boot messages, and the |
pciback devices should show up in the domain0's boot messages, and the |
| devices should be listed in the `/kern/xen/pci`{.filename} directory. |
devices should be listed in the `/kern/xen/pci` directory. |
| |
|
| PCI devices to be exported to a domU are listed in the `pci`{.literal} |
PCI devices to be exported to a domU are listed in the `pci` array of |
| array of the domU's config file, with the format |
the domU's config file, with the format `'0000:bus:dev.func'` |
| `'0000:bus:dev.func'`{.literal} |
|
| |
|
| pci = [ '0000:00:06.0', '0000:00:0a.0' ] |
pci = [ '0000:00:06.0', '0000:00:0a.0' ] |
| |
|
| In the domU an `xpci`{.literal} device will show up, to which one or |
In the domU an `xpci` device will show up, to which one or more pci |
| more pci busses will attach. Then the PCI drivers will attach to PCI |
busses will attach. Then the PCI drivers will attach to PCI busses as |
| busses as usual. Note that the default NetBSD DOMU kernels do not have |
usual. Note that the default NetBSD DOMU kernels do not have `xpci` or |
| `xpci`{.literal} or any PCI drivers built in by default; you have to |
any PCI drivers built in by default; you have to build your own kernel |
| build your own kernel to use PCI devices in a domU. Here's a kernel |
to use PCI devices in a domU. Here's a kernel config example: |
| config example: |
|
| |
|
| include "arch/i386/conf/XEN3_DOMU" |
include "arch/i386/conf/XEN3_DOMU" |
| #include "arch/i386/conf/XENU" # in NetBSD 3.0 |
#include "arch/i386/conf/XENU" # in NetBSD 3.0 |
| |
|
| # Add support for PCI busses to the XEN3_DOMU kernel |
# Add support for PCI busses to the XEN3_DOMU kernel |
| xpci* at xenbus ? |
xpci* at xenbus ? |
| pci* at xpci ? |
pci* at xpci ? |
| |
|
| # Now add PCI and related devices to be used by this domain |
# Now add PCI and related devices to be used by this domain |
| # USB Controller and Devices |
# USB Controller and Devices |
| |
|
| # PCI USB controllers |
# PCI USB controllers |
| uhci* at pci? dev ? function ? # Universal Host Controller (Intel) |
uhci* at pci? dev ? function ? # Universal Host Controller (Intel) |
| |
|
| # USB bus support |
# USB bus support |
| usb* at uhci? |
usb* at uhci? |
| |
|
| # USB Hubs |
# USB Hubs |
| uhub* at usb? |
uhub* at usb? |
| uhub* at uhub? port ? configuration ? interface ? |
uhub* at uhub? port ? configuration ? interface ? |
| |
|
| # USB Mass Storage |
# USB Mass Storage |
| umass* at uhub? port ? configuration ? interface ? |
umass* at uhub? port ? configuration ? interface ? |
| wd* at umass? |
wd* at umass? |
| # SCSI controllers |
# SCSI controllers |
| ahc* at pci? dev ? function ? # Adaptec [23]94x, aic78x0 SCSI |
ahc* at pci? dev ? function ? # Adaptec [23]94x, aic78x0 SCSI |
| |
|
| # SCSI bus support (for both ahc and umass) |
# SCSI bus support (for both ahc and umass) |
| scsibus* at scsi? |
scsibus* at scsi? |
| |
|
| # SCSI devices |
# SCSI devices |
| sd* at scsibus? target ? lun ? # SCSI disk drives |
sd* at scsibus? target ? lun ? # SCSI disk drives |
| cd* at scsibus? target ? lun ? # SCSI CD-ROM drives |
cd* at scsibus? target ? lun ? # SCSI CD-ROM drives |
| |
|
| Links and further information |
Links and further information |
| ----------------------------- |
============================= |
| |
|
| - The HowTo on [Installing into |
- The [HowTo on Installing into RAID-1](http://mail-index.NetBSD.org/port-xen/2006/03/01/0010.html) |
| 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 |
| gives some hints on using Xen (grub) with NetBSD's RAIDframe |
with NetBSD's RAIDframe. (This is obsolete with the use of |
| - Harold Gutch wrote documentation on [setting up a Linux DomU with a |
NetBSD's native boot.) |
| NetBSD Dom0](http://www.gutch.de/NetBSD/docs/xen.html) |
|
| - An example of how to use NetBSD's native bootloader to load |
- An example of how to use NetBSD's native bootloader to load |
| NetBSD/Xen instead of Grub can be found in the i386/amd64 |
NetBSD/Xen instead of Grub can be found in the i386/amd64 boot(8) |
| [boot(8)](http://netbsd.gw.com/cgi-bin/man-cgi?boot+8+NetBSD-6.0+i386) |
and boot.cfg(5) manpages. |
| and |
|
| [boot.cfg(5)](http://netbsd.gw.com/cgi-bin/man-cgi?boot.cfg+5+NetBSD-6.0+i386) |
|
| manpages. |
|
| |
|
![[BACK]](/icons/back.gif){kind=icon}
Return to howto.mdwn CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [NetBSD Developer Wiki] / wikisrc / ports / xen