NetBSD as a Xen domU

From Sfvlug

(Difference between revisions)
Line 1: Line 1:
-
I used CentOS 5.3 x86_64 (Linux) as the dom0, but that should be irrelevant.
+
I used CentOS 5.3 x86_64 (Linux) as the dom0, but that should be irrelevant.  This is how I installed NetBSD 5.0 amd64 as a Xen domU.
 +
 
 +
In Xen parlaiance, dom0 (domain zero) refers to the first kernel launched by the hypervisor, the one which has direct access to all the hardware.  Then, domU (domain unprivileged) refers to all the other kernels running in the hypervisor, that do not have direct access to hardware.
/etc/xen/auto/netbsd
/etc/xen/auto/netbsd
Line 36: Line 38:
:<pre> xm create -c netbsd </pre>
:<pre> xm create -c netbsd </pre>
 +
 +
;kernel, on_reboot, and on_crash
 +
 +
:Basically, when installing we want the domU to halt if it crashes or reboots, because otherwise it would start the installation process again.  However, if one of these events occurs if the machine is in production, we want it to reboot.
 +
 +
;vfb
 +
 +
:I hope this will work.  I honestly haven't tested this to see if there is a display available on this domU yet.
 +
 +
;disk
 +
 +
:This refers to a physical partition I created with Linux LVM2.  In NetBSD, it is apparently not extremely important to make the device ID match a real major and minor number combo.
 +
 +
For installation, I mounted the NetBSD ISO image in my FTP directory and started vsftpd.  I had to temporarily disable SELinux because ISO-9660 lacks the special labeling otherwise required.  After installation was finished, I re-enabled SELinux.

Revision as of 06:48, 1 August 2009

I used CentOS 5.3 x86_64 (Linux) as the dom0, but that should be irrelevant. This is how I installed NetBSD 5.0 amd64 as a Xen domU.

In Xen parlaiance, dom0 (domain zero) refers to the first kernel launched by the hypervisor, the one which has direct access to all the hardware. Then, domU (domain unprivileged) refers to all the other kernels running in the hypervisor, that do not have direct access to hardware.

/etc/xen/auto/netbsd 

# -*- python -*-                                                                

if xm_vars.env.get('install'):
    kernel      = "/var/lib/xen/images/netbsd-INSTALL_XEN3_DOMU.amd64"
    on_reboot   = "destroy"
    on_crash    = "destroy"
else:
    kernel      = "/var/lib/xen/images/netbsd-XEN3_DOMU.amd64"
    on_reboot   = "restart"
    on_crash    = "restart"

name            = "netbsd"
uuid            = "a351589d-9858-42de-8749-f6048aa08f72"
maxmem          = 256
memory          = 256
vcpus           = 1
on_poweroff     = "destroy"
root            = "xbd0"
vfb             = [ "type=vnc,vncunused=1,keymap=en-us" ]
disk            = [ "phy:/dev/VolGroup00/netbsd,0x1,w" ]
vif             = [ "mac=00:16:3E:A8:01:03,bridge=xenbr0" ]
if ...
The Xen xm command creates a special Python object, which you can use to test the environment. The end result is that when you are installing the domU, invoke the following: 
 xm create -c netbsd install=1
And when otherwise starting an installed domU, invoke: 
 xm create -c netbsd
kernel, on_reboot, and on_crash
Basically, when installing we want the domU to halt if it crashes or reboots, because otherwise it would start the installation process again. However, if one of these events occurs if the machine is in production, we want it to reboot.
vfb
I hope this will work. I honestly haven't tested this to see if there is a display available on this domU yet.
disk
This refers to a physical partition I created with Linux LVM2. In NetBSD, it is apparently not extremely important to make the device ID match a real major and minor number combo.

For installation, I mounted the NetBSD ISO image in my FTP directory and started vsftpd. I had to temporarily disable SELinux because ISO-9660 lacks the special labeling otherwise required. After installation was finished, I re-enabled SELinux.

Retrieved from "http://editthis.info/sfvlug/NetBSD_as_a_Xen_domU"
Personal tools