ブートローダには仮想化ソフトウエアの起動と実行に関する制御が含まれています。 YaST を使用するか、もしくは直接設定ファイルを編集することで、ブートローダプログラムの設定を変更することができます。
YaST のブートローダプログラムは
› › にあります。 タブを選択して、 Xen カーネルを含むものを で選択してください。設定が終わったら
を押します。これでホストの次回の起動時に Xen が読み込まれ、 Xen 仮想化環境を使用できるようになります。ブートローダプログラムを使用することで、様々な機能を調整することができます。具体的には下記のようなものがあります:
カーネルのコマンドラインパラメータの指定
カーネルイメージと初期 RAM ディスクの指定
特定のハイパーバイザの選択
ハイパーバイザに対する追加パラメータの指定。詳しくは https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html (英語) をお読みください。
仮想化環境のカスタマイズに際しては、 /etc/default/grub
ファイルを編集してください。このファイルに対して、 GRUB_CMDLINE_XEN="<パラメータ>"
のような行を追加します。なお、編集後は忘れずに grub2-mkconfig -o /boot/grub2/grub.cfg
を実行してください。
ホスト側の物理ディスクの容量がいっぱいになり空き容量が無くなると、スパース (疎な) イメージファイルをベースとした仮想ディスクを使用している仮想マシンは、ディスクへの書き込みができなくなります。これにより、 I/O エラーが発生することになります。
このような状況に陥ってしまった場合、まずは物理ディスク側にある不要なファイルを削除するなどして容量を空けてください。その後、仮想マシン側のファイルシステムを再マウントして、ファイルシステムを書き込み可能な状態に戻してください。
スパースイメージファイルが実際に使用している容量を調べるには、 du -h <イメージファイル名>
を実行します。
スパースイメージファイルの容量を増やすには、まずファイルサイズを増やしてから、ファイルシステム側のサイズを増やしてください。
パーティションのサイズを変更する場合もスパースファイルのサイズを変更する場合も、処理の失敗に備えて必ずバックアップを採取しておいてください。バックアップ無しに作業を行ってはなりません。
イメージファイルのサイズ変更はオンラインで実施することができます。つまり、 VM ゲスト が動作している間でも実行することができます。スパースイメージファイルのサイズを拡張するには、下記のコマンドを入力して実行します:
>
sudo
dd if=/dev/zero of=<イメージファイル> count=0 bs=1M seek=<サイズ_(メガバイト単位)>
たとえば /var/lib/xen/images/sles/disk0
というファイルを 16GB まで拡張させたい場合は、下記を実行します:
>
sudo
dd if=/dev/zero of=/var/lib/xen/images/sles/disk0 count=0 bs=1M seek=16000
非スパースファイルをベースにしたイメージファイルの場合であっても、イメージファイルのサイズを拡張することができます。ただし、この場合は現時点でのイメージサイズを正確に知っておかなければなりません。現時点でのイメージサイズを seek パラメータに設定して、拡張するサイズを count サイズで指定します:
>
sudo
dd if=/dev/zero of=/var/lib/xen/images/sles/disk0 seek=8000 bs=1M count=2000
なお、 seek の値を間違えてはなりません。誤った値を指定してしまうと、データの一部を消してしまうことになります。
サイズ変更の作業時に VM ゲスト が動作中であった場合、 VM ゲスト 側にイメージを提供しているループバックデバイス側でもサイズ変更を行う必要があります。まずは下記のコマンドを実行して、現在使用しているループバックデバイスを検出します:
>
sudo
losetup -j /var/lib/xen/images/sles/disk0
あとはループバックデバイスのサイズを変更します。たとえばループバックデバイスが /dev/loop0
である場合は、下記のようなコマンドになります:
>
sudo
losetup -c /dev/loop0
あとはゲストシステム内でブロックデバイスのサイズを確認します。具体的には fdisk -l /dev/xvdb
のようなコマンドを入力して実行し、確認を行います。なお、デバイス名はお使いの環境に合わせて変更してください。
スパースファイル内にあるファイルシステム側の変更については、使用しているファイルシステムの種類によって異なりますので、対応するツールをお使いのうえ変更を行ってください。
Xen では、ほとんどサービスの停止を伴うことなく VM ゲスト のシステムを一方の VM ホストサーバ から他方の VM ホストサーバ に移行することができます。これはたとえば、負荷の重い VM ゲスト をより強力なハードウエアの搭載された VM ホストサーバ に移行したり、負荷に余裕のある VM ホストサーバ に移行したりする際に使用します。また、何らかの理由で VM ホストサーバ を停止させる必要が発生した場合、その中で動作している VM ゲスト を他の VM ホストサーバ に移行して、サービスの停止を回避するためにも使用します。ここには 2 種類の理由しか記述していませんが、実際にはさまざまな理由で移行が必要となることがあります。
移行を開始する前に、まずは VM ホストサーバ に関するいくつかの事前要件を考慮する必要があります:
移行に関わる全ての VM ホストサーバ のシステムで、同じような CPU を使用する必要があります。動作周波数などは異なっていてもかまいませんが、同一のファミリの CPU を使用しておく必要があります。 CPU に関する詳細は、 cat /proc/cpuinfo
を実行すると取得することができます。ホスト CPU の機能比較に関する詳細については、 29.3.1項 「CPU 機能の検出」 をお読みください。
特定のゲストシステムが使用している全てのリソースは、移行に関わる全ての VM ホストサーバ から使用できなければなりません。具体的には、使用している全てのブロックデバイスは、両方の VM ホストサーバ システム内に存在していなければなりません。
移行処理に関わる VM ホストサーバ が異なるサブネット内に存在している場合、ゲストに対して DHCP リレーを提供する必要があります。なお、ゲスト側で固定のネットワーク設定を使用している場合、ネットワークの設定果て座興で修正する必要があります。
PCI パススルー
などの特殊機能を使用していると、問題が発生する場合があります。異なる VM ホストサーバ 間で VM ゲスト を移行する可能性がある場合は、これらの機能を使用しないでください。
移行を高速に行うには、ネットワークも高速化してください。可能であればギガビットイーサネットで高速なスイッチを使用してください。また、 VLAN を使用することで、衝突を防ぐことができます。
cpuid
および xen_maskcalc.py
のツールを使用することで、移行元と移行先の VM ゲスト に存在する CPU の機能を比較することができます。これらのコマンドを使用することで、ゲストの移行が正しく完了するかどうかを事前によりよく予測することができるようになります。
現在動作中の Dom0 と移行先の VM ゲスト 内で cpuid -1r
を実行して出力を比較します。たとえば下記のようになります:
tux@vm_host1 >
sudo cpuid -1r > vm_host1.txttux@vm_host2 >
sudo cpuid -1r > vm_host2.txttux@vm_host3 >
sudo cpuid -1r > vm_host3.txt
出力されたテキストファイルを xen_maskcalc.py
スクリプトがインストールされたホストに集めます。
あとは出力された全てのテキストファイルに対して xen_maskcalc.py
スクリプトを実行します:
>
sudo
xen_maskcalc.py vm_host1.txt vm_host2.txt vm_host3.txt cpuid = [ "0x00000001:ecx=x00xxxxxx0xxxxxxxxx00xxxxxxxxxxx", "0x00000007,0x00:ebx=xxxxxxxxxxxxxxxxxx00x0000x0x0x00" ]
あとは cpuid=[...]
内に出力された内容を、移行先のゲストの domU.cfg
の xl
設定内に貼り付けるか、もしくは libvirt
の XML 設定内に設定します。
あとは移行元のゲストを起動し直して、 CPU の機能を 一部無効化 した形で実行します。これにより、全てのホスト内に存在する CPU 機能だけを使用して動作させることができるようになります。
cpuid
に関する詳細については、 https://etallen.com/cpuid.html (英語) をお読みください。
CPU マスク計算プログラムの最新版をダウンロードしたい場合は、 https://github.com/twizted/xen_maskcalc をご覧ください。
VM ゲスト 側で必要となるブロックデバイスは、移行に関わる全ての VM ホストサーバ システムからアクセスできなければなりません。これは移行を行う VM ゲスト システムのルートファイルシステムを、共有型ストレージ内に配置することで実現することができます。一般的には下記のようなものがあります:
iSCSI
: 複数のシステムに対して、同時に同一のブロックデバイスにアクセスする機能を提供することができます。
NFS
: 複数のシステムから容易にアクセスすることのできるルートファイルシステムとして、幅広く使用されています。詳しくは 第22章 「NFS によるファイル共有」 をお読みください。
DRBD
: 2 台の VM ホストサーバ システム間でのみ使用することのできるシステムです。この仕組みを使用すると、ネットワークを介してデータが複製されることになりますので、データの保全性をさらに高めることができます。
SCSI
: ハードウエア側で共有が許可されていれば、同じディスクに対して複数のシステムがアクセスすることができます。
NPIV
: ファイバチャネルディスクを使用するための特殊なモードです。ただし、この場合は移行に関わる VM ホストサーバ が同じファイバチャネルのスイッチに接続されていなければなりません。 NPIV に関する詳細は、 27.1項 「物理ストレージから仮想ディスクへのマッピング」 をお読みください。一般的に、これは 4 Gbps もしくはそれ以上のファイバチャネル接続環境でのみ動作します。
VM ゲスト システムの実際の移行作業は、下記のコマンドで行います:
>
sudo
xl migrate <ドメイン名> <ホスト名>
移行の速度はメモリのディスクへの書き込み速度と、新しい VM ホストサーバ への送信速度、そして新しい VM ホストサーバ での読み込み速度によって決まります。つまり、メモリの少ない VM ゲスト のほうが、メモリの多い VM ゲスト よりも素早く移行できることになります。
多数の仮想化ゲストを定常的に管理している場合、動作している多数の VM ゲスト の正常性を監視する作業が欠かせません。 Xen では、システムに関する情報を収集するためのさまざまなシステムツールを提供しています。
VM ホストサーバ の基本的な監視 (I/O および CPU) については、 仮想マシンマネージャ 側で提供しています。詳しくは 10.7.1項 「仮想マシンマネージャ を利用した監視」 をお読みください。
xentop
を利用した Xen の管理 #Edit sourceXen 仮想化環境で情報を収集するために使用する端末アプリケーションとして、 xentop
が用意されています。ただし、このツールを使用するにはサイズの大きな (文字数の多い) 端末が必要となります。サイズの小さな端末を使用してしまうと、表示が改行されて読みにくくなってしまいます。
xentop
には監視の際の設定を変更するためのコマンドキーが用意されています。主なものは下記のとおりです:
画面の更新間隔を指定します。
ネットワークの統計情報も表示するようにします。なお、標準的な設定のみが表示されます。また、ルーティング型ネットワークのような特殊な設定にも対応していません。
接続されているブロックデバイスと、その累積しよう回数を表示します。
xentop
に関する詳細は、 man 1 xentop
で表示されるマニュアルページをお読みください。
virt-top
libvirt にはハイパーバイザに依存しない virt-top
というツールが提供されています。こちらも VM ゲスト の監視にはお勧めです。詳しくは 10.7.2項 「virt-top
を利用した監視」 をお読みください。
稼働中の openSUSE システムを監視したりデバッグしたりするためのシステムツールは数多く存在しています。それらのうちの多くは 第2章 「システム監視ユーティリティ」 で説明を行っています。ここでは特に、仮想化環境を監視するためのツールについて説明しています:
コマンドラインユーティリティである ip
コマンドは、任意のネットワークインターフェイスの監視を行うことができるコマンドです。このコマンドは、ルーティング型のネットワークやマスカレード型のネットワークを構成しているような場合、特に有用です。たとえば alice.0
という名前のネットワークインターフェイスを監視したい場合は、下記のコマンドを実行します:
>
watch ip -s link show alice.0
標準的な設定では、全ての Xen VM ゲスト は仮想ネットワークブリッジに接続されます。 bridge
コマンドを実行すると、 VM ゲスト システム内の仮想ネットワークアダプタが、どのブリッジに接続されているのかを知ることができます。この場合は、 bridge link
と入力して実行します。出力は下記のようになります:
2: eth0 state DOWN : <NO-CARRIER, ...,UP> mtu 1500 master br0 8: vnet0 state UNKNOWN : <BROADCAST, ...,LOWER_UP> mtu 1500 master virbr0 \ state forwarding priority 32 cost 100
上記の出力では、 2 種類の仮想ブリッジがシステム内に定義されています。一方は物理イーサネットデバイスである eth0
に、もう一方は VLAN インターフェイスである vnet0
に接続されています。
マスカレード型のネットワークを使用している場合や、イーサネットインターフェイスに対してファイアウオールの設定を行っている場合、現在のファイアウオールルールを確認しておく必要がある場合があります。
この場合、 iptables
コマンドを実行することで、さまざまなファイアウオール設定を一括で表示することができます。チェイン内の全てのルールを表示したい場合、もしくは全ての設定を出力したい場合は、 iptables-save
もしくは iptables -S
を実行してください。
標準的な Xen 環境では、 VM ゲスト システムに対しては、 VM ホストサーバ システムの一部の情報しか伝達されません。ゲスト側でさらに詳しい VM ホストサーバ の情報を提供する必要がある場合は、 vhostmd
を利用して、選択したゲストに情報提供を行ってください。お使いのシステムで vhostmd
を動作させるには、下記の手順を行います:
まずは VM ホストサーバ に vhostmd パッケージをインストールします。
設定内に metric
セクションを追加または削除するには、 /etc/vhostmd/vhostmd.conf
ファイルを編集します。ただし、既定値のままでもかまいません。
下記のコマンドを実行して、 vhostmd.conf
設定ファイルの書式が正しいことを確認します:
>
cd /etc/vhostmd>
xmllint --postvalid --noout vhostmd.conf
あとは sudo systemctl start vhostmd
を実行して、 vhostmd デーモンを開始します。
vhostmd をシステムの起動時に開始するように設定したい場合は、下記を実行します:
>
sudo
systemctl enable vhostmd
alice という名前の VM ゲスト に対して、 /dev/shm/vhostmd0
というイメージファイルを接続するため、下記のコマンドを実行します:
>
xl block-attach opensuse /dev/shm/vhostmd0,,xvdb,ro
VM ゲスト 側のシステムにログインします。
クライアント側のパッケージ vm-dump-metrics
をインストールします。
vm-dump-metrics
コマンドを実行します。結果をファイルに保存したい場合は、 -d <ファイル名>
オプションを追加してください。
vm-dump-metrics
の出力は XML 形式で行われます。また、出力される内容は /etc/vhostmd/metric.dtd
の DTD 定義に従って行われます。
さらに詳しい情報については、 man 8 vhostmd
で表示されるマニュアルページのほか、 VM ホストサーバ システム側にある /usr/share/doc/vhostmd/README
(英語) ファイルをお読みください。ゲスト側では、 man 1 vm-dump-metrics
のマニュアルページもお読みいただくことができます。