仮想マシンのデファクトスタンダードっぽいXenを使ってみる。Debianのバージョンはetch(4.0)、Xenのバージョンは3.0となる。
xen-ioemu-xxxは、完全仮想化で使うパッケージのようだ。完全仮想化はボトルネックが大きく、Linuxしか使う予定がないため使用しない。
apt-get install xen-linux-system-2.6.18-5-xen-amd64 xen-tools xen-utils-3.0.3-1 bridge-utils
デフォルトだと、すべての実装メモリがDomain0に割り当てられるので、これを制限する。だだし、これを行わなくてもDomainUに割り当てたメモリはDomain0から減ってゆく。
ここでは、Domain0に512MBのメモリと2個のCPUを割り当てる。
kernel /xen-3.0.3-1-amd64.gz dom0_mem=524288 dom0_max_vcpus=2
ループバック用ディレクトリと、自動起動用設定ファイルのディレクトリを作成。
mkdir /home/xen mkdir /etc/xen/auto
デフォルト値の変更。
dir = /home/xen debootstrap = 1 dist = etch mirror = http://cdn.debian.or.jp/debian/ kernel = /boot/vmlinuz-2.6.18-5-xen-amd64 initrd = /boot/initrd.img-2.6.18-5-xen-amd64
(network-script network-bridge) #(network-script network-dummy)
XENDOMAINS_SAVE= XENDOMAINS_RESTORE=false
ネットワークブリッジの作成。
# /etc/xen/scripts/network-bridge start vifnum=0 bridge=xenbr0 netdev=eth0
DomainUを仮想NICに接続し、Domain0からパケットフィルタリングを行えるようにする。
ただし、Xen 3.2だと複数NICへの対応方法が違うようだ。ここでは、Xen 3.0の時の覚え書き。
auto dummy0 iface dummy0 inet static hwaddress ether 00:16:3e:00:ff:ff address 192.168.20.30 netmask 255.255.255.0
#(network-script network-bridge) (network-script network-bridge.dummy0)
#!/bin/sh script=/etc/xen/scripts/network-bridge case $1 in start|stop|status) $script $1 vifnum=0 bridge=xenbr0 netdev=eth0 $script $1 vifnum=1 bridge=xenbr1 netdev=eth1 $script $1 vifnum=2 bridge=xenbr2 netdev=dummy0 ;; *) echo "unkown $1" exit 1 esac
新規作成したファイルには、実行権を付ける。
# chmod +x /etc/xen/scripts/network-bridge.dummy0
DomainUに仮想NICを指定するときは、xenbr2を指定する。
ホスト名を指定してDomainUを作成する。ネットワークのデフォルトを設定していないので、DHCPを指定する。
xen-create-image --hostname domu01 --dhcp
作成したDomainUに割り当てるCPUを指定する。CPU2〜7の6つをDomainU専用に割り当てる。CPUの割り当てを変えた後は、createで起動させないと反映されないようだ。また、NICの設定も変更する。
cpus = '2,3,4,5,6,7' vcpus = 6 vif = [ 'mac=00:16:3e:00:00:11,bridge=xenbr0' ]
xen-create-image を使う場合は、DomainUを物理ディスクに割り当てることができないようなので、手作業でディスクイメージを作成する。
mkfs.xfs /dev/sda2 mount /dev/sda2 /mnt debootstrap etch /mnt
xen-create-image を使う場合は、DomainUを物理ディスクに割り当てることができないようだ。このため、一時的にループファイルシステム上に作った後ファイルを移動する。
mkfs.xfs /dev/sda2 mkdir /mnt/1 ; mkdir /mnt/2 mount -o loop /home/xen/domains/domu01/disk.img /mnt/1 mount /dev/sda2 /mnt/2 cp -a /mnt/1/* /mnt/2/
DomainUの設定ファイルも、物理ディスクを使うように変更。
#disk = [ 'file:/home/xen/domains/domu01/disk.img,sda1,w', 'file:/home/xen/domains/domu01/swap.img,sda2,w' ] disk = [ 'phy:/dev/sda2,sda1,w', 'phy:/dev/sda6,sda2,w' ]
自動起動の設定も行う。
cd /etc/xen/auto; ln -s ../domu01.cfg
コンソールを割り当てて起動。ブート状態を見ることができる。
xm create domu01.cfg -c
pppoeconfで一通り設定はできるが、以下のメッセージが出て接続ができない。
Linux kernel does not support PPPoE -- are you running 2.4.x?
探してみると、いくつか同じ現象は起こっているようだ。日本語の記事がほとんどなかったが、ヒット件数が少なかったのでざっと読んでみる。しかし、どれも解決策は見つからなかった。
考え方を変えて、すなおにDebianでPPPoE接続をするということで探す。すると、ptyを設定するという記事があった。以下のように設定した。
pty "/usr/sbin/pppoe -I eth1 -T 80 -m 1452" #plugin rp-pppoe.so eth1
今度は、接続できた。しかし、この設定ではユーザモードで動作しているようなので、より軽い(と思われる)カーネルモードで動作させるための方法を探す。今後は以下のように設定した。
#pty "/usr/sbin/pppoe -I eth1 -T 80 -m 1452" #connect /bin/true plugin rp-pppoe.so eth1
今度も接続できた。pppoeプロセスがいないのでカーネルモードで動作していると思われる。
しかし、コメントアウトしたconnectの行は、pppoeconfが作ったはずなんだけどな。
再起動時に有効かどうかを確認したら、接続されなかった。どうやら、/dev/pppがなくなる。
MAKEDEVとやっても起動時に作成されなかったので、ネットワークの設定に仕掛けを入れた。
auto dsl-provider iface dsl-provider inet ppp pre-up mknod /dev/ppp c 108 0 #仕掛け pre-up /sbin/ifconfig eth1 up provider dsl-provider
Xenでは、シリアルポートを解析用に使うためにデフォルトでは生のシリアルポートが見えなくなっているらしい。
そこで、解析用に使用しないようにする。
# xenkopt=console=tty0 xencons=off
設定変更後、GRUBを更新する。
# update-grub
xen-create-image --hostname domu01 ...
xm create domu01.cfg
xm shutdown domu01
xm console domu01
xm vcpu-list
http://w3.doshisha.ac.jp/~kueda/index.php?Debian%E3%81%ABXen
http://seldon.cocolog-nifty.com/petapeta/2007/03/etch_xen.html
http://seldon.cocolog-nifty.com/petapeta/2007/04/etch_xen.html
http://my-server.jp/archives/2006/11/xen_1.html
http://nakajin.dyndns.org/xen.html
http://antas.jp/blog/ina/archives/2007/10/xen_cpupin_cleared.html
http://webframe.sourceforge.jp/wiki/index.php?Xen
http://tomo.ac/goodstream/xen/centos5/tips.html
http://www.grandarbre.net/2007/11/xen-2.html
http://lists.debian.or.jp/debian-users/200403/msg00313.html
http://ken-etsu-tech.blogspot.com/2007/10/xendell-remote-access-controller.html