カテゴリ：XenServer
2013-08-27 Tue
■ XenServerで発生する vNIC障害 [XenServer]
ツチノコブログ / XenServerによるmemcachedパフォーマンス
http://tsuchinoko.dmmlabs.com/?p=464
でも触れられていますが、XenServer では、ごくごくまれに仮想マシンに割り当てられた vNIC がおかしくなることがあります。
ただ、再現条件がわからず、起きないVMは全然起きないので、特定のトラフィックパターンに起因する可能性もあるのかも…
もともと、XenServerはネットワーク回りに不安を抱えており、dmmでも
ちょくちょくXenServerのネットワークが定期的にフリーズしています。
具体的には、XenServerの、というよりは、VMの仮想NICがおかしくなります
どうおかしくなるのか？ですが
例えば、XenServer側の vif と、VM側の NIC は下記のような関係になっています。
[vif10.0] XenServer
RX TX
｜ |
｜ |
TX RX
[ eth0 ] CentOS5.5(PV)
この問題が発生した時に、ifconfig で、RXおよびTXのカウンタを眺めていると、vif10.0 のTX と、eth0 のRX のカウンタは上がるものの、eth0の TX と vif のRXのカウンタは上がりませんでした。
実際、vif10.0と eth0 で tcpdump してみても、XenServer側から、VM の方向には、ARPパケットが流れていきますし受信もされていますが、その逆は全くで、上図でいうところの eth0/TX も、vif10.0/RX のカウンタも上がりませんし、arp packet の応答も見えません。
DMMさんでは
その都度、ネットワークインターフェースのdeactivate→activateで復旧させなければいけません。
と言われていますが、このキモは対象 vif の再生成です。なので、VMの再起動や、XenMotion によるホストの移動でも、復旧します。
また仮想マシンの eth0 を down/up しても、残念ながら復旧しません。
ともあれ、明確な対策が打てないものの如何にも割り込み周り系っぽい＆NICの offload 機能で幸せになった試しがないので、最近は 物理NIC, vif, 仮想マシンNIC で、考えられるだけNICの off load機能をすべて off にしてます。効果があったような気がちょっとする今日このごろ。
で、最近これに対応するっぽい記述のパッチが出ました。
http://support.citrix.com/article/CTX135623
Customers may experience a loss of network connectivity, if the environment, across multiple VMs, is creating high network load. This is due to the VM being unable to send packets. However, ifconfig (run from the control domain - dom0) will show that packets are still sent to the VM.
が、どうも違うみたい
http://forums.citrix.com/thread.jspa?threadID=305894&start=90&tstart=0
Hi,
I applied this hotfix and for me didn't resolv this issue
Still, from time to time my XS lose network connectivity.
うーん、残念。
2012-10-25 Thu
■ failed to pause VDI [XenServer]
下記、XenServer 5.6 SP2 + XS56EFP1001, XS56EFP1004, XS56EFP1005, XS56EFP1006, XS56ESP2, XS56ESP2001, XS56ESP2002, XS56ESP2003, XS56ESP2004, XS56ESP2005, XS56ESP2006, XS56ESP2007, XS56ESP2008, XS56ESP2009, XS56ESP2011, XS56ESP2013, XS56ESP2014, XS56ESP2015, XS56ESP2016
な環境での話。
検証環境でテストしていたら、妙な現象が。特定の VM でスナップショットが取れなくなっている。
怪しげなログ（/var/log/SMlog)
[15446] 2012-10-12 16:03:53.947425 ***** BLKTAP2:call_pluginhandler: EXCEPTION XenAPI.Failure, ['HOST_OFFLINE', 'OpaqueRef:5d79ee19-6942-531e-7eb3-833fdbb29044']
[15446] 2012-10-12 16:03:53.954785 lock: released /var/lock/sm/a4c3399a-4cde-6738-2aab-d627f456f369/sr
[15446] 2012-10-12 16:03:53.955676 ***** vdi_snapshot: EXCEPTION util.SMException, failed to pause VDI c7514e13-25bd-4e0b-8ab7-32aad371a232
File "/opt/xensource/sm/blktap2.py", line 1212, in call_pluginhandler
{"sr_uuid":sr_uuid,"vdi_uuid":vdi_uuid})
File "/usr/lib/python2.4/site-packages/XenAPI.py", line 229, in __call__
return self.__send(self.__name, args)
File "/usr/lib/python2.4/site-packages/XenAPI.py", line 133, in xenapi_request
result = _parse_result(getattr(self, methodname)(*full_params))
File "/usr/lib/python2.4/site-packages/XenAPI.py", line 203, in _parse_result
raise Failure(result['ErrorDescription'])
[15446] 2012-10-12 16:03:53.954785 lock: released /var/lock/sm/a4c3399a-4cde-6738-2aab-d627f456f369/sr
[15446] 2012-10-12 16:03:53.955676 ***** vdi_snapshot: EXCEPTION util.SMException, failed to pause VDI c7514e13-25bd-4e0b-8ab7-32aad371a232
File "/opt/xensource/sm/SRCommand.py", line 94, in run
return self._run_locked(sr)
File "/opt/xensource/sm/SRCommand.py", line 131, in _run_locked
return self._run(sr, target)
File "/opt/xensource/sm/SRCommand.py", line 169, in _run
return target.snapshot(self.params['sr_uuid'], self.vdi_uuid)
File "/opt/xensource/sm/LVHDSR.py", line 997, in snapshot
raise util.SMException("failed to pause VDI %s" % vdi_uuid)
[15446] 2012-10-12 16:03:53.982316 Raising exception [82, Failed to snapshot VDI [opterr=failed to pause VDI c7514e13-25bd-4e0b-8ab7-32aad371a232]]
HOST_OFFLINEとか出てるけど、全プールのホストは生きてる。適当にググってみたけど、それっぽいエラーがなかった。たまには
Citrix Support Forums
で質問してみようと、事象をまとめてたら、なんとなく原因がわかってしまった。
こんな感じで追っていった。
1. EXCEPTION を投げてるコードをざっくり眺める
-> ぱっと見、疑わしき点はなかった
2. VDIの破損を疑う
-> 対処のVMは、問題なく起動したり、shutdownできるので、VDIが破損している可能性はなさそう。
3. 対象のVMを full copy して Cloneを作成してみる。
-> 問題なく、Snapshot が取得可能。元VMの構成情報がおかしい？
VDIの操作で失敗しているので、VDIの構成情報を眺めてみることに。
まずはvdiのuuidを特定する。
# xe vbd-list vm-name-label=<VMの名前> params=vdi-uuid
vdi-uuid ( RO) : c7514e13-25bd-4e0b-8ab7-32aad371a232
vdi-uuid ( RO) : <not in database>
片方は、CD-ROMドライブなので、必要なのは 上のほう。
# xe vdi-param-list uuid=c7514e13-25bd-4e0b-8ab7-32aad371a232
このパラメータを、full copy して問題がない VM と見比べると、次のことがわかった。
VM が電源ONされると、sm-config に
host_OpaqueRef:1279ce49-0bdf-809f-d4a3-df67d3021873: RO;
が追加される。host_OpaqueRef は、VMを稼働させるhostによって、uuid が異なる（が、なんと、その uuidは host-uuidじゃない。意味わからん）
起動が完了すると
host_OpaqueRef:1279ce49-0bdf-809f-d4a3-df67d3021873: RW;
になる。VMを shutdown すると、このパラメータは消される。
で、Snapshotが取れないVMは、停止状態で
host_OpaqueRef:5d79ee19-6942-531e-7eb3-833fdbb29044: RO;
稼動状態で
host_OpaqueRef:1279ce49-0bdf-809f-d4a3-df67d3021873: RW; host_OpaqueRef:5d79ee19-6942-531e-7eb3-833fdbb29044: RO;
ん？２つある...
実は、この問題となったVMは、検証環境を再構築する際に、退避させていた VM。
どうやら、強制shutdownしたか、起動途中で強制shutdown したかはわからないが、sm-config にこのゴミ情報が残った状態で、VMのバックアップが取られてしまったらしい。
で、新環境では、その host_OpaqueRef で指定される host は存在しないので、HOST_OFFLINE となった模様（VMのmeta情報に、バックアップしては困る（多分しちゃだめな）情報が残ることは、ままある話だけど……以前あった話では、そのVMでは、使ってないSR情報が入ってて、そのSRがないから meta情報は importできないよ！って怒られたことがある。泣いた...）
で、こまったことに、sm-config って RW じゃない。
sm-config (MRO):
xeコマンド使って、書き換えできない...良い子は真似しちゃいけない、マスターサーバ上での state.db 直接書き換え
# xe pool-ha-disable
# /etc/init.d/xapi stop
# cp /var/xapi/state.db /var/xapi/state.db.bak
# vi /var/xapi/state.db <- 該当部分の削除
# /etc/init.d/xapi start
slaveサーバには、古い情報が残るけど、snapshotの作成＆削除とかしてると、更新されるのでまぁいいでしょう。
state.db のクリーナーが欲しい今日この頃。
と、ここまで来ても、なんで RO な host_OpaqueRef が残ってたか、いつの時点でかはトレースできなかった。
2012-07-02 Mon
■ XenServerで、Host名を変更する [XenServer]
XenServerで POOL内のホスト名を変更するには、いまからなにを自分が変えようとしているかを、ちょっと意識する必要があります。
普通に XenCenterから対象ホストを指定して、その Properties から変えればいいんじゃないか？と思うんですが、これでは ssh でログインしたときのホスト名は変わりません。実は XenCenter から変更したのは name-label で、hostname ではありません。
これは
# xe host-list uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx params=name-label,hostname
name-label ( RW) : xenserver1_changed
hostname ( RO): xenserver1
を実行してみることでわかります(xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxは、変更したホストのUUID)
XenServerのスレーブサーバは、/etc/sysconfig/network の生成などを、マスタサーバから構成情報を取得して生成しているんですが
/etc/init.d/management-interface
このスクリプトが行なっているようです。
生成、と書きましたが、実際は一部設定ファイルの置換です(例外あり？)
/opt/xensource/libexec/interface-reconfigure
に詳細な処理が書いてあります。
で、
/etc/sysconfig/network
に関しては、DNSDEV, GATEWAYDEVしか書き換えず
HOSTNAME=xenserver1
みたいな箇所は、インストール時のままとなります。
つまりは、XenServer は、管理上、ホストの name-label と hostname を区別してるんですね。
これ以外にも
/etc/hostname
/etc/iscsi/initiatorname.iscsi
あたりも hostname が埋め込まれていますが、name-label の変更では更新されません。インストール時に指定したホスト名がそのまま継続して使われます。
よって、自身の host uuid を調べようと
# xe host-list hostname=`hostname` params=uuid --minimal
とかは、ホスト名に重複がない限りはうまく行くでしょうが、
# xe host-list name-label=`hostname` params=uuid --minimal
は、必ずうまく行くとは限りません。まぁ普通はあとでホスト名を変えるなんてことはしないと思いますけど……
ちなみに、ホスト名を xe コマンドで変更することはできないの?と疑問に思うことでしょう。しかし
# xe host-list uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx params=name-label,hostname
name-label ( RW) : xenserver1_changed
hostname ( RO): xenserver1
にある通り、hostname は、RO(Read Only)で、変更はできません。ssh でログインして、vi などで /etc/sysconfig/network とかを書き換えるしかないようです。
2012-06-30 Sat
■ XenServerで、パッチを当てたことにする(無保証) [XenServer]
昨日のブログの続きですが
XenServer5.6 SP2だと、FP1 から上げていった POOL とかを同じ XenCenterから接続してたりすると
- XS56EFP1007
- XS56EFP1008
が当たってないと言われるのが気持ち悪いことこの上ないので、当てたことにする方法です。
# cd /var/patch/applied
# vi ead29a11-9dcd-47ec-b82d-da73516fb38b
とかして、下記を記載します。このファイル名は、patch の uuid です。
<info uuid="ead29a11-9dcd-47ec-b82d-da73516fb38b"
name-label="XS56EFP1008"
name-description="Public availability: Hotfix for kernel and xen issues"
after-apply-guidance="restartHost"
version="1.0" />
中身は本当に当ててあるホストからコピってきましょう。これを必要なだけ繰り返します。
もちろん、本当にパッチが当たるわけではないです。
最後に reboot してオシマイ。
……ほんとにこれでいいのか?という気もするが。
2012-06-29 Fri
■ 間違ったパッチを当ててしまって、再度当て直したい時(無保証) [XenServer]
ちょっと昔のことで忘れましたが、XenServer 5.6 SP2 のインストーラでインストールすると、なぜか
- XS56EFP1007
- XS56EFP1008
があたってないぞ！って怒られちゃうんですよね。まぁXenCenterの表示上の問題なので、実害はないんですが、なんかすっきりしません。
で、なぜか 間違って XS56EFP1007 を当ててしまった日には最悪です。たとえば、SP2006 で更新されたファイルが、XS56EFP1007 で古いものに書き戻されてしまいます。
ならば再度 SP2006 を当てればいいじゃない！といいたいところですが、そうは簡単ではないです。なんとかパッチを消してしまいたいところですが、undo できません。
XS56SP2006 の patch uuid が da76a27e-80d4-4223-a601-ac4b21925937 だとして
# xe patch-destroy uuid=da76a27e-80d4-4223-a601-ac4b21925937
The specified patch is applied and cannot be destroyed.
詰んだ！
いやいや xe patch-clear があったはずだとか思うんですが、単純に
/var/patch
にあるパッチファイルを消すだけで意味がないです。ちなみに、消しちゃっても
# xe patch-upload filename=xs56esp2006.xsupdate
で戻ります。で、普通は再インストールしか手段はないんですが、強引になんとかできなくもないようです。
以下、完全無保証（元々このブログの記事全部ですが）
まず ls /var/patch すると、いかにも uuid っぽいファイルが置いてあります。
しかし残念ながら、patch の uuid とは一致してません。が、タイムスタンプとファイルサイズから、あたりをつけて、さらに gpg で暗号化されているので、復号化してやります。
# /usr/bin/gpg --homedir /opt/xensource/gpg --no-default-keyring \
--keyring /opt/xensource/gpg/pubring.gpg \
--decrypt /var/patch/c4e54bd4-9784-6e95-20fd-e209e2901f39 > /tmp/sp2006.sh
で、念のため patch のバックアップを一旦退避
# cd /opt/xensource/patch-backup/
# mv da76a27e-80d4-4223-a601-ac4b21925937 da76a27e-80d4-4223-a601-ac4b21925937.bak
このファイル名は、patch の uuid になってます(このディレクトリって、密かにDom0のディスク容量を圧迫している気が...)
で、復元したファイルを
# chmod u+x /tmp/sp2006.sh
して、
# cd /tmp
# ./sp2006.sh apply
を実行すると、そのパッチが再度実行されます。本当に対象の patch かどうかは、sp2006.sh を見れば、テキストなのですぐにわかります。
……こんなやり方わかるか！orz
参考
http://forums.citrix.com/thread.jspa?threadID=239060
こういった情報までドキュメントで公開されると嬉しいのになぁ……
2011-11-19 Sat
■ XenStore について [XenServer]
XenServer DomainUからXenの管理情報を読み取る
http://irgaly.net/2011/11/xenserver_domainu%E3%81%8B%E3%82%89xen%E3%81%AE%E7%AE%A1%E7%90%86%E6%83%85%E5%A0%B1%E3%82%92%E8%AA%AD%E3%81%BF%E5%8F%96%E3%82%8B
へぇーこれは知らなかった :-)
2011-11-19 Sat
■ XenServerのホスト(Dom0)から準仮想化のVMのコンソールへアクセスする [XenServer]
XenServer Domain0からDomainUのコンソールへアクセスする - infobase
https://twitter.com/#!/irgaly/status/137458334289756161
を読んで、そんな方法があるのかぁと思ったので、私も同じような記事を書いてみようかと。まったく同じ方法書いてもしかたないので、ここでは xl コマンドを使わない方法を。
まずはコンソールにつなげたい仮想マシンが動いている XenServerホスト(Dom0)へ sshでログインする
$ ssh root@xenserver
次に、対象のVMの dom_idを調べる
# xe vm-list params=dom-id name-label=rhel5
dom-id ( RO) : 80
ここまでわかれば、あと一歩
# /usr/lib/xen/bin/xenconsole <dom-id>
で接続可能なので、上記の例だと
# /usr/lib/xen/bin/xenconsole 80
で接続できる。表示が変わらない場合は、リターンキーを押してみると良い。ちなみに抜けるときは、Ctrl+] で抜けることが出来る。
ともあれ、方法としてはこっちの方法が古く、xl の方が主流になるのかなぁ。
See Also:
http://wiki.xensource.com/xenwiki/Xen_Cloud_Platform%3A_Access_to_VM_console
2011-10-25 Tue
■ Vyatta君の Id "T0" respawning too fast なるメッセージを止める [XenServer][Vyatta]
XenServer上で Vyatta を動かしていると
INIT: Id "T0" respawning too fast: disabled for 5 miutes
なんてメッセージが頻繁に仮想マシンのコンソールに吐き出されます。これは、XenServerで動かしている Vyatta にttyS0 が存在しないのにも関わらず、標準で ttyS0 のコンソールに関する設定が入っているためです。
なので
http://www.vyatta.org/forum/viewtopic.php?p=2559#2559
を参考に、Vyatta の設定モードから該当の設定を消してやります。
$ configure
# delete system console device ttyS0
# commit
# save
これで OK :-)
2011-10-20 Thu
■ 完全仮想化なCentOS5.6を準仮想化にする [XenServer]
XenServer Tips 完全仮想化のLinux VMを準仮想化対応に変更する
http://techtarget.itmedia.co.jp/tt/news/1109/06/news01.html
という記事が出るよ！という予告があってからわくわくしてたら、CentOSの例がなかったので、しょんぼり。
きっと誰かやってるよね！と Google 先生に聞きながらやってみたら出来たので、以下に備忘録として書いとく。
ちなみに参考URLにも記載しましたが
PV enabling an HVM from VMware on XenServer (CentOS RedHat)
http://itproctology.blogspot.com/2009/06/pv-enable-hvm-on-xenserver.html
がすごく参考になりました
■ HVMなサーバでの作業
1. なにはともあれ、Xen対応kernelをインストールする
# yum install kernel-xen
2. PVドライバ付きの initrd を作成する。
# cd /boot
mkinitrd --omit-scsi-modules --with=xennet --with=xenblk --preload=xenblk initrd-$(uname -r)xen-no-scsi.img $(uname -r)xen
ただ、uname -r の結果と、インストールした kernel-xen のバージョンが違うこともあるので、違っていたら頑張って打ち込む。
# cd /boot
# mkinitrd --omit-scsi-modules --with=xennet --with=xenblk --preload=xenblk \
initrd-2.6.18-274.3.1.el5xen-no-scsi.img 2.6.18-274.3.1.el5xen
次に、/boot/grub/menu.lst にある kernel-xen のあたりを下記のように書き換える。
title CentOS (2.6.18-274.3.1.el5xen-no-scsi)
root (hd0,0)
kernel /vmlinuz-2.6.18-274.3.1.el5xen ro root=/dev/VolGroup00/LogVol00 console=xvc0
initrd /initrd-2.6.18-274.3.1.el5xen-no-scsi.img
CentOS5.6 だと、/etc/inittab に
co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav
がもともと記載されているので、コンソール周りでのこれ以上の対応は不要だと思います。
もちろん、このセクションの kernel で boot するように
default=0
あたりを適当に書き換える必要があります。
で、ここでのありがちなミスが "modules" を "initrd" に書き換え忘れ。忘れてると、あとで
VFS: Cannot open root device "VolGroup00/LogVol00" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
とか言って、起動してくれません。
■ XenServerで、PV化を実施する。
次に、VMのパラメータを変更していきます。このあたりは、先日の vyatta のインストール [2011-10-19-1]とほとんど一緒です。
以下は、すべて XenServer上で実施します(対象VM名を HVM2PV にしてあります)
# xe vm-list name-label=HVM2PV params=uuid
ここで得られるのが、vm の uuid です。でこれをもとに作業していきます。
a) boot policyのクリアおよび bootloaderの指定
# xe vm-param-set uuid=<uuid> HVM-boot-policy=
# xe vm-param-set uuid=<uuid> PV-bootloader=pygrub
b) 利用している HDDの vbd uuid を調べる
# xe vm-disk-list uuid=<vm uuid>
で調べた vbd の uuid を指定して bootable にします。
# xe vbd-param-set uuid=<vbd uuid> bootable=true
これで、準仮想化(PV)の VM として起動してくれます。例によって、ログインプロンプトが出たけどコンソールから入力が受け付けられないよ！ってなった場合には、XenCenterを再起動してください。
まぁミスったら、この逆で
# xe vbd-param-set uuid=<vbd uuid> bootable=false
# xe vm-param-set uuid=<uuid> HVM-boot-policy="BIOS order"
# xe vm-param-set uuid=<uuid> PV-bootloader=
にして、起動させ、xen kernel じゃない kernel を grub menu から選択してもらえれば、復旧できるかと思います。
あとは、xen-tools を入れれば、XenMotionも可能になります。ただ、最初に紹介した記事にもあるように、仮想マシンにCDを入れっぱなしの状態にすると、
too many bootable disks
云々と言われて起動しなくなるので、注意が必要です。
参考URL
- http://itproctology.blogspot.com/2009/06/pv-enable-hvm-on-xenserver.html
- http://forums.citrix.com/thread.jspa?threadID=266975
2011-10-19 Wed
■ XenServer5.x系に Vyattaをインストールする [XenServer][Vyatta]
Vyatta は、ソフトウェアルータとして最近数年注目されています。仮想化の流行によって、その注目度も、さらに加速している気もしますが、XenServerで使ってるぜ！ってあんまり聞かない気がするので、インストール方法を書いときます。利用者が少なくてサポートが後手に...とかなっても悲しいので ;-p
http://www.vyatta.org あたりから
vyatta-livecd-virt_VC6.3-2011.07.21_i386.iso
を入手します。Vyatta 6.3 から、XenServer専用のテンプレート(xvaファイル)は提供されなくなって、すべてのこのISOイメージがベースとなってます
"CIFS ISO Library" あたりに入れておくといいでしょう。もしISO Libraryを 作ってないなら、XenCenterをインストールしている Windowsの1ディレクトリを CIFS ISO Library として登録してしまうと、お手軽で楽。
ともあれ、まず LiveCD で Vyatta を立ち上げます。XenCenterから
1. "New VM" で、VM Template として "Other install media" を指定する。
2. "Install from ISO library or DVD drive" で上記 isoイメージを指定(*1)
3. 1vCPU & Memory 512MB & HDD 4GB あたりで VMを作成(VM名は VC63あたりで）
で、しばらく待つとVMが立ち上がってくるので、Console からログインします。初期ID/Passは、ともに "vyatta"になってます。
で、このままだと普通に LiveCD で Vyatta が立ち上がっただけなので、インストールを開始します。そのまま "install-system"と type してください。
vyatta@vyatta:~$ install-system
でここからちょっと表示と改行タイミングがあってないので、リターンキー3回押したあとに、"Yes"と入力してリターンを押してください。で、再度リターンキーを押すと、インストールが開始されるのが、見えるはずです。
なにをやったかというと
Would you like to continues? (Yes/No) [Yes]: <- リターン1回目
Partition (Auto/Union/Parted/Skip) [Auto]: <- リターン2回目
Install the image on? [sda]: <- リターン3回目
Continue? (Yes/No) [No]: Yes <- "Yes"の入力とリターン4回目
How big of a root partition should I create? (1000MB - 4295MB) [4295]MB: <- リターン5回目
を入力したことになります。
で、
Which one should I copy to sda? [/opt/vyatta/etc/config/config.boot]:
と聞かれるので、そのままリターンを押します。すると vyatta ユーザの初期パスワードを聞いてくるので、適当に付けてやります
Enter vyatta password: <- 類推しづらいパスワードを入力
Retype vyatta password: <- 確認のため、再度パスワードを入力
さらに
Which drive should GRUB modify the boot partition on? [sda]:
で、そのままリターンを押します。すると、paravirtual で動作させるかどうか聞いてきますので、Yes と答えます。
conversion to PV domU? [No]: Yes <- "Yes"の入力とリターン
これでインストールは完了です。次に XenTools を導入します。一旦、VMをshutdownしましょう
vyatta@vyatta:~$ shutdown
Proceed with shutdown? [confirm] <- リターンを入力
shutdown が確認できたら、LiveCD を Eject して VMをスタートさせます。
VMが起動してきたら、ID : vyatta で、先ほど設定したパスワードと共にログインします。また、VM の DVD Drive 1 には xs-tools.iso を指定しておきます。
あとは、下記を実行(debパッケージのバージョンは、導入している XenServerのバージョンによって異なります）
$ sudo su -
# mount /dev/cdrom /mnt
# dpkg -i /mnt/Linux/xe-guest-utilities_5.6.100-651_i386.deb
# umount /mnt
# shutdown
これで、Xen Tools の導入が完了です。が、まだ終わりません。この状態だと、完全仮想化で動くので、パフォーマンスもよくないですし、XenMotion もできません。このため、このVMを準仮想化として動作させるように XenServer 側で設定していきます。
まず、XenServer(ホスト側）にログインし、対象のVMの uuid を調べます。
# xe vm-list name-label=VC63
次に、PV で起動するようにブート関連のパラメータ設定を変更していきます。<uuid> には、上記コマンドで調べたVM の uuid を指定します。長いですが、数文字打ち込んで "Tab" キーを押せば補完入力も可能です。
# xe vm-param-set uuid=<uuid> HVM-boot-policy=
# xe vm-param-set uuid=<uuid> PV-bootloader=pygrub
次に、boot させるHDDの属性を変更します。まず最初に
# xe vbd-list vm-name-label=VC63
で、VMにつながっている HDD をチェックします。今回の例だと、device が hda と表示されているはずです。これを bootable=true にします。
# xe vbd-param-set uuid=<uuid> bootable=true
ここで指定する uuid は、vdi-uuid *ではない* ことに注意してください。vbd の uuidです。
ここまでくればあと１歩。これで reboot すれば、準仮想化として動作するはずです。が、ログインプロンプトまで順調に表示されるものの、入力ができない状態に陥るかと思います。
理由はよくわかりませんが、慌てずに一旦 XenCenter を終了させ、再度 XenCenter を起動させてみてください。今度は普通につながるはずです。
あとはよく使う Firewall のルールを入れ、/config/config.boot から "interface ethernet"を削除してからこのVMをテンプレート化してしまえば、仮想ルータを作り放題です :-)
参考: http://www.vyatta.org/getting-started/how-to-install
2011-10-17 Mon
■ XenServer Configuration Limits [XenServer]
XenServer Configuration Limits
https://support.citrix.com/servlet/KbServlet/download/28909-102-661481/XenServer-6.0-Configuration-Limits.pdf
XenServer 6.0 系ですが、制限事項などがまとまってます。