Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
コンテンツコンテンツ
仮想化ガイド
  1. 前書き
  2. I 概要
    1. 1 仮想化技術
    2. 2 仮想化シナリオ
    3. 3 Xen 仮想化の紹介
    4. 4 KVM 仮想化の紹介
    5. 5 仮想化ツール
    6. 6 仮想化コンポーネントのインストール
  3. II libvirt を利用した仮想マシンの管理
    1. 7 libvirt デーモン
    2. 8 VM ホストサーバ の準備
    3. 9 ゲストのインストール
    4. 10 基本的な VM ゲスト の管理
    5. 11 接続と認可
    6. 12 高度なストレージ設定
    7. 13 仮想マシンマネージャ を利用した仮想マシンの設定
    8. 14 virsh を利用した仮想マシンの設定
    9. 15 AMD SEV-SNP による仮想マシンのセキュリティ強化
    10. 16 VM ゲスト の移行
    11. 17 Xen から KVM への移行ガイド
  4. III 全ハイパーバイザ共通の機能
    1. 18 ディスクのキャッシュモード
    2. 19 VM ゲスト の時刻設定
    3. 20 libguestfs
    4. 21 QEMU ゲストエージェント
    5. 22 ソフトウエア TPM エミュレータ
    6. 23 VM ゲスト に対するクラッシュダンプの作成
  5. IV Xen を利用した仮想マシンの管理
    1. 24 仮想マシンホストの設定
    2. 25 仮想ネットワーク
    3. 26 仮想環境の管理
    4. 27 Xen 内でのブロックデバイス
    5. 28 仮想化: オプション設定
    6. 29 管理作業
    7. 30 XenStore: ドメイン間で共有される設定データベース
    8. 31 Xen の高可用性仮想化ホストとしての使用
    9. 32 Xen: 準仮想化 (PV) ゲストから完全仮想化 (FV/HVM) ゲストへの変換
  6. V QEMU を利用した仮想マシンの管理
    1. 33 QEMU の概要
    2. 34 KVM VM ホストサーバ の構築
    3. 35 ゲストのインストール
    4. 36 qemu-system-ARCH を利用した仮想マシンの実行
    5. 37 QEMU モニタを利用した仮想マシンの管理
  7. VI トラブルシューティング
    1. 38 内蔵ヘルプとパッケージのドキュメンテーション
    2. 39 システム情報とログの収集
  8. 用語集
  9. A NVIDIA カードに対する GPU パススルー の設定
  10. B GNU ライセンス
ナビゲーション
適用先 openSUSE Leap 15.7

29 管理作業 Edit source

29.1 ブートローダプログラム Edit source

ブートローダには仮想化ソフトウエアの起動と実行に関する制御が含まれています。 YaST を使用するか、もしくは直接設定ファイルを編集することで、ブートローダプログラムの設定を変更することができます。

YaST のブートローダプログラムは YaST › システム › ブートローダ にあります。 ブートローダのオプション タブを選択して、 Xen カーネルを含むものを 既定のブートセクション で選択してください。

ブートローダの設定
図 29.1: ブートローダの設定

設定が終わったら OK を押します。これでホストの次回の起動時に 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 を実行してください。

29.2 スパースイメージファイルとディスク領域 Edit source

ホスト側の物理ディスクの容量がいっぱいになり空き容量が無くなると、スパース (疎な) イメージファイルをベースとした仮想ディスクを使用している仮想マシンは、ディスクへの書き込みができなくなります。これにより、 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 のようなコマンドを入力して実行し、確認を行います。なお、デバイス名はお使いの環境に合わせて変更してください。

スパースファイル内にあるファイルシステム側の変更については、使用しているファイルシステムの種類によって異なりますので、対応するツールをお使いのうえ変更を行ってください。

29.3 Xen VM ゲスト システムの移行 Edit source

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 を使用することで、衝突を防ぐことができます。

29.3.1 CPU 機能の検出 Edit source

cpuid および xen_maskcalc.py のツールを使用することで、移行元と移行先の VM ゲスト に存在する CPU の機能を比較することができます。これらのコマンドを使用することで、ゲストの移行が正しく完了するかどうかを事前によりよく予測することができるようになります。

  1. 現在動作中の Dom0 と移行先の VM ゲスト 内で cpuid -1r を実行して出力を比較します。たとえば下記のようになります:

    tux@vm_host1 > sudo cpuid -1r > vm_host1.txt
    tux@vm_host2 > sudo cpuid -1r > vm_host2.txt
    tux@vm_host3 > sudo cpuid -1r > vm_host3.txt
  2. 出力されたテキストファイルを xen_maskcalc.py スクリプトがインストールされたホストに集めます。

  3. あとは出力された全てのテキストファイルに対して xen_maskcalc.py スクリプトを実行します:

    > sudo xen_maskcalc.py vm_host1.txt vm_host2.txt vm_host3.txt
    cpuid = [
        "0x00000001:ecx=x00xxxxxx0xxxxxxxxx00xxxxxxxxxxx",
        "0x00000007,0x00:ebx=xxxxxxxxxxxxxxxxxx00x0000x0x0x00"
    ]
  4. あとは cpuid=[...] 内に出力された内容を、移行先のゲストの domU.cfgxl 設定内に貼り付けるか、もしくは libvirt の XML 設定内に設定します。

  5. あとは移行元のゲストを起動し直して、 CPU の機能を 一部無効化 した形で実行します。これにより、全てのホスト内に存在する CPU 機能だけを使用して動作させることができるようになります。

29.3.1.1 さらなる情報 Edit source

cpuid に関する詳細については、 https://etallen.com/cpuid.html (英語) をお読みください。

CPU マスク計算プログラムの最新版をダウンロードしたい場合は、 https://github.com/twizted/xen_maskcalc をご覧ください。

29.3.2 移行のためのブロックデバイスの準備 Edit source

VM ゲスト 側で必要となるブロックデバイスは、移行に関わる全ての VM ホストサーバ システムからアクセスできなければなりません。これは移行を行う VM ゲスト システムのルートファイルシステムを、共有型ストレージ内に配置することで実現することができます。一般的には下記のようなものがあります:

  • iSCSI: 複数のシステムに対して、同時に同一のブロックデバイスにアクセスする機能を提供することができます。

  • NFS: 複数のシステムから容易にアクセスすることのできるルートファイルシステムとして、幅広く使用されています。詳しくは 第22章 「NFS によるファイル共有 をお読みください。

  • DRBD: 2 台の VM ホストサーバ システム間でのみ使用することのできるシステムです。この仕組みを使用すると、ネットワークを介してデータが複製されることになりますので、データの保全性をさらに高めることができます。

  • SCSI: ハードウエア側で共有が許可されていれば、同じディスクに対して複数のシステムがアクセスすることができます。

  • NPIV: ファイバチャネルディスクを使用するための特殊なモードです。ただし、この場合は移行に関わる VM ホストサーバ が同じファイバチャネルのスイッチに接続されていなければなりません。 NPIV に関する詳細は、 27.1項 「物理ストレージから仮想ディスクへのマッピング」 をお読みください。一般的に、これは 4 Gbps もしくはそれ以上のファイバチャネル接続環境でのみ動作します。

29.3.3 VM ゲスト システムの移行 Edit source

VM ゲスト システムの実際の移行作業は、下記のコマンドで行います:

> sudo xl migrate <ドメイン名> <ホスト名>

移行の速度はメモリのディスクへの書き込み速度と、新しい VM ホストサーバ への送信速度、そして新しい VM ホストサーバ での読み込み速度によって決まります。つまり、メモリの少ない VM ゲスト のほうが、メモリの多い VM ゲスト よりも素早く移行できることになります。

29.4 Xen の監視 Edit source

多数の仮想化ゲストを定常的に管理している場合、動作している多数の VM ゲスト の正常性を監視する作業が欠かせません。 Xen では、システムに関する情報を収集するためのさまざまなシステムツールを提供しています。

ヒント
ヒント: VM ホストサーバ の監視

VM ホストサーバ の基本的な監視 (I/O および CPU) については、 仮想マシンマネージャ 側で提供しています。詳しくは 10.7.1項 「仮想マシンマネージャ を利用した監視」 をお読みください。

29.4.1 xentop を利用した Xen の管理 Edit source

Xen 仮想化環境で情報を収集するために使用する端末アプリケーションとして、 xentop が用意されています。ただし、このツールを使用するにはサイズの大きな (文字数の多い) 端末が必要となります。サイズの小さな端末を使用してしまうと、表示が改行されて読みにくくなってしまいます。

xentop には監視の際の設定を変更するためのコマンドキーが用意されています。主なものは下記のとおりです:

D

画面の更新間隔を指定します。

N

ネットワークの統計情報も表示するようにします。なお、標準的な設定のみが表示されます。また、ルーティング型ネットワークのような特殊な設定にも対応していません。

B

接続されているブロックデバイスと、その累積しよう回数を表示します。

xentop に関する詳細は、 man 1 xentop で表示されるマニュアルページをお読みください。

ヒント
ヒント: virt-top

libvirt にはハイパーバイザに依存しない virt-top というツールが提供されています。こちらも VM ゲスト の監視にはお勧めです。詳しくは 10.7.2項 「virt-top を利用した監視」 をお読みください。

29.4.2 追加のツール Edit source

稼働中の openSUSE システムを監視したりデバッグしたりするためのシステムツールは数多く存在しています。それらのうちの多くは 第2章 「システム監視ユーティリティ で説明を行っています。ここでは特に、仮想化環境を監視するためのツールについて説明しています:

ip

コマンドラインユーティリティである ip コマンドは、任意のネットワークインターフェイスの監視を行うことができるコマンドです。このコマンドは、ルーティング型のネットワークやマスカレード型のネットワークを構成しているような場合、特に有用です。たとえば alice.0 という名前のネットワークインターフェイスを監視したい場合は、下記のコマンドを実行します:

> watch ip -s link show alice.0
bridge

標準的な設定では、全ての 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-save

マスカレード型のネットワークを使用している場合や、イーサネットインターフェイスに対してファイアウオールの設定を行っている場合、現在のファイアウオールルールを確認しておく必要がある場合があります。

この場合、 iptables コマンドを実行することで、さまざまなファイアウオール設定を一括で表示することができます。チェイン内の全てのルールを表示したい場合、もしくは全ての設定を出力したい場合は、 iptables-save もしくは iptables -S を実行してください。

29.5 VM ゲスト システムに対するホスト情報の提供 Edit source

標準的な Xen 環境では、 VM ゲスト システムに対しては、 VM ホストサーバ システムの一部の情報しか伝達されません。ゲスト側でさらに詳しい VM ホストサーバ の情報を提供する必要がある場合は、 vhostmd を利用して、選択したゲストに情報提供を行ってください。お使いのシステムで vhostmd を動作させるには、下記の手順を行います:

  1. まずは VM ホストサーバ に vhostmd パッケージをインストールします。

  2. 設定内に metric セクションを追加または削除するには、 /etc/vhostmd/vhostmd.conf ファイルを編集します。ただし、既定値のままでもかまいません。

  3. 下記のコマンドを実行して、 vhostmd.conf 設定ファイルの書式が正しいことを確認します:

    > cd /etc/vhostmd
    > xmllint --postvalid --noout vhostmd.conf
  4. あとは sudo systemctl start vhostmd を実行して、 vhostmd デーモンを開始します。

    vhostmd をシステムの起動時に開始するように設定したい場合は、下記を実行します:

    > sudo systemctl enable vhostmd
  5. alice という名前の VM ゲスト に対して、 /dev/shm/vhostmd0 というイメージファイルを接続するため、下記のコマンドを実行します:

    > xl block-attach opensuse /dev/shm/vhostmd0,,xvdb,ro
  6. VM ゲスト 側のシステムにログインします。

  7. クライアント側のパッケージ vm-dump-metrics をインストールします。

  8. 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 のマニュアルページもお読みいただくことができます。

このページを印刷