Xen 3.0(NetBSD 4.0/Xen編)


NetBSD/Xenの基礎編として、NetBSD 4.0(BETA2)のXen 3.0環境のゲストOS(ゲストドメイン:ドメインU)としてVine Linux 3.1を実行させる手順を紹介します。
尚、今回紹介するのは別マシンにインストールされていたVine Linux 3.1のHDDをNetBSD 3.1マシンにスレーブ接続させて利用する方式です。
また、ドメインUでVine Linux 4.0を実行させる手順も合わせて紹介します。

最後にドメインUへのNetBSD 3.1のインストールとGUI操作手順についても少し紹介します。


1.前提条件

前提条件は以下の通りです。



2.NetBSD 4.0の導入とNetBSD/Xen 3.0環境の構築




3.ドメイン構成ファイルの作成

DomainU上でHDD2(/dev/hdb1)にあるVine Linux 3.1を動作させるためのドメイン構成ファイル(仮想マシン環境設定ファイル)を作成します。
そのファイルは/usr/pkg/share/examples/xen/xmvine31uとします(NetBSD 4.0側に用意します)。
※ドメイン構成ファイルは/usr/pkg/share/examples/xenにインストールされるサンプルファイル(xmexample1)をカスタマイズして作成します。
xmvine31uの内容は以下の通りです。

#  -*- mode: python; -*-
#============================================================================
# Python configuration setup for 'xm create'.
# This script sets the parameters used when a domain is created using 'xm create'.
# You use a separate script for each domain you want to create, or 
# you can set the parameters for the domain on the xm command line.
#============================================================================

#----------------------------------------------------------------------------
# Kernel image file.
kernel = "/root/vmlinuz-2.6.16.29-xen"

# Optional ramdisk.
#ramdisk = "/boot/initrd.gz"

# The domain build function. Default is 'linux'.
#builder='linux'

# Initial memory allocation (in megabytes) for the new domain.
#
# WARNING: Creating a domain with insufficient memory may cause out of
#          memory errors. The domain needs enough memory to boot kernel
#          and modules. Allocating less than 32MBs is not recommended.
memory = 220

# A name for your domain. All domains must have different names.
name = "vine31u"

# 128-bit UUID for the domain.  The default behavior is to generate a new UUID
# on each call to 'xm create'.
#uuid = "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"

# List of which CPUS this domain is allowed to use, default Xen picks
#cpus = ""         # leave to Xen to pick
#cpus = "0"        # all vcpus run on CPU0
#cpus = "0-3,5,^1" # run on cpus 0,2,3,5

# Number of Virtual CPUS to use, default is 1
#vcpus = 1

#----------------------------------------------------------------------------
# Define network interfaces.

# By default, no network interfaces are configured.  You may have one created
# with sensible defaults using an empty vif clause:
#
# vif = [ '' ]
#
# or optionally override backend, bridge, ip, mac, script, type, or vifname:
#
# vif = [ 'mac=00:16:3e:00:00:11, bridge=xenbr0' ]
#
# or more than one interface may be configured:
#
# vif = [ '', 'bridge=xenbr1' ]

vif = [ 'mac=00:16:3e:00:00:11, bridge=bridge0' ]

#----------------------------------------------------------------------------
# Define the disk devices you want the domain to have access to, and
# what you want them accessible as.
# Each disk entry is of the form phy:UNAME,DEV,MODE
# where UNAME is the device, DEV is the device name the domain will see,
# and MODE is r for read-only, w for read-write.

disk = [ 'phy:/dev/wd1e,hda1,w', 'phy:/dev/wd1f,hda2,w' ]
#----------------------------------------------------------------------------
# Define to which TPM instance the user domain should communicate.
# The vtpm entry is of the form 'instance=INSTANCE,backend=DOM'
# where INSTANCE indicates the instance number of the TPM the VM
# should be talking to and DOM provides the domain where the backend
# is located.
# Note that no two virtual machines should try to connect to the same
# TPM instance. The handling of all TPM instances does require
# some management effort in so far that VM configration files (and thus
# a VM) should be associated with a TPM instance throughout the lifetime
# of the VM / VM configuration file. The instance number must be
# greater or equal to 1.
#vtpm = [ 'instance=1,backend=0' ]

#----------------------------------------------------------------------------
# Set the kernel command line for the new domain.
# You only need to define the IP parameters and hostname if the domain's
# IP config doesn't, e.g. in ifcfg-eth0 or via DHCP.
# You can use 'extra' to set the runlevel and custom environment
# variables used by custom rc scripts (e.g. VMID=, usr= ).

# Set if you want dhcp to allocate the IP address.
#dhcp="dhcp"
# Set netmask.
#netmask=
# Set default gateway.
#gateway=
# Set the hostname.
#hostname= "vm%d" % vmid

# Set root device.
root = "/dev/hda1 ro"

# Root device for nfs.
#root = "/dev/nfs"
# The nfs server.
#nfs_server = '169.254.1.0'  
# Root directory on the nfs server.
#nfs_root   = '/full/path/to/root/directory'

# Sets runlevel 5.
extra = "5"

#----------------------------------------------------------------------------
# Configure the behaviour when a domain exits.  There are three 'reasons'
# for a domain to stop: poweroff, reboot, and crash.  For each of these you
# may specify:
#
#   "destroy",        meaning that the domain is cleaned up as normal;
#   "restart",        meaning that a new domain is started in place of the old
#                     one;
#   "preserve",       meaning that no clean-up is done until the domain is
#                     manually destroyed (using xm destroy, for example); or
#   "rename-restart", meaning that the old domain is not cleaned up, but is
#                     renamed and a new domain started in its place.
#
# The default is
#
#   on_poweroff = 'destroy'
#   on_reboot   = 'restart'
#   on_crash    = 'restart'
#
# For backwards compatibility we also support the deprecated option restart
#
# restart = 'onreboot' means on_poweroff = 'destroy'
#                            on_reboot   = 'restart'
#                            on_crash    = 'destroy'
#
# restart = 'always'   means on_poweroff = 'restart'
#                            on_reboot   = 'restart'
#                            on_crash    = 'restart'
#
# restart = 'never'    means on_poweroff = 'destroy'
#                            on_reboot   = 'destroy'
#                            on_crash    = 'destroy'

#on_poweroff = 'destroy'
#on_reboot   = 'restart'
#on_crash    = 'restart'

#============================================================================

[補足]
(1)bridge0はNetBSD/Xenのブリッジです。
Domain0側もそのブリッジを使用してネットワークアクセスするので「ifconfig bridge0 down」を実行してしまうとDomain0側のネットワーク自体も使用できなくなります。
(2)disk = [ 'phy:/dev/wd1e,hda1,w', 'phy:/dev/wd1f,hda2,w' ]は物理ディスクパーティションを使用する場合の指定方法です。
※Xen 3.0ではXen 2.0と異なり、「/dev」指定が必要となります。


4.Vine Linux 3.1用DomainUへのGUIログイン環境の構築(VNCの導入と設定)

DomainUではVGAはエミュレートされません。
DomainUにVNC接続してGUIモードでログインできる環境をここでVineをネーティブ起動して構築します。
この構築作業は以下の項目です。
(1)-
(2)-
(3)-
(4)仮想フレームバッファデバイス、日本語入力パッケージ(Anthy,uim,uimアプレット)のインストール
(5)VNCサーバの導入と自動起動設定
(6)gdm設定ファイルの変更
(7)-
(8)フォントサーバ設定ファイルの変更
(9)日本語入力環境の変更

以下に順を追って各項目の詳細手順を示します(各作業は当然のことながらネーティブ環境のLinuxで行います)。


5.Vine Linux 3.1(DomainU)用カーネルモジュールの準備



6.Vine Linux 3.1(DomainU)の実行




7.Vine Linux 4.0(DomainU)の実行

Vine Linux 4.0についてもVine Linux 3.1と同様の手順でDomainUで実行させることができます。
※Vine Linux 4.0側にDomainU用の特別なカーネルやinitrdを用意する必要はありません。




8.DomainUへのNetBSD 3.1のインストールとGUI操作手順