ラベル libvirt の投稿を表示しています。 すべての投稿を表示
ラベル libvirt の投稿を表示しています。 すべての投稿を表示

2009/04/05

シェルスクリプト内でXMLから情報を取り出す

XML形式により情報をやり取りすることが多くなった昨今、シェルスクリプト(shell script)でXMLを扱うことも増えてきた。例えば、libvirtを使って
virsh dumpxml DomU名
として得た仮想マシンの設定情報などだ。Xen DomU dc1の設定ファイル/etc/xen/dc1が、
name = "dc1"
uuid = "4df3f764-00cb-42a6-8ff6-a98985cbda14"
maxmem = 256
memory = 64
vcpus = 1
bootloader = "/usr/bin/pygrub"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
vfb = [ ]
disk = [ "phy:/dev/VolGroupXX/LogVolDc1,xvda,w" ]
vif = [ "mac=00:16:3e:ff:ab:01,bridge=br1000",
"mac=00:16:3e:ff:ab:02,bridge=br2000" ]
だったとしよう。このdc1の設定をXML形式で得ると、
# virsh dumpxml dc1
<domain type='xen' id='18'>
<name>dc1</name>
<uuid>094a82d5-7e6c-980d-49d3-9e8e68fb84e2</uuid>
<bootloader>/usr/bin/pygrub</bootloader>
<os>
<type>linux</type>
<kernel>/var/lib/xen/boot_kernel.rMNCqh</kernel>
<initrd>/var/lib/xen/boot_ramdisk.og2mn7</initrd>
<cmdline>ro root=/dev/VolGroup00/LogVol00 console=xvc0 acpi=off nopcmcia noapm nousb nofirewire nosound</cmdline>
</os>
<memory>262144</memory>
<currentMemory>65536</currentMemory>
<vcpu>1</vcpu>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<interface type='bridge'>
<source bridge='br4000'/>
<target dev='vif18.0'/>
<mac address='00:16:3e:1d:89:01'/>
<script path='vif-bridge'/>
</interface>
<interface type='bridge'>
<source bridge='br2002'/>
<target dev='vif18.1'/>
<mac address='00:16:3e:1d:92:01'/>
<script path='vif-bridge'/>
</interface>
<disk type='block' device='disk'>
<driver name='phy'/>
<source dev='/dev/VolGroupXX/LogVolDc1'/>
<target dev='xvda'/>
</disk>
<console tty='/dev/pts/1'/>
</devices>
</domain>

#
のようになる。このとき、ディスクに関する情報を取り出したいとしよう。
まず、XML形式をファイルに保存する。
# virsh dumpxml dc1 > dc1.xml
#
このファイルを引数として、xmllintコマンドを対話モードで起動する。
# xmllint --shell dc1.xml
/ >
プロンプトの「/」は、現在のXML文書上のパスを示している。
ここで「cat」と入力すると、現在のパス以下の内容すべてが表示される。つまり、XMLファイルの内容すべてが表示されることになる。
/ > cat
<?xml version="1.0"?>
<domain type="xen" id="18">
<name>dc1</name>
<uuid>094a82d5-7e6c-980d-49d3-9e8e68fb84e2</uuid>
<bootloader>/usr/bin/pygrub</bootloader>
<os>
<type>linux</type>
<kernel>/var/lib/xen/boot_kernel.rMNCqh</kernel>
<initrd>/var/lib/xen/boot_ramdisk.og2mn7</initrd>
<cmdline>ro root=/dev/VolGroup00/LogVol00 console=xvc0 acpi=off nopcmcia noapm nousb nofirewire nosound</cmdline>
</os>
<memory>262144</memory>
<currentMemory>65536</currentMemory>
<vcpu>1</vcpu>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<interface type="bridge">
<source bridge="br4000"/>
<target dev="vif18.0"/>
<mac address="00:16:3e:1d:89:01"/>
<script path="vif-bridge"/>
</interface>
<interface type="bridge">
<source bridge="br2002"/>
<target dev="vif18.1"/>
<mac address="00:16:3e:1d:92:01"/>
<script path="vif-bridge"/>
</interface>
<disk type="block" device="disk">
<driver name="phy"/>
<source dev="/dev/VolGroupXX/LogVolDc1"/>
<target dev="xvda"/>
</disk>
<console tty="/dev/pts/1"/>
</devices>
</domain>

/ >
ただし、xmllintの出力は正規化されているため、先頭行が追加されている。
ディスクに関する設定は、XPath形式で表せば、「/domain/devices/disk」にあることが解る。これをcatで出力してみる。
/ > cat /domain/devices/disk
-------
<disk type="block" device="disk">
<driver name="phy"/>
<source dev="/dev/VolGroupXX/LogVolDc1"/>
<target dev="xvda"/>
</disk>
/ >
さらに、ソースデバイス名のみを抽出してみよう。
/ > cat /domain/devices/disk/source/@dev
-------
dev="/dev/VolGroupXX/LogVolDc1"
/ >
これを非対話的に実行するには、
# echo "cat /domain/devices/disk/source/@dev" | xmllint --shell dc1.xml
/ > -------
dev="/dev/VolGroupXX/LogVolDc1"
/ > #
とすればよい。
これと同様の操作をネットワークインターフェースに対して実行してみる。
# echo "cat /domain/devices/interface/source/@bridge" | xmllint --shell dc1.xml 
/ > -------
bridge="br4000"
-------
bridge="br2002"
/ > #
XPath /domain/devices/interfaceにマッチする要素は二つあるので、出力も二つだ。
これらのうち、二番目のものだけを出力するには、
# echo "cat /domain/devices/interface[2]/source/@bridge" | xmllint --shell dc1.xml
/ > -------
bridge="br2002"
/ > #
とする。

2009/04/03

A backup script for Xen DomUs, part 2

A backup script for Xen DomUs, part 1』で紹介したスクリプトxen-backup.shについて解説する。

このスクリプトの大まかな流れは以下の通り:
  1. バックアップ設定ファイルの読み込み: 182行目
  2. バックアップを実行するかどうかの検査: 183行目~215行目
  3. DomU設定の解析: 217行目~228行目
  4. ディスクイメージのマウント@ローカル: 230行目~254行目
  5. ディスクイメージのマウント@リモートDom0: 256行目~263行目
  6. Rsyncによるバックアップ: 265行目~266行目
  7. ディスクイメージのアンマウント@リモートDom0: 268行目~274行目
  8. ディスクイメージのアンマウント@ローカル: 277行目~280行目

バックアップを実行するかどうかの検査
DomUの状態を表示するコマンド
virsh domstate DomU名
を使って、以下の各項目を検査する。
  1. 対象DomUが、ローカルDom0でホストされいるか?
  2. 対象DomUが、ローカルDom0で正常に実行されているか?
  3. 自分自身がDOM0Sに含まれているか?
すべての検査に合格すれば、バックアップを実行する。

DomU設定の解析
コマンド
virsh dumpxml DomU名
で対象となるDomUの設定(XML形式)を得て、ディスクイメージ情報を抽出する。
このとき、関数get_value_from_configを呼び出す。
115: get_value_from_config()
116: {
117:     local xml=$1 num=$2 elem=$3 attr=$4
118:     echo "cat /domain/devices/disk[$num]/$elem/@$attr" | \
119:         xmllint --shell $xml | \
120:         awk -F\" '/^ +'$attr'/{print $2}'
121: }
この中ではxmllintコマンドを使用している。ディスクイメージに対する設定項目/domain/devices/diskは、複数指定される可能性があることに注意。

ディスクイメージのマウント@ローカル
各ディスクイメージをローカルにマウントする。
マウントする前に、ディスクイメージのスナップショットを撮っている(『XenとLVM・その3・スナップショットLVの利用』参照)
238:                 lvcreate --snapshot --name=$snapshot_name --size=$SNAPSHOT_SIZE ${disk_source[$i]}
239:                 add_close_command "lvremove -f /dev/$vgname/$snapshot_name"
240:                 analyze_disk /dev/$vgname/$snapshot_name
マウント時と反対の動作をバックアップ後に実施する必要があるため、add_close_command関数(34行目~38行目)を使って記録する。
実際の解析は、analyze_disk関数(124行目~175行目)を使っている。

analyze_disk関数
マウント時の動作は、リモート側でも実行する必要があるため、add_open_command関数(14行目~19行目)で実行および記録する。
与えられたデバイス$the_diskに対して、
131:     part_type=`parted -s $the_disk print | awk '/^Partition Table:/{print $3}'`
でパーティションの種類を得ている。これがDOSパーティションなら、パーティション毎に分割し、それぞれに対して処理する必要がある。
134:             add_open_command "kpartx -a -p $PSEP $the_disk"
135:             add_close_command "kpartx -d -p $PSEP $the_disk"
ここで、kpartxコマンドに対するオプション「-p 区切文字」を指定していることに注意。例えば、/dev/VolGroup00/LogVolDomUに対して、
kpartx -a /dev/VolGroup00/LogVolDomU1
を実行すると、パーティションごとに
/dev/mapper/LogVolDomU1
/dev/mapper/LogVolDomU1
等のデバイスが作成されるが、元のデバイス名の最後が数字の場合、例えば/dev/VolGroup00/LogVolDomU1の場合は、
/dev/mapper/LogVolDomU1p1
/dev/mapper/LogVolDomU1p1
の様に区切文字「p」が挿入される。オプション「-p 区切文字」を指定すれば、どちらの場合も区切文字が挿入されるので都合が良い。なお、「kpartx -a -p 区切文字」で作成したデバイスは、「-p」を指定して「kpartx -d -p 区切文字」としないと削除できない(この辺りの動作は、kpartxのmanpageにも触れられていない)
136:             while read device[$num] fs_type[$num] mount_point[$num]; do
137:                 ((num++))
138:             done <<EOF
139: $(parted -s $the_disk print | awk '/^ *[0-9]+ /{print $1" "$6" "$7}')
140: EOF
この部分は、一見
parted -s $the_disk print | awk '/^ *[0-9]+ /{print $1" "$6" "$7}' | while read device[$num] fs_type[$num] mount_point[$num]; do
((num++))
done
の様に書き直せそうだが、期待通りの動作とならない。なぜなら、readコマンドをパイプの後で使うと、readコマンドがサブシェルで実行され、サブシェルの変数には代入されるが、元のシェルの変数には反映されないため。
最終的に、mountコマンドでマウントされるデバイスにまで分割できたら、add_fs_table関数(52行目~57行目)で記録しておく。ディレクトリ階層の高い順にマウントする必要があるため、すべてのマウントポイントを解析し終えてからマウントする(252行目~254行目)。

ディスクイメージのマウント@リモートDom0
リモートDom0に対して、SSH経由でマウントを実行する。
258:         ssh -T $remote_dom0 <<EOF
259: ##### COMMANDS FOR TARGET TO OPEN
260: `exec_open_commands | sed 's/-'$$'//'`
261: mkdir -p $target_prefix
262: `mount_fs_all $target_prefix | sed 's/-'$$'//'`
263: EOF
入力がTTYでないことを明示するため、sshコマンドには、「-T」オプションを与えている。

Rsyncによるバックアップ
266:         rsync -avz --delete -e ssh $source_prefix/ $remote_dom0:$target_prefix
引数「$source_prefix/」の最後のスラッシュは必須。省略すると、期待通りに動作しない。


A backup script for Xen DomUs, part 1
A backup script for Xen DomUs, part 2

A backup script for Xen DomUs, part 1

XenのDomUを運用する際、複数のDom0(物理サーバ)を準備しておき、DomUのディスクイメージ(以下、単にイメージ)を共有しておけば、一台のDom0が故障しても、健全なDom0でサービスを継続することが可能だ。
Dom0間でDomUイメージを共有する方法には、iSCSIを使う方法や、DRBDを使う方法があるが、CentOSのiSCSIターゲット(ストレージ側)やDRBDには問題があり、今のところ安心して採用できない(iSCSIターゲットに専用機器を使えば問題無いが、金がかかる)

そこで紹介するのが、今回のバックアップスクリプトxen-backup.shだ。このスクリプトは、rsync(1)を使うため、単純にディスクイメージをネットワークコピーするより圧倒的に早い。また、Xen固有のコマンドを一切使わず、virshコマンドを使っている。このため、libvirtがサポートしている他の仮想環境、kvmなどでも使用できるかもしれない(未確認)。
前提条件は以下の通り:
  1. Dom0間で、rootによるSSHログインが可能であること。
  2. 論理ボリューム(logical volume, LV)上にイメージが保存されていること。
  3. 各DomUに対して、ディスクイメージLV名が一致すること。
  4. Dom0とDomUのボリュームグループ名(volume group, VG)が重複しないこと。
  5. 実行前に別途フルバックアップを実行すること。
  6. 無保証
前提条件1.は、rsyncを安全に使うため必要。完全に自動化したい場合は、このバックアップ用の公開鍵を作成し、秘密鍵のパスフレーズを外した状態で、各Dom0のrootに配布すればよい。
前提条件2.は、動作中のDomUに対してスナップショットを撮ってバックアップするための条件。スナップショットが必要ない場合は、ファイルや物理的なディスクパーティションに対して動作させられるよう改造するのはそう難しくないだろう。
前提条件3.は要するに、DomUの設定ファイルが(ディスクイメージに関して)完全に一致すれば良い、ということだ。これは単に私の手抜きの結果。LV名が異なる場合は、コピー元・コピー先それぞれのDom0上で設定ファイルを解析するよう改造が必要。
前提条件4.については、『パスワードを紛失したDomUをリカバリ』に書いた通りで、具体的には、DomoのVG名を、標準の「VolGroup00」から「VolGroupXX」に変更してインストールする(DomUのVG名を標準のままでよい)。『Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる・その2・Dom0 fsXのインストール』を参照。
前提条件5.は、使用前に例えば、
[root@dom0a ~]# dd bs=16M if=/dev/VolGroupXX/LogVolDomU1 | ssh dom0b 'dd bs=16M of=/dev/VolGroupXX/LogVolDomU1'
を実行する必要がある。今回のスクリプトでは、パーティション情報やLVM情報はコピーされないためだ。

なお、今回のスクリプトでは、対象DomUが実際に動作しているDom0上から、他のDom0へコピーを行う。これは、誤って古いイメージから新しいイメージへ書き戻すのを防ぐため。

スクリプトを実行する前に、各DomUに対する設定ファイル/root/Works/Xen-Backup/xen-backup.d/*.confを準備する(通常は、DomU名.conf)。設定項目は次の二つのみ:
DOMU
DomU名
DOM0S
このDomUのイメージを保存するDom0。空白で区切って並べる。ネットワーク的に到達可能な名前でなければならない。
例えば、DomU domu1に対する設定ファイル/root/Works/Xen-Backup/xen-backup.d/domu1.confならば、
DOMU=domu1
DOM0S="dom0a dom0b"
となる。この場合、domu1は、dom0a dom0bでホストされている。

xen-backup.shをダウンロード

コードは以下のbase64形式を、xen-backup.sh.b64として保存しておき、以下のコマンド
cat xen-backup.sh.b64 | base64 -di | gunzip > xen-backup.sh
で復元して使用する。

2009/4/5(日)追記:
ログをSYSLOGで出力するように変更した。

2009/4/6(月)追記:
重複実行を排除した。

2009/4/7(火)追記:
エラーもログされるよう変更した。
Cronからでも正常に実行されるよう、PATHを設定するように変更した。

2012/11/30(金)追記:
ファイルをダウンロードできるようにした。

H4sIAIcc2kkCA9VZbXPbuBH+LP4KHI2pbKc05eTaTu0wV53fznOO7bHl6V0Tn8SQkMQx34agZDuO
/3t3AZAEKDF10g+dJjMRAewudh/sG5CNH9xPUep+8vncOhuen3gH1uVw9IvnLnjhxlngxy4Hgj1t
LIZysl5paODDskIWxH7BiFOQg4vz4/Hh6ZXnFllWuv/Mijvu/sZS52c/uFvk7gN8fhKfO6HO99v7
s+9hu764uTo4Qs7x6OLSc5O0dHm2KAKmU42GVydHI5Oq9IsZKw1Z58PL618uRuPr038debsn+tr7
38fDw8Ora28ibHejnPhhWBA+z+7JF1IWpO/2Cf79Qvz7Oxj9QbajlJXEfcqLKC0Jff3cn+giL6+P
Lr1+3tfnzi5OxqPhiTeBA2KpnzBCBx8ovTUZTw/Hx6dnR5679Au3WKSuTj7ZyaMGIhR4PDw4PTsd
/e6J83xjrF1cjk4vzj3btqw4m40TxmebW9aTReCPICcxW7LYo7tiis+jaakWZzNWEAcMU0oTJ5ff
1X47VPDKSbkRodvWs9yKl2GUvmyv+3kUM1IwPyQxYLpPwszqsWCeEYpjgPz7tBHCwyxlqFMNsE+y
nKXjIEsSPw15sxCRdFwvpX7IvYFlgReMdfraIrYEg+iuVE5aS6J0mpHX7/4kDTS2+UBTQw6/rXDY
3GytvHq1tYUaswcWmCstOCNQsMHvA6ERcWKAqCWP3OqIPrXUim6frd7mZiR27QAsiDPOOhBr1nTI
DI5abVMOQmLOGJiYSwYo5tIKKityV1CalWRQwQK2Ow4Ir/BpK4kAdeAy5ePS/xQzE5F6ViBRjWot
N+Q+0tBqFbGovg0UqsnK/iRbpCXO+nHcMjwv2DR6WBfKylmIZM4zzFchW0YBEwo85qzDj6rdWy7U
aA3g7Nfus1/jBFHx0erxrCiJc7f7Z4gSGGph3q2I3AflaDTeRG4sLaQ69xfCWUj63P3oUteFDCx4
BbkgEzlDyYbsRKjaThdiHO8i/f+DuPgforyQMHfiGfFx8oi1q4ZSVuZxlHuTecZLmURlUSVzn4vC
yzhvKuuPWFmRM5oCdD8Q5zOhtRDErZyz1OpNs4IkjzgFqZhWFb0xVXBTSeF5a0X0ClYuipQMJMc0
snrCDjXAH0Wxq2wDvoKNw4jftVzlIakrnZxIF4lHX1s1cHbgQ/cQZokP/YY8Hu6iIMgFi+TWBlBA
RowIOA6fsxjKDUzANJsVLCf9P94idZ+8I8jupgugEMUHNEPDoEAt2HhaZAlks3QazdZqqPQiLGbw
+4b4ZVl49McX6+lS5HT/QZHRll7ZoTes4DE7xx9t0UC96gumvt5CofJ+6sePn9eiCnCLaRNaSMWm
f5O2N6rw9YuyicXmWAYidJezseix4qX8vRPk+GkJ+prbm+AnBITDwYuURkTaULeHl0ASlVGWkhHG
8V5t5JvKmwNo6iDaKqngtVYv4WHGt6T3tVsPYguNHtBc7H6wwWz2txsmo4I1XGE3l5Y0JJDybCs4
1UgDVc7I2ILcBANRoHp1dnr79uji2HoJUGT7w8D5++2rJt53bWLTv+I/f0OsUJAMYG+gq6tl0UVS
pc+eRPWp1hzSp0BWMIJXLh4cfu/noGuvt79fzS8TMaFcAA54yQM/BSVFqNEn+kyfEDn4qQBCwcoI
I1GBmNWTW86CuZ/OsGt4JFRtY1e0rQPTiFOTGFNc5Z6Q5Cbxklc60NeeZ/cr6r5NajRBKYWN9BAt
umTmqJhcqmQjqch7OkbbAqEmKKpyUZ+rVMQ5dhtAzo81ROpKZ7v0yfAlhFJokvh5zgpYbrZ5zk3I
zaO1axUZ9wPhi5HpifILSeIsy9WC7umDxs0Hpo/D8L92478IXzbcuNNDTe+s1O5tV6OvgjhAbGrl
GvEDCVIlTaR1AZWaqScg8dZ3RHmTsTfINRRJMGVAJqFfsoltiSLqTCGPqFtqXTzVrdHg3wBvy7BE
AlpZgEU94gRutGmUzmyLxZw1dYZSqGS1WFlywd2xdI2nGO9Y1avnB3d7BxekXx9evL/BKy5+DK7F
1w6hNSOefFutYM6CO1CCHGbJDaEowcZan/AS7PQmy6jgc1KNJQEU16bSgldDJwAl1qM/WT3ZWsgJ
4kD6GzQ9xXpcrn89vdzTdkdgACqCHRF4GpSNcg5TOFQ5GuwpwUHAHGxLpBPVCkZqIz5flB9JNp1u
fevG6lS+vrPuRUHhQ3UPv4SPwIYu+vK90qyAbiKOH7t2FSEt3VS7bhUsyUpw8CwZcMAcq4Go4WJG
HDs6DA6ErwhvMNq/uhcVyA3qrk+TIhZUmKB7YkvY7IrBWpGYqaZuFaUvYIvaSH2hM6C+oC6TIEVp
EC9C9h/8YFXYz8ODX29M2MtMYYeTg02+tUc+0CfDsO3b51vbsnob5OpoeCie+U5Prob4jHItGjqP
qic8V8jcgSmrp8JkkeTY4cnN3ol2D89n1zg9zEvjsIiWkA3Et3zHk9/qtU7dXoy+WnaPNGpOUpMk
DmSyttut+IjaE899ogmQ279EQKUoW+r8UuWX8EtKjb/2HOkxKcrjHo0E/u8vbs5HCr6VRkdQVr2O
VkxakKiCks8fq9rBUz/n88ws3U8tIJ7X1XBsahxKlZzl7JsFvJE9wFrX31BdOPqlHjF7ANodq7Um
1NBfFIY1m99H5Zzw6DMgYjz22nWbF0DlhzCAi0kl2XGEQa0NgADEeKaY9faue/7rdfXi8RKjbsmw
hFa9l2y9jP0rhdf2amvo17YLOtgSaxUJ69xF5hy+yPNMtDqRSshAweES091CmL6MLxIIzli9lIin
ePmI71IqU4fVUzdvnUY+4Tc0cBW6C6NCXFkMkV2IrybCLs8SXRMYpL/ztDdxIGNm+Owx79hP1hot
hYqSo6fUJkbXeL2Wjg2uRjsRtLC9MzIIZEfaodRk9cm4ebpx+pT2xeNNg6xxENbERMRYXCcHO9pO
C/ljGqiKgDnRKIdQj3SblLWFYHH85WcIv5DFDAOVSRAc9iCroVsmbY9wTQRX9F5/fN98MOph8HuP
xnxXfAG6m0FIMDT2SZGo82oFyZY6cPPFelVWdY11lqTKP+o6omL25bHTgNC2px2knZHTW2NYK0Ns
dbF2mDv/yv/C1O93RaLdLqB1WrnrMEjQ8v8gCQ+KKC/rS8+/ARtDd5VWHQAA


A backup script for Xen DomUs, part 1
A backup script for Xen DomUs, part 2

2008/12/16

Libvirt & Xen その2 予備調査: xm

Libvirtの使い方の前にxmコマンドについて調査する。

このコマンドとXenハイパーバイザとの通信については、『White Paper: Basic components of Xen』で解説されている。Xenの標準UIであるxmコマンドは、デーモンxendとXML RPCによって通信を行い、Dom0を通じてXenハイパーバイザを制御する。ここで使われるXML RPCインターフェースは、UNIXソケットで、アクセスにはroot権限が必要だ。

実際に試してみよう。
[root@fs1 ~]# /usr/sbin/xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 3673 2 r----- 28871.0
[root@fs1 ~]#

[user01@fs1 ~]$ /usr/sbin/xm list
ERROR Internal error: Could not obtain handle on privileged command interface (13 = Permission denied)
Error: Most commands need root access. Please try again as root.
[user01@fs1 ~]$
通常ユーザでxmコマンドが失敗するのは、xendと通信する際に使用するUNIXドメインソケット/var/run/xend/xmlrpc.sock(CentOS/RHEL/Fedoraの場合)には、root権限でないと書き込めなからだ。
[root@fs1 ~]# ls -l /var/run/xend/xmlrpc.sock
srwxr-xr-x 1 root root 0 Dec 8 13:39 /var/run/xend/xmlrpc.sock
[root@fs1 ~]#
また、xmコマンドは、このUNIXドメインソケットの他に、/proc/xend以下のファイルも利用する。実は、最初のエラーメッセージ「ERROR Internal error: Could not...」は、/proc/xen/privcmdを開こうとしたときのもので、次のエラーメッセージ「Error: Most commands...」は/var/run/xend/xmlrpc.sockを開こうとしたときのもの。

これは、straceコマンドを利用して、
[user01@fs1 ~]$ strace /usr/sbin/xm list > strace-xm-log.txt 2>&1
[user01@fs1 ~]$
の様に実行することにより、確認できる。

以上、Xenハイパーバイザは、主にデーモンxendの提供するインターフェースを通じて制御する。デーモンxendが提供するインターフェースは、三種類のアプリケーション層(HTTP、XML-RPCおよびXen Management API)、二種のトランスポート層(UNIXドメインソケットおよびTCP)の計六種類が提供されている。設定は、/etc/xen/xend-config.sxpで行う。上で使ったUNIXソケット/var/run/xend/xmlrpc.sockもこのファイルの中で設定さていれる。
TCPを利用したインターフェースは、ネットワーク経由で操作することが可能。しかし、HTTPやXML-RPCは、セキュリティは十分ではない。IPアドレス・ドメイン名ベースのアクセス制御があるのみで、認証や暗号化はサポートされていない。SSHのポートフォワーディングと併用するなど、別途セキュリティを確保する必要がある。

2008/12/09

Libvirt & Xen その1 概要

このシリーズでは、Libvirtを使ったXenの管理について解説する。

Libvirtの利点は二つある。

一点目は、他の仮想化ソリューションへの移行が容易になることだ。
現時点でCentOSおよびRHELでは、仮想化ソリューションとしてXenとKVMをサポートしているが、今後Xenはサポートから外される方針のようだ。Xenユーザにとっては、KVMへの移行が今後の課題となるだろう。
移行時の課題の一つが、管理方法の変更だ。Xenでは通常、xmコマンドを用いて管理する。これはXen専用のコマンドなので、KVMを管理することはできない。
CentOSおよびRHELでは、KVMとXenを統合管理するために、RPMパッケージlibvirt準備されている。Libvirtによる管理に慣れておけば、XenからKVMへの移行に役立つだろう。
Libvirtは、XenとKVMの他に、QEMU、Linux Containers、OpenVZ、UMLをサポートしている。将来的にはVMwareもサポートされる予定だ。

二点目は、セキュリティだ。
リモート管理の場合、Xenのアクセス制御は、IPアドレス・ホスト名ベースのものしかなく、貧弱だ。一方、Libvirtでは、ユーザ名・パスワード認証、Kerberos認証、および、TLS(SSL)による認証(および暗号化)をサポートしている。Iptablesを併用すれば、IPアドレスベースのアクセス制御も可能だ。
ローカルからの管理の場合、XenもlibvirtもUNIXソケットを使うが、Xenでは、rootに対する読み書き権限が与えられ、その他のユーザに関しては、読み取り権限が与えられていて、基本的に変更できない。一方、libvirtでは、任意の1グループを特権グループとして設定することができ、これに対して書き込み権限を与えることもできる。また、PolicyKitを使ったアクセス制御を行うこともできる。

2008/12/16追記:
Xenの新しいバージョンでは、新しい管理API・XenApiが準備されている。『XM and XenAPI developement on Xen Summit April 2007』によると、TLSによる暗号化やPAM認証が使えるらしい。