Xenで異CPU間ライブマイグレーション

iSCSIで SANを組んだので、せっかくだから Xenのライブマイグレーションを試してみた。

ノード１（命名kagami）
Core2Duo E8400
仮想サーバ運用のため奮発して部品を買いそろえ構築した新マシン

ノード２（命名tsukasa）
Athlon64 3500+
余り物の部品を寄せ集めてひとまず構築

kagamiと tsukasaは iSCSIで SAN上のストレージへログインしており、VMのイメージはそこに配置されている。

ライブマイグレーションのためのポート（8002）はデフォルトでlistenされているが、接続元がlocalhostだけに絞られている（この設定のままだと全く意味がない）。設定ファイル /etc/xen/xend-config.sxpで、

(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$')
となっている行を

(xend-relocation-hosts-allow '')
に変更。

稼働中のdomUに対し、ライブマイグレーションを実行するコマンドは下記。

xm migrate --live ドメイン名 移動先ホスト名

意外なことに、特に問題なく kagami→tsukasaも tsukasa→kagamiも成功。
全然違うCPUだから無理かと思っていたのだけれど、動いてるプロセスの少ないシンプルな環境のVMだから移動できたのかも。
あと、dom0同士の時計が合ってないと移動されたdomUのカーネルが狂ったように時間が戻ったと騒ぎ出すので注意。

GentooのXenで network-bridgeが上手くできない場合

xendの起動時に実行される network-bridgeスクリプトは元の物理的な eth0を peth0 にリネームしたうえでIPアドレスを剥奪し、代わりの eth0を作成して元のIPアドレスを付け直すという動作をする（SSHで接続した端末から xendの起動をすると切断されてしまうのはこのためだ）。

しかし Gentooの場合、普通に emergeしたての xendを起動すると、peth0は出現するものの元の eth0 が作成されず通信できない状態になってしまうことがある（私の所だけなのか？）

この場合、network-script内で addr_pfxを取り出している部分を書き直すことで問題を回避できる。

get_ip_info() {
#    addr_pfx=`ip addr show dev $1 | egrep '^ *inet' | sed -e 's/ *inet //' -e "s/$1//"`
    addr_pfx=`ip addr show dev $1 | sed -n 's/^ *inet \(.*\) [^ ]*$/\1/p'`
    gateway=`ip route show dev $1 | fgrep default | sed 's/default via //'`
}

Xen 3.1.2 Released

Xen 3.1.1からのさらなるバグフィックスリリース。

[Xen-devel] ANNOUNCE: Xen 3.1.2 released!

Gentooなら Portageにもう入ってる。

Xen domU on Linux 2.6.23

Linux 2.6.23には Xenの Paravirtual環境に対応するためのコードがマージされる。つまり2.6.23以降は domUで常に最新のカーネルが使えるようになるということだ。
実際 9/1に公開されたばかりの Linux 2.6.23-rc5にはそれらしきものが入っているのを確認したのだが、i386用のみで x86_64用はまだのようだった。
Xen-develメーリングリストでも8月上旬頃に「x86_64まだ？」「頑張ってる最中だよ」というやりとりがあった（このころはrc2）

はぶられたか、Gentoo（Xen 3.0.4）

Xen 3.0.2→3.0.4への移行をやったときに、network-bridgeスクリプトがそのままでは正常に動かないためやむを得ず 3.0.2のものをコピーして使っていたのだが、もっとよく調べてみた。

手がかりになったのは、下記ファイルにおける Xen3.0.2から3.0.4への差分。
/etc/xen/scripts/xen-network-common.sh

旧バージョンでは、ifup/ifdownコマンドを持たないGentooのために、/etc/init.d/net.* start/stopを呼び出すようなifdown/ifupへのブリッジとなるシェル関数が書かれていたのに対し、新しいバージョンではさっくり消されていた。

Xen-develメーリングリストをちらっと確認したところ、どうやらそういう個別対応はしない方針でスクリプト類をクリーンナップした模様。こういった類の問題に対しては ebuildによるパッチで対応してくれることを期待していたのだが、そうはなっていないみたいだ。

私は xen-network-common.shを一部旧バージョンの内容に書き換えることで対応したが、/sbin/ifupと /sbin/ifdownを手で作るという方法の方がスマートかもしれない。

Xen 3.0.2 dom0 e1000 problem

Xen3.0.2で動作させているホストのメモリを4GBに増設したら、なんだか通信が不安定に。

e1000_clean_tx_irq: Detected Tx Unit Hang

Xenのせいか e1000ドライバのせいかメモリのせいか板のせいか。

同じエラーに対し、ethtool -K ethX tso off で解決するといった過去事例はあったようだが（Xenと関係なく）、どうやらそれでもないっぽい。別の時期にXenのメーリングリストでもこのエラーが報告されているので、Xenの絡んだ別の問題と思われる。

XenのFullvirtualizationとAcronis True Image

パラバーチャリゼーション（準仮想化）と比べてフルバーチャリゼーション（完全仮想化, HVM）は VMWareや VirtualPCのようにハードウェアを完全に仮想化できるため WindowsなどをゲストOSとして利用できるのが利点だが、完全仮想のドメインUに割り当てられたブロックデバイスはパーティションではなく一台の仮想ハードディスクになってしまう（ハードウェアを完全に仮想化するわけだから当然）ので、これだとそう簡単にサイズの拡張ができない。
いっぽう準仮想化の場合はパーティション単位での割当が出来るため、lvextendで論理ボリュームのリサイズをして xfs_growfsするといった短い操作で拡張が出来るという利点があるのだ。しかも運が良ければ無停止で。


少しのお金で解決できる問題なら支払って楽をしよう。というわけで、Acronis TrueImageというソフトを購入し HVM Domainで使ってみた。このソフトを使えば、小さいハードディスクから大きいハードディスクへ（又はその逆）OS環境をまるごとコピーすることが出来る。無停止でのマイグレーションというわけにはいかないが、容量拡張のソリューションとして実マシン・仮想マシン問わず役に立つ一品である。

このソフトはブータブルCDで提供されているので、ディスクイメージを作ってドメインUに対してCD-ROMとして割り当ててやれば仮想マシン上で動かすことが出来る。

画面は、仮想ハードディスクにインストールされた Windows 2000をAcronis TrueImageで別の仮想ハードディスクにコピーしている図（この例では拡張ではなく縮小をしている）。
これで Windows系の OSも気軽に Xenでまずは小さくセットアップして、必要に応じて容量を拡張するという柔軟な運用が可能になるのだった。


おまけ：仮想マシン上にインストールした Windows2000で CrystalMarkの HDDベンチマークを実行してみた図。なんかメーター振り切ってます。実機はAthlon64X2 5200+, Gentoo Linux, HighPoint RocketRAID2322でRAID5の8台構成。

Xen 3.0.4と via_rhine

Xenを3.0.2から3.0.4へアップグレードしたら、なぜか VIAのRhineチップを使ったNICにブリッジを設定するとハングするようになった。
いろいろやってみたら、いつのまにか直ったのだがいまいち釈然とせず。
カーネル設定で、"VIA Rghine support"→"Use MMIO instead of PIO(CONFIG_VIA_RHINE_MMIO)"をYにしたから直ったのかな。

Xen 3.0.2→3.0.4

Portageの Xenが 3.0.2から 3.0.4になっていたので入れ替えてみた。
今まであきらめていた HVM Domainが動く。

以前に書いた「Xenで複数のネットワークインターフェイスを domUに提供する」で作成したスクリプトを使用するためには、network-bridgeスクリプトを 3.0.2のものに置き換える必要があった。なんでだろう。

メモ。HVM DomainのVNCで他のホストから接続できるようにするには、xend-config.sxpの
(vnc-listen '127.0.0.1')
というところを
(vnc-listen '0.0.0.0')
にする。

XenでドメインUの仮想CPU数を絞る方法

うちのドメインUたちはドメイン0で稼働しているLVMの上で動作している。
ドメインUの稼働している論理ボリュームのスナップショットを作成してxfs_copyでバックアップし、gzipで圧縮するという処理をドメイン0上のcronで毎夜行っているのだが、これが重い（特にgzip）。

Xenの仮想CPUは、ドメイン0にはデフォルトで実CPU数と同じだけ割り当てられてしまうので、ドメイン0でコンテキストが複数走るような重い処理を開始するとCPUコアを両方使ってしまいドメインU群に割り振られる処理時間が激減しているようだったので、ドメイン0に割り当てる仮想CPU数を2から1に減らそうと考えた。

結果をいうと、grub.conf内にある kernel=/boot/xen.gz 行で、dom0_mem=オプションと並べて dom0_max_vcpus=1 と書くことでどうやら実現できたようだが、この情報がほとんどどこにも載っていない。誰もドメイン0の仮想CPU数を減らしたくなんかないのだろうか。

これを書いている最中にちょうどドメイン0でバックアップが走り出したが、ドメイン0へ割り当てる仮想CPU数を減らした今、ドメインU群は重くなることなく良いレスポンスを維持しているようだ。

ソリッドステート・ドメイン0【その3】

前回の続き。

前回までで、ドメイン0のルートパーティションをフラッシュメモリに移すことができた。
でもそれだけじゃつまんないでしょう。出来るの当たり前だし。

さて、ドメインUたち（これらは相変わらずハードディスク上で動作中）は、どれくらいドメイン0から自立しているのか試してみよう。たとえば、ドメイン0に障害が起こっても、ドメインUは引き続き動作できるのか？

適当なドメインUで在る程度時間のかかる処理を走らせる。

genkernel bzImage


走っている最中に、

（ば・・・ばかな！まさか！）






えーーーーーい（ズシャァァァア）

コンソールに出力されるはカーネルの阿鼻叫喚。いかんともしがたい状態に陥るドメイン0。よいこはまねをしてはいけません。



しかしそれでもドメインUは動作を続け、genkernelは「ブートスプラッシュを見たいなら・・・」などという呑気なWARNINGを出して何事もなかったかのように終了。sshで新しくリモートログインも出来る。
ドメイン0のディスクに障害が起こったくらいでは、ドメインUには（急には）影響しないようだ。もちろん、ディスク障害がデバイスドライバやカーネル内部プロセスの障害に発展すれば別だろうけど。

ドメイン0は Privileged domainという名目で数々の特別扱いを受けているものの、Xen本体から見ればドメインのひとつに過ぎない（のだと思う）。つまり、VirtualPCや VMWareがホストOSの中でゲストOSを動作させるのと同じように Xenではドメイン0の中でドメインUが動いていると考えるのは少し間違い（なのだと思う）。

さてドメインUは無事なものの、ドメイン0が再起不能となった今もはや新たにドメインを起動することも出来ない。
PCのリセットボタンに手が伸び、狂った実験は幕を閉じたのだった。

ソリッドステート・ドメイン0【その2】

前回の続き


PCでマイクロSDを読み書きするためのインターフェイスといえば USBしかないので、3.5インチベイに内蔵するタイプの USBカードリーダー/ライターを取り付け。2000円弱で売っているオウルテックのFA405MX3というもの。なんとマイクロSDを直接挿せるスロットが・・・（SD/miniSDとの同時使用はできないとのこと）


早速マイクロSDカードを差し込み、dmesgで認識されたことを確認。udevの取り計らいにより、このメモリカードへは
/dev/disk/by-id/usb-Generic-_SD.MMC_200211111（略）
という名前でアクセス出来るようだ。/dev/sdXだといつもコロコロ変わって不便だから固定の名前がつくのっていいよね。でも長いよ。

普通に fdiskと mkfs.xfs して適当な場所にマウントし、ルートパーティションの内容を丸ごとコピー。さすがに時間がかかる（SDメモリにスループットは期待しないこと。とてもがっかりするから）。
コピーには cp -avxコマンドを使ったが、ルートファイルシステムを -xオプションつきでコピーすると /dev以下がコピーされないので注意（udevもdevfsも使っていない人以外...）。

さて、カーネルのroot=や /etc/fstabにこんな長い名前を書くのはゴメンなので、パーティションにラベルをつけてやることにする。
ルートファイルシステムなので root とつけてやろう（安易）
ラベルを付けるコマンドはファイルシステムによってそれぞれだが、今回はXFSを選んだので下記のように。

xfs_admin -L root /dev/disk/by-id/usb-Generic-_SD.MMC_200211111（略）-part1

こうしておくとfstabに
/dev/disk/by-id/usb-Generic-_SD.MMC_200211111（略）-part1
なんて書かなくても、
LABEL=root
と書けば勝手にそのラベルがついたパーティションを探してマウントしてくれる。

/etc/fstabと /boot/grub/grub.confを書き換える。
カーネルのオプション（実際は initrdに渡される）に scandelay 指定を付ける必要があった（Gentoo以外では違うやり方かも）。そうしないとメモリカードを認識する前にルートファイルシステムをマウントしようとして失敗する。

書き換えができたらリブートし、めでたく小指の先ほどのメモリで OSが起動するのだった。

なぜか続く

ソリッドステート・ドメイン0【その1】

このソリッド野郎！

・・・というわけで、Xenのドメイン0といえばドメインUを「管理」するためのドメインである。
極端な話、必要なハードウェアを認識していて、xendが走っていて、xmコマンドが動けばよろしい。
だったら、ドメイン0を起動するためのボリュームは容量を小さくしてフラッシュメモリに入れてしまえば面白いのでは。
と、思いついたので実践してみた。それほど意味はない。

それより前にまずこれ。

うちの Linuxマシンには全部これ（IDE用32MBフラッシュメモリ）が刺さっている。
何に使うんだそんなものだって？grubとカーネルとinitrdが入ってるのさ。（それより何処で買うんだこんなもの→ここです）
これで、どんな構成で記憶装置を接続していようが BIOSは「プライマリIDE」の「マスター」であるこのメモリ(/dev/hda)を確実に優先して起動デバイスに選択し、ブートできるという寸法だ。こうしておけば何があってもブートローダーを経てカーネルまでは起動出来るので、障害から復帰しやすくなる（grubのコマンドラインを使える人限定だけど）。

しかし残念なことに、32MBからカーネル等の分を引いた容量ではそう簡単にドメイン0を運用できそうにないので（ドメインの管理をするための各種スクリプトを実行するにはPythonが要る）このフラッシュメモリはブート専用とし、次なる記憶装置としてこれを選んでみた。

これは！最近の携帯電話で採用されまくって急速に普及中のマイクロSDじゃないか！（1ギガバイト1980円。よく探せば1500円以下で買える）
写真で見ての通り、小指の先ほどの大きさ。吹けば飛ぶぞ！
っていうかこんなもので OS動かそうってアホかおまえは！

続く

xendをnfsdより後に起動させるように rcスクリプトを調整する

うちの場合、全てのドメインUから ドメイン0のリソースを NFSで参照するので、xend（と、自動起動のドメインUたち）が nfsdより後に起動してくれないと困る。
Gentooの場合、rcスクリプトの中にdepend(){}というセクションがあって、ここで起動順序を制御できる。

デフォルトの /etc/init.d/xend では

depend() {
need net
before xendomains sshd ntp-client ntpd nfs nfsmount rsyncd portmap dhcp
}

のようになっていたので、

depend() {
need net
before xendomains
after sshd ntp-client ntpd nfs nfsmount rsyncd portmap dhcp
}

というふうに xendがとにかく最後に起動するようにした。

Xenで複数のネットワークインターフェイスを domUに提供する

Xenはネットワークインターフェイスをドメイン0とドメインUの間でブリッジできる。
簡単にいうと、ドメイン0で認識されているネットワークインターフェイスを、ドメインUでも共有できるということである。

ドメイン0で xendを起動すると、ネットワークインターフェイスをドメインUにブリッジするための仮想インターフェイスが起動される。それらは xenbrというプレフィクスのネットワークインターフェイスである。

Xenのデフォルトでは、ドメイン0で認識されている一番最初のネットワークインターフェイス（大抵 eth0だろう）に対して xenbr0を自動的に起動する。ドメインの設定ファイルに

vif=[""];

と書くと、xenbr0がドメインUから eth0 として利用できるようになる。
（どうやら "" は "bridge=xenbr0" の省略記法のようだ）

さて、ドメインUに複数のネットワークインターフェイスを持たせたい場合は、ドメイン0における 2番目以降のインターフェイスに対しても xenbrデバイスを起動しなくてはならない。これにはちょっとしたスクリプトを作成して、それが xendの起動時に呼び出されるよう設定を変更する必要がある。

/etc/xen/scripts に、適当な名前（ここではmy-network-script）で下記のようなシェルスクリプトを作成し、実行権限をつける。
vifnumは xenbrデバイスにつける番号、 netdevはブリッジしたい実デバイスの名前。


#!/bin/sh
dir=$(dirname "$0")
"$dir/network-bridge" "$@" vifnum=0 netdev=eth0
"$dir/network-bridge" "$@" vifnum=1 netdev=eth1


さらに xendの設定ファイル /etc/xen/xend-config.sxp を開き、上で作ったスクリプトファイルをを呼び出すように変更する。


(network-script network-bridge)

↓

(network-script my-network-script)


これで xendを再起動したら、xenbrデバイスが複数になっているはず。

実際のドメイン設定ファイルで複数のネットワークインターフェイスを定義するには、
vif=["","bridge=xenbr1"];
のようにカンマで区切って2番目以降の xenbrデバイスを追記する。
この記述の場合 xenbr1はドメインU側で eth1として認識される。

最新のnForceマザーボードをXenで使うためにforcedethドライバをハックする

統合チップセットnForceの搭載されたマザーボードは市場に多く出回っている。
これにオンボード搭載されているイーサネットを Linuxで使いたければ、大抵 forcedeth というドライバで動作させることができる。
しかし、nForceのオンボードイーサネットコントローラにも色々バージョンがあるようで、forcedethドライバのバージョンが古い（つまりカーネルのバージョンが古い）とドライバ内のデバイス識別子リストに該当せず認識させられないことがある。
nForceに限らずこれはシリーズ物のハードウェア全般に言えることだが。

さて、この前買ってきた nForce430マザーに搭載のイーサネットコントローラは Linux 2.6.16の forcedethドライバで認識できなかった。単にドライバが新しいデバイスのIDを知らないだけだというのは何となく想像がつく。
かといって Linuxのバージョンを上げるわけにはいかない状況だった。なぜかというと Xenを使っているから。
私は Portageと genkernelを使ってしか Xen対応のカーネルをセットアップできないヘタレ者なので、仮に Xenがもっと新しい Linuxカーネルに対応していたとしても Portageが追従しない以上手出しできない（ことにしている）。

デバイスIDを追加するだけならドライバソースに手で入れてやれば良い。

---
Xen対応化されたカーネル
linux-2.6.16-28-xen

最新のカーネル
linux-2.6.20.3
---

まずは、最新のPCIデバイスリストを最新カーネルから拝借

# cp linux-2.6.20.3/include/linux/pci_ids.h linux-2.6.16-28-xen/include/linux/

で、
linux-2.6.20.3/drivers/net/forcedeth.c
linux-2.6.16-28-xen/drivers/net/forcedeth.c
の中でデバイスリストを定義している部分に目を付け、ここを中心に手マージする。
なお今回は、MCP61というデバイスのIDがリストになかったためデバイスが認識されないでいた。

デバイスIDの追加で、一応はデバイスが認識されるようになったが動作がおかしい。
どうやら一部のチップでは MACアドレスのオーダが逆順になるらしい。シリーズ物なのにそんな微妙な個性ださなくてよろしい。
最新カーネルのドライバソースにはそれの対応も含まれていたので、めんどくせえなと思いつつその部分も手マージ。
これで思った通りに動作した。

できたdiffを載せようかと思ったけど誰か他の人がこれと同じシチュエーションに遭遇するケースはかなりレアだと思うのでやめ。

当然だが、こういう真似をするためにはC言語を読めることが必須。

module license 'Proprietary' taints kernel.

RocketRAIDのドライバを動的にロードしようとして言われた言葉。
この後に
Unknown symbol force_evtchn_callback
などというエラーが続く。

Xenがプロプライエタリなモジュールにシンボルをエクスポートしてくれないためだと思う。
特別なハードウェアをXenと組み合わせるときは注意。

カーネルに静的リンクすれば問題なく動くのだけど、RocketRAID231x系と RocketRAID232x系のドライバを両方組み込む、といったことができない。（シンボル名がかぶる）

うーん困ったね。

販促用記事

懇意にしていただいている、PRO SHOP MAXSERVE に、販促用の記事を寄稿しました。

IT開発現場におけるサーバ仮想化とマルチレーンの活用

マルチレーンを使って高速で大容量なストレージを低コストで組み上げ、Xenを使った仮想サーバ環境に活用しようという趣旨です。

genkernelでXenカーネルを作る(x86_64)

基本的には、環境変数 ARCH_OVERRIDEに "xen0" 又は "xenU" をセットして genkernelを実行すれば良いのだが、そのままではどういうわけかうまくいかない。

/usr/share/genkernel/xen0(およびxenU)/config.sh

上記ファイル内の KERNEL_MAKE行を下記のように書き換える必要がある。

KERNEL_MAKE="make ARCH=x86_64"

ドメインUで /dev/sd*を使いたければ、ドメインUカーネルを作成するときSCSIをオフにすること。
（/dev/sd*という名前を使わなければいいじゃないかって？ sdにしておけば仮想マシンと実機とで行き来できるでしょ）
さもないとxen_blk: can't get major 8 with name sdとか言われてdomainUが起動しない。

Xenの導入がひと段落したのでSDLを入れてHVM domainを試したのだが、xm createした瞬間マシンが即死（リブート）。
これに関しては安定を待つとするか・・・※追記：別のマシンで試したら色々問題はあるものの同じバージョンのXenでWindows XPの起動まで出来た。