本章では高度な管理作業のほか、最先端の仮想化ソリューションを実装したいユーザ向けの設定オプションについて説明しています。ただし、本章で説明しているオプションや作業はいずれも善意で提供されているものであり、 Novell 社のサポート範囲内であることを示すものではありません。
仮想 CD リーダは、仮想マシンの作成時に追加することができるほか、既存の仮想マシンに対しても追加を行うことができます。また、仮想 CD リーダは物理 CD/DVD をベースにして動作させることができるほか、 ISO イメージをベースにすることもできます。なお、仮想 CD リーダは、準仮想化の場合と完全仮想化の場合で異なる動作になります。
準仮想化型の仮想マシンでは、仮想 CD リーダと仮想ディスクを足して最大で 100 個までの設定を行うことができます。準仮想化マシンでは、仮想 CD リーダは読み込み専用の仮想ディスクとして CD を表示します。仮想 CD リーダは、 CD のデータ書き込み用に使用することはできません。
準仮想化型のマシンで CD へのアクセスが終わったら、仮想マシンから仮想 CD リーダを削除しておくことをお勧めします。
準仮想化ゲストでは、 devtype=cdrom
というデバイス種類の設定を行うことができます。この設定を行うことで実際の CD リーダの動作を擬似するほか、メディアの交換にも対応するようになります。また、 CD リーダのトレイを開くためのイジェクトコマンドも使用できるようになります。
完全仮想化マシンの場合、仮想 CD リーダと仮想ディスクを足して最大で 4 個までの設定を行うことができます。完全仮想化マシンの仮想 CD リーダは、通常の (物理的な) CD リーダと全く同じ扱いをすることができます。
ホストコンピュータ側の物理 CD リーダ (例: /dev/cdrom
) にメディアを挿入すると、物理 CD リーダをベースにした仮想 CD リーダが設定されている全ての仮想マシンから、挿入したメディアを読み込むことができるようになります。なお、オペレーティングシステム側に自動マウントの機能があれば、 CD は自動的にファイルシステム内に現れるようになります。仮想 CD リーダは CD のデータ書き込み用に使用することはできません。読み込み専用デバイスとして設定されます。
仮想 CD リーダは、ホストコンピュータに接続された CD リーダをベースにすることができるほか、 ISO イメージファイルをベースにすることもできます。
仮想マシンが動作中であり、オペレーティングシステムの起動が完了していることを確認します。
まずは物理 CD リーダにメディアを挿入するか、もしくは必要な ISO イメージを Dom0 内に準備します。
VM ゲスト で新しく未使用のブロックデバイスを選択します。たとえば /dev/xvdb
などになります。
ゲストに割り当てるものが物理 CD リーダなのか ISO イメージなのかを選択します。
物理 CD リーダを使用する場合は、下記のコマンドを VM ゲスト に対して実行し、 CD リーダの割り当てを行います。下記の例は、ゲストの名前が alice である場合の例となります:
>
sudo
xl block-attach alice target=/dev/sr0,vdev=xvdb,access=ro
イメージファイルを割り当てる場合は、下記のコマンドを実行します:
>
sudo
xl block-attach alice target=/path/to/file.iso,vdev=xvdb,access=ro
これで /dev/xvdb
などのブロックデバイスを仮想マシンに追加することができました。
仮想マシンが Linux である場合は、下記のように実行します:
仮想マシン内で端末を開いて fdisk -l
を実行し、デバイスが正しく割り当てられていることを確認します。 ls /sys/block
を実行することでも、仮想マシンに存在するすべきのディスクを表示することができます。
CD は仮想マシン側で仮想ディスクとして認識されます。そのため、下記のようなデバイス名になります:
/dev/xvdb
下記のようなコマンドを入力して実行することで、物理メディアもしくは ISO イメージを読み込むことができます。
>
sudo
mount -o ro /dev/xvdb /mnt
上記を実行すると、 /mnt
というマウントポイントにマウントされます。
すると、指定したマウントポイントにアクセスすることで、 CD もしくは ISO イメージの内容にアクセスすることができるようになります。
仮想マシンが Windows である場合は、仮想マシンを再起動します。
マイコンピュータ
内に仮想 CD リーダが現れていることを確認します。
仮想マシンが動作中であり、オペレーティングシステムの起動が完了していることを確認します。
仮想 CD リーダがマウントされている場合は、まずは仮想マシン内でマウントを解除します。
ホスト側で xl block-list alice
のように入力して実行することで、ゲスト側のブロックデバイスの一覧を表示することができます。
ゲストから仮想デバイスを削除するには、 xl block-detach alice
ブロックデバイス_ID のように入力して実行します。これがうまくいかない場合は、 -f
オプションを指定して強制的な取り外しをお試しください。
メディアを取り出すには、物理的な取り出しボタンを押してください。
ラックマウント型のサーバなど、ビデオモニタやキーボード、マウスが接続されていないコンピュータは、しばしば ヘッドレス
環境と呼ばれ、これらを VM ホストサーバ とする場合は、リモート管理技術を設定しておく必要があります。
一般的なシステム設定としては、下記のようなものがあります:
GNOME などのグラフィカルデスクトップを仮想マシンホストにインストールしている場合、 VNC ビューアなどのリモートビューアを使用してログインすることができるほか、 tigervnc
や virt-viewer
などを使用することで、リモートのゲスト環境にログインすることもできます。
ssh
コマンドをリモートのコンピュータで実行することで、仮想マシンホストのシェルにログインして、テキストベースのコンソールを使用することができます。あとは xl
コマンドで仮想マシンの管理を行うことができるほか、 virt-install
コマンドで新しい仮想マシンを作成することもできます。
VNC ビューアを使用することで、動作中のゲストに対してグラフィカルな方法でアクセスすることができます。 Dom0 からアクセスする際に使用する (ローカルアクセスやオンボックスアクセスと呼びます) ことができるほか、リモートのコンピュータからアクセスする際にも使用することができます。
VM ゲスト のディスプレイを表示したい場合は、接続先は VM ホストサーバ の IP アドレスになります。仮想マシンが動作中の場合、ホスト側の VNC サーバがポート番号を割り当てて、 VNC ビューアからのアクセスを待ち受けます。割り当てられるポート番号は、仮想マシンの起動時における最小のポート番号になります。なお、ポート番号は仮想マシンの動作中にのみ有効であり、シャットダウンを行ってしまうと、ポート番号は他の仮想マシンに割り当てることができるよう、解放されます。
たとえば 1, 2, 4, 5 の各ポートが仮想マシン向けに割り当てられている場合、新しく起動する仮想マシンに対しては、 VNC サーバが 3 を割り当てることになります。同じ仮想マシンであっても、次回の起動時に 3 が使用中であった場合は、また別のポート番号を割り当てることになります。
リモートのコンピュータから VNC サーバに接続できるようにするには、ファイアウオール側で VM ゲスト の使用するポートをできる限り多く空けておく必要があります。 VNC では 5900 番以降を使用する仕組みであることから、たとえば 10 台の VM ゲスト を動作させるような場合、 TCP ポートの 5900 から 5910 までを空けておいてください。
VM ホストサーバ 内のローカルで仮想マシンの VNC ディスプレイにアクセスするには、下記のいずれかのコマンドを実行します:
vncviewer ::590#
vncviewer :#
ここで、 # には仮想マシンに割り当てられた VNC ポート番号を指定します。
VM ホストサーバ 以外のマシンから VM ゲスト にアクセスする場合は、下記の書式でコマンドを作成して実行します:
>
vncviewer 192.168.1.20::590#
上記は、 VM ホストサーバ のアドレスが 192.168.1.20 である場合の例となります。
VNC サーバの既定では、利用可能な最小のポート番号を自動的に割り当てる動作を行いますが、仮想マシンに対して固定の VNC ポート番号を割り当てることもできます。
特定の VM ゲスト が使用するポートを固定したい場合は、仮想マシンの xl 設定ファイルを編集して、下記のような箇所にある vnclisten
の値を必要に応じて変更してください。下記の例では 2 を指定していますが、これは 5900 のベース値が自動的に足されて、 5902 として扱われます:
vfb = [ 'vnc=1,vnclisten="localhost:2"' ]
ゲストドメインの xl 設定の編集に関する詳細は、 26.1項 「xl: Xen 管理ツール」 をお読みください。
動的に最も小さい VNC ポート番号を割り当てる仮想マシンが存在する場合は、それらとの重複を避けるため、大きめの値を設定しておいてください。
仮想マシンのディスプレイを仮想マシンホストのコンソール自身から行う場合 (ローカルアクセスやオンボックスアクセスと呼ばれます) 、 VNC ではなく SDL を使用することもできます。 VNC はネットワーク経由でデスクトップを表示するには高速なプロトコルですが、同じコンピュータ内でデスクトップにアクセスするだけであれば、 SDL のほうがより高速に処理することができます。
VNC ではなく SDL を既定値として使用する場合は、仮想マシンの xl 設定を下記のように変更してください。変更方法に関する詳細は 26.1項 「xl: Xen 管理ツール」 をお読みください。
vfb = [ 'sdl=1' ]
なお、 VNC ビューアからのアクセスとは異なり、 SDL のウインドウを閉じてしまうと、仮想マシンそのものも終了してしまうことに注意してください。
仮想マシンが起動すると、ホスト側では仮想マシンの設定内にある keymap
の内容に従って、仮想キーボードを作成します。 keymap
の設定が存在しない場合、仮想マシンは既定値である英語 (US) キーボードを作成します。
仮想マシンの現在のキーボード設定を確認するには、下記のコマンドを Dom0 で実行します:
>
xl list -l VM_名 | grep keymap
ゲストの仮想キーボードを設定するには、下記のような内容を設定します:
vfb = [ 'keymap="ja"' ]
対応するキーボードレイアウトの一覧を表示したい場合は、 man 5 xl.cfg
で表示されるマニュアルページ内にある、 Keymaps
セクションをご覧ください。
Xen 内では、 Dom0 や VM ゲスト が性能を確保する目的で、使用する CPU コア数やコア番号を指定することができます。 Dom0 の性能は、ディスクやネットワークのドライバがここで動作することから、システム全体に対して重要な設定となります。 I/O に負荷が集中するゲストの場合、 Dom0 の CPU サイクルを多く消費することになります。その一方、 VM ゲスト 側の性能についても、必要な処理を完了するためのリソースとなりますので、こちらも重要となります。
Dom0 に対して CPU リソースを占有できるようにすることで、 VM ゲスト 側から届く I/O 要求を Dom0 内で容易に処理できるようになることから、性能を向上させる結果になります。逆に Dom0 が CPU リソースを占有できないと、性能が落ちてしまうだけでなく、 VM ゲスト が正しく動作しない場合もあります。
CPU リソースの占有を設定するには、 3 つの手順が必要となります。まずは Xen の起動時のコマンドライン設定、次に Dom0 の VCPU 設定、そして最後に VM ゲスト に対する CPU 関連の設定になります。
まずは Xen の起動時のコマンドラインに対して、 dom0_max_vcpus=X
を追加します。具体的には、 /etc/default/grub
に下記の行を追加します:
GRUB_CMDLINE_XEN="dom0_max_vcpus=X"
/etc/default/grub
内に既に GRUB_CMDLINE_XEN
がある場合は、その行に dom0_max_vcpus=X
を追加してください。
なお、 X
には Dom0 が占有する VCPU 数を指定します。
あとは下記のコマンドを実行して、 GRUB 2 の設定ファイルを更新します:
>
sudo
grub2-mkconfig -o /boot/grub2/grub.cfg
コンピュータを再起動して、設定を反映させます。
次に Dom0 の VCPU のそれぞれに対して、物理プロセッサへのバインド (「ピン」 とも呼びます) を設定します。
>
sudo
xl vcpu-pin Domain-0 0 0 xl vcpu-pin Domain-0 1 1
最初の行は、 Dom0 の VCPU 番号 0 を物理プロセッサ番号 0 に割り当てる設定、次の行は Dom0 の VCPU 番号 1 を物理プロセッサ番号 1 に割り当てる設定です。
最後に、全ての VM ゲスト の設定を変更して、 Dom0 が使用する物理プロセッサを使用しないようにします。たとえば 8-CPU のシステムであれば、下記のような内容を全ての VM ゲスト の設定ファイル内に追加します:
cpus="2-8"
"\n \n"
仮想マシン側に対しても、特定の CPU リソースを占有するように設定する必要がある場合があります。既定では、仮想マシンは利用可能な CPU コアを全て使用します。なお、十分な数の物理プロセッサを占有させ、他の VM ゲスト に対して使用させないようにすることで、性能を改善することができます。たとえば 8 CPU コアのマシンに対して、仮想マシンがそのうちの 2 個を占有するような場合、下記のような設定になります:
vcpus=2 cpus="2,3"
上記の例では 2
個のプロセッサを VM ゲスト に専用に割り当てています。使用するコアは 3 番目と 4 番目 (設定ファイル上では 0 から数えるため、 2
と 3
になっています) です。さらに多くの物理プロセッサを割り当てる必要がある場合は、 cpus="2-8"
のような書式で指定してください。
「alice」 という名前のゲストに対して、 CPU の割り当てをホットプラグ形式で変更したい場合は、対応する Dom0 で下記のコマンドを実行してください:
>
sudo
xl vcpu-set alice 2>
sudo
xl vcpu-pin alice 0 2>
sudo
xl vcpu-pin alice 1 3
上記の例では、ゲストに対して 2 個の物理プロセッサを占有するよう設定しています。それぞれ VCPU 0 が物理プロセッサ 2 を、 VCPU 1 が物理プロセッサ 3 を使用します。あとは下記のようにすることで、割り当てを確認することができます:
>
sudo
xl vcpu-list alice Name ID VCPUs CPU State Time(s) CPU Affinity alice 4 0 2 -b- 1.9 2-3 alice 4 1 3 -b- 2.8 2-3
Xen 環境では、完全仮想化環境のドメインにのみ提供される機能が存在しています。これらは頻繁に使用するものではありませんが、環境によっては設定する必要があるかもしれません。
物理ハードウエアと同様に、 VM ゲスト を通常使用するものとは異なる起動デバイスを使用する必要が生じることがあります。完全仮想化型のマシンであれば、ドメインの xl 設定ファイル内に boot
パラメータを指定することで、起動に使用するデバイスを設定することができます:
boot = 起動デバイス
ここで、 起動デバイス には、 c
であればハードディスクを、 d
であれば CD-ROM を、 n
であればネットワーク (PXE) 起動を指定することになります。複数を指定した場合は、並んだ順に起動を試す動作になります。たとえば下記のようになります:
boot = dc
上記の例は、 CD-ROM からの起動を試し、それがうまくいかない場合はハードディスクから起動しようとする設定になります。
一方の VM ホストサーバ から他方の VM ホストサーバ に VM ゲスト を移行できるようにするには、両方の VM ホストサーバ システムのいずれでも使用できる CPU 機能のみを提供するように設定する必要があります。つまり、両方の VM ホストサーバ で実際に搭載されている CPU が異なる場合、 VM ゲスト の起動時に、共通しない機能を隠蔽しておく必要があることになります。これにより、ホストを跨いで VM ゲスト を移行できることになります。完全仮想化環境の場合、これは cpuid
を設定することで実現することができます。
現在搭載されている CPU の情報を取得するには、 /proc/cpuinfo
ファイルをご覧ください。ここには現在の CPU に関する重要な情報が全て記載されています。
CPU の再定義を行うには、まず CPU の製造元が提供する CPUID の定義を参照しておく必要があります。これらはそれぞれ下記の箇所で公開されています (いずれも英語です):
cpuid = "host,tm=0,sse3=0"
書式はカンマ区切りで キー=値 の形式で指定します。また、最初は必ず "host" と記述します。いくつかのキーには数値を指定しますが、残りのほとんどのキーには、機能ビットを操作するための 1 文字を記述します。 CPUID のキーについて、詳しくは man 5 xl.cfg
をお読みください。また、下記の値を指定することで、対応するビットの指定を変えることができます:
対応するビットを 1
に強制します
対応するビットを 0
に強制します
既定のポリシーの値を使用します
ホスト側の値をそのまま使用します
k
と同様ですが、移行後も値を保持するようにします
なお、ビットは右から左に表記し、かつ 0
から始めます。
Dom0 や VM ゲスト に提供する PCI-IRQ の数を増やす必要がある場合、 Xen カーネルのコマンドラインでそれを行うことができます。 extra_guest_irqs=
DOMU_IRGS,DOM0_IRGS の形式で指定してください。最初の値である DOMU_IRGS は、全ての VM ゲスト に対する値を、 2 つめの値である DOM0_IRGS (カンマ区切り) は、 Dom0 に対する値とになります。なお、 VM ゲスト の設定を変更しても、 Dom0 には何も影響しませんし、逆もまた然りです。たとえば Dom0 側のみを変更したい場合は下記のように指定します:
extra_guest_irqs=,512
Xen ハイパーバイザでは、全ての物理 CPU にまたがる形で個別に仮想 CPU のスケジュール処理を行います。各コアに複数のスレッドが搭載された新しい CPU の場合、複数の仮想 CPU が同一コア内の別スレッドとして動作することがありますので、これによって仮想 CPU の処理性能に影響がある場合があります。たとえば一方のスレッド内で動作する仮想 CPU が重い処理をしている場合、もう一方のスレッド内で動作する仮想 CPU の性能が大きく落ち込んでしまうことになります。また、これらの仮想 CPU が別々のゲストシステムを動作させている場合は、ゲストシステム側にも影響があることになります。この場合の性能劣化は状況によって大きく異なり、単純にゲストシステム側に割り当てられる処理時間が削減されるだけであることもありますし、最悪の場合は サイドチャネル攻撃 という結果をもたらすこともあります。
このような問題に対しては、 スケジューリング粒度 の設定を行うことをお勧めします。 Xen の起動パラメータとして下記のような値を設定してください:
sched-gran=粒度
粒度 の箇所には下記のいずれかを指定します:
Xen ハイパーバイザでの標準的なスケジュール設定です。 1 つの物理 CPU コア内で複数のゲストの仮想 CPU を動作させます。こちらが既定値になります。
1 つの物理 CPU コアに対して、常に 1 つの仮想 CPU のコア 1 つを割り当てます。同じ物理 CPU コア内で複数の仮想 CPU のコアを動作させることはありません。そのため、動作させるべき仮想 CPU が存在するような状況でも、いくつかの物理コアが待機状態に置かれることがあります。性能への影響は、ゲストシステム内で実際に動作させる処理内容によって異なります。なお、比較的負荷の高い状況下では、 1 つのコア内で 1 つの処理のみを動作させるハイパースレッディングの無効化 (詳しくは https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html#smt-x86 にある smt
オプションの説明をお読みください) より、性能劣化は穏やかになります。
さらに粒度を高めて、 CPU ソケット単位で処理を分けるようにします。