仮想化管理ガイド

Red Hat Enterprise Linux 6

仮想環境を管理する

Laura Novich

Red Hat Customer Content Services

Scott Radvan

Red Hat Customer Content Services

Dayle Parker

Red Hat Customer Content Services

概要

仮想化管理ガイドでは、ホスト物理マシン、ネットワーク構築、ストレージ、デバイスなどの管理、ゲスト仮想マシン管理、およびトラブルシューティングについて解説しています。

第1章 はじめに

1.1. Virtualization ドキュメントスイート

Red Hat では、様々な仮想化製品のドキュメントを豊富に提供しています。Red Hat Enterprise Linux および同梱製品のドキュメントには、以下のようなガイドが含まれます。
  • Red Hat Enterprise Linux 仮想化スタートガイド 』: 仮想化の概念、利点、ツールについて概説し、Red Hat の仮想化関連ドキュメントおよび製品の概要を記載しています。
  • Red Hat Enterprise Linux 仮想化ホスト設定およびゲストインストールガイド』: 仮想化ソフトウェアのインストールおよびホスト物理マシン上のゲスト仮想マシンの設定について記載しています。
  • Red Hat Enterprise Linux 仮想化管理ガイド』 (本書): virt-manager または virsh のいずれかを主要設定ツールとして使用した、ホスト物理マシン、ネットワーク、ストレージ、デバイスおよびゲスト仮想マシンの管理について説明します。このガイドには、libvirt および QEMU についての参考情報と、トラブルシューティング情報も記載しています。
  • Red Hat Enterprise Linux 仮想化セキュリティーガイド』: Red Hat が提供する仮想化セキュリティーテクノロジーについての概要を説明しています。また、仮想化環境内のホスト物理マシン、ゲスト仮想マシン、共有インフラストラクチャーおよびリソースのセキュリティーを保護するための推奨事項も記載しています。
  • Red Hat Enterprise Linux 仮想化のチューニングと最適化ガイド』: システムおよびゲスト仮想マシンで、仮想化パフォーマンスの機能とオプションを最大限に活用するためのヒント、コツおよびアドバイスを記載しています。
  • Red Hat Enterprise Linux V2V ガイド』: VM、Xen および VMware ESX/ESX(i) ハイパーバイザーから Red Hat Enterprise Virtualization および libvirt で管理されている KVM への仮想マシンのインポートについて記載しています。
Red Hat Enterprise Virtualization ドキュメントスイートは、Red Hat Enterprise Virtualization プラットフォームおよび関連製品のインストール、アプリケーション開発、設定および使用方法に関する情報を提供します。
  • Red Hat Enterprise Virtualization インストールガイド』: Red Hat Enterprise Virtualization 環境を準備し、セットアップする方法、および Red Hat Enterprise Virtualization 環境を最新リリースにアップグレードする方法について記載しています。さらに、ハイパーバイザーをセットアップする方法や、Red Hat Enterprise Virtualization 環境の初期設定を実行する方法についても概説しています。
  • Red Hat Enterprise Virtualization 管理ガイド』: Red Hat Enterprise Virtualization 環境を最初にセットアップした後に設定し、管理する方法について記載しています。これには、ハイパーバイザーやストレージドメイン、および外部プロバイダーを環境に追加する方法や、仮想マシン、仮想ディスクおよびテンプレートなどのリソースを管理する方法、およびバックアップを取る方法や復元する方法などが含まれます。
  • Red Hat Enterprise Virtualization ユーザーガイド』: 基本タブや拡張タブで提供される機能を含む Red Hat Enterprise Virtualization 環境のユーザーポータルの使い方、仮想マシンおよびテンプレートの作成および使用方法、さらにはリソース使用を監視する方法について記載しています。
  • Red Hat Enterprise Virtualization テクニカルガイド』: Red Hat Enterprise Virtualization に特有の REST API、Python、Java ソフトウェア開発キット、およびコマンドラインツールの使用方法について記載しています。さらに、Red Hat Enterprise Virtualization の背後にある基盤となる技術コンセプトについて概説しています。

注記

これらの製品についてのすべてのガイドは、Red Hat カスタマーポータル (https://access.redhat.com/documentation/en-US/) からご覧いただけます。

第2章 サーバーのベストプラクティス

Red Hat Enterprise Linux ホストのパフォーマンスを強化する場合に次のような作業やヒントが役に立ちます。その他のヒントについては、『Red Hat Enterprise Linux 仮想化のチューニングと最適化ガイド』 を参照してください。
  • enforcing モードで SELinux を実行します。 setenforce コマンドを使って enforcing モードで SELinux が実行するよう設定します。
    # setenforce 1
  • 不必要なサービスはすべて削除するか、または無効にします (AutoFSNFSFTPHTTPNIStelnetdsendmail など)。
  • サーバー上にはプラットフォームの管理に必要な最低限のユーザーアカウントのみを追加します。不必要なユーザーアカウントは削除してください。
  • ホストでは不必要なアプリケーションは実行しないようにしてください。ホストでアプリケーションを実行すると仮想マシンのパフォーマンスに影響を与えるため、サーバーの安定性に影響を与える可能性があります。サーバーをクラッシュさせる可能性のあるアプリケーションは、サーバー上のすべての仮想マシンをダウンさせてしまう原因ともなります。
  • 仮想マシンのインストールおよびイメージを集中管理できる場所を使用します。仮想マシンのイメージは /var/lib/libvirt/images/ に格納してください。仮想マシンのイメージをこれ以外のディレクトリーに格納する場合は、そのディレクトリーを SELinux ポリシーに追加し、インストールを開始する前にラベルの付け直しを必ず行ってください。集中管理のできる共有可能なネットワークストレージの使用を強くお勧めします。

第3章 仮想化のセキュリティー

仮想化の技術を導入する際には、ホスト物理マシンとそのオペレーティングシステムが攻撃されないようにする必要があります。この場合、ホスト とは、システム、デバイス、メモリー、ネットワークのほかにすべてのゲスト仮想マシンを管理する Red Hat Enterprise Linux システムのことです。ホスト物理マシンが保護されていないと、システム内のすべてのゲスト仮想マシンが脆弱になります。仮想化を使用してシステム上のセキュリティーを強化する方法にはいくつかの種類があります。担当者または担当者の企業は 導入計画 を作成する必要があります。この導入計画には、以下を含める必要があります。
  • 動作仕様
  • ご使用のゲスト仮想マシンで必要なサービスの指定
  • ホスト物理サーバーとこれらのサービスに必要なサポートの指定
以下は、導入計画の作成時に考慮すべきセキュリティー問題です。
  • ホスト物理マシン上では必要となるサービスのみを実行する。ホスト物理マシン上で実行されているプロセスやサービスが少ないほど、セキュリティーのレベルとパフォーマンスが高くなります。
  • ハイパーバイザー上で SELinux を有効にする。SELinux と仮想化の使用方法についての詳細は、「SELinux と仮想化」 を参照してください。その他のセキュリティーに関するヒントは、『Red Hat Enterprise Linux 仮想化セキュリティーガイド』 に記載されています。
  • ファイアーウォールを使用してホスト物理マシンへのトラフィックを制限する。攻撃からホストを保護するデフォルト拒否ルールでファイアウォールを設定できます。また、ネットワークを介するサービスを制限することも重要です。
  • 標準ユーザーのホストのオペレーティングシステムに対するアクセスを許可しない。ホストのオペレーティングシステムに特権が設定されている場合、特権のないアカウントにアクセスを許可すると、セキュリティーレベルが危険にさらされる可能性があります。

3.1. ストレージのセキュリティーに関する問題

ゲスト仮想マシンに対する管理者のセキュリティー権限を持つユーザーは誰でもホスト物理マシンのパーティションを変更できるため、このレベルのセキュリティー権限は実際のシステム管理者のみに付与することが不可欠になります。さらに、以下の点を考慮する必要があります。
  • ホスト物理マシンでは、fstab ファイル、initrd ファイル内でファイルシステムを識別するため、またはコマンドラインで使用するためのディスクラベルを使用することができません。権限の限られたユーザー、とりわけゲスト仮想マシンのユーザーがパーティション全域または LVM ボリュームへの書き込みアクセスを持つ場合、それらが誤って削除されたり、さらにはこの誤操作により同じストレージを使用している他のすべてのゲスト仮想マシンに影響が及ぶ可能性があります。
  • ゲスト仮想マシンのユーザーにはディスク全域またはブロックデバイス (例: /dev/sdb) への書き込みアクセスを付与すべきではありません。これを防ぐために /dev/sdb1 または LVM ボリュームなどのパーティションを使用します。

3.2. SELinux と仮想化

SELinux (Security Enhanced Linux) は、Linux のセキュリティーを強化するために Linux コミュニティーの支援の下に NSA (米国の国家安全保障局) によって開発されました。SELinux は攻撃者の能力を制限して、バッファーオーバーフローアタックや権限エスカレーションなど多くの一般的なセキュリティー上の弱点を防止するために機能します。これらの利点により、すべての Red Hat Enterprise Linux システムは SELinux を有効にした状態で強制モードで実行する必要があります。

手順3.1 SELinux を有効にしたゲスト仮想マシン上での論理ボリュームの作成とマウント

  1. 論理ボリュームを作成します。この例では、volumegroup というボリュームグループ上に NewVolumeName という 5 ギガバイトの論理ボリュームを作成します。また、この例はディスク領域が十分にあることを前提としています。ネットワークデバイス上で追加のストレージを作成し、そのストレージへのアクセスをゲストに付与する必要がある場合があります。詳細は、14章ボリューム を参照してください。
    # lvcreate -n NewVolumeName -L 5G volumegroup
  2. ext3 などの拡張属性に対応できるファイルシステムで NewVolumeName 論理ボリュームをフォーマットします。
    # mke2fs -j /dev/volumegroup/NewVolumeName
  3. 新しい論理ボリュームをマウントする新規のディレクトリーを作成します。このディレクトリーはファイルシステムのどこに配置しても構いません。ただし、重要なシステムディレクトリー (/etc/var/sys) またはホームディレクトリー (/home/root など) 内には配置しないようにしてください。この例では、/virtstorage というディレクトリーを使用しています。
    # mkdir /virtstorage
  4. 論理ボリュームをマウントします。
    # mount /dev/volumegroup/NewVolumeName /virtstorage
  5. 作成したばかりのフォルダーの SELinux タイプを設定します。
    # semanage fcontext -a -t virt_image_t "/virtstorage(/.*)?"
    targeted ポリシー (targeted はデフォルトのポリシー) を使用すると、コマンドにより次のような 1 行が /etc/selinux/targeted/contexts/files/file_contexts.local ファイルに追加されます。この行によって変更が永続化されます。
    /virtstorage(/.*)?    system_u:object_r:virt_image_t:s0
  6. 次のコマンドを実行して、マウントポイント (/virtstorage) とその下のすべてのファイルのタイプを virt_image_t に変更します (restorecon コマンドと setfiles コマンドは /etc/selinux/targeted/contexts/files/ 内のファイルを読み込みます)。
    # restorecon -R -v /virtstorage

注記

ファイルシステム上に新しいファイルを作成します (touch コマンドを使用)。
# touch /virtstorage/newfile
次のコマンドを使用してファイルのラベルが変更されていることを確認します。
# sudo ls -Z /virtstorage
-rw-------. root root system_u:object_r:virt_image_t:s0 newfile
上記の出力は、新しいファイルが正しい属性の virt_image_t を持っていることを示しています。

3.3. SELinux

このセクションには、仮想化の導入で SELinux を使用する際に考慮すべきトピックが含まれています。システムの変更を導入したり、デバイスを追加したりする場合には、SELinux ポリシーを随時更新する必要があります。ゲスト仮想マシン用に LVM ボリュームを設定するには、それぞれの基礎となるブロックデバイスとボリュームグループの SELinux コンテキストを修正する必要があります。policycoreutilis-python パッケージをインストールしていること (yum install policycoreutilis-python) を確認してから、次のコマンドを実行します。
# semanage fcontext -a -t virt_image_t -f -b /dev/sda2
# restorecon /dev/sda2
KVM と SELinux

以下の表は、libvirt で起動した場合に KVM に影響を与える SELinux ブール値を示しています。

KVM の SELinux ブール値
SELinux ブール値説明
virt_use_commvirt によるシリアルおよびパラレル通信ポートの使用を許可します。
virt_use_fusefsvirt による fuse ファイルの読み込みを許可します。
virt_use_nfsvirt による NFS ファイルの管理を許可します。
virt_use_sambavirt による CIFS ファイルの管理を許可します。
virt_use_sanlocksanlock による virt lib ファイルの管理を許可します。
virt_use_sysfsvirt によるデバイス設定 (PCI) の管理を許可します。
virt_use_xserver仮想マシンによる xserver との対話を許可します。
virt_use_usbvirt による USB デバイスの使用を許可します。

3.4. 仮想化のファイアウォール情報

ゲスト仮想マシンと対応する管理ユーティリティー間の通信のために様々なポートが使用されます。

注記

ゲスト仮想マシン上のネットワークサービスはいずれも、外部アクセスを可能にするためにゲスト仮想マシンに適用できるポートを開いておく必要があります。ゲスト仮想マシン上のネットワークサービスにファイアウォールが設定されている場合、これにアクセスすることはできません。常にゲスト仮想マシンのネットワーク設定を最初に確認してください。
  • ICMP 要求を許可する必要があります。ICMP パケットはネットワークテストに使用されます。ICMP パケットがブロックされていると、ゲスト仮想マシンに ping できません。
  • ポート 22 は、SSH アクセスおよび初期インストール用に開いておきます。
  • ポート 80 または 443 (RHEV Manager のセキュリティー設定によって異なる) が、ホスト物理マシンに関する情報を通信するために vdsm-reg サービスで使用されます。
  • ポート 5634 から 6166 までが SPICE プロトコルを使ったゲスト仮想マシンのコンソールアクセスに使用されます。
  • ポート 49152 から 49216 までが KVM を使用した移行に使用されます。同時に行なう移行の数に応じて、この範囲内のどのポートでも使用できます。
  • また、共有ブリッジおよびデフォルトのブリッジ用に IP 転送を有効 (net.ipv4.ip_forward = 1) にする必要があります。この変数は libvirt をインストールすると有効になるため、手動で無効にしない限り、仮想化パッケージをインストールすると有効になります。

注記

物理ブリッジデバイスには IP 転送を有効にする必要は ありません。ゲスト仮想マシンが物理ブリッジを介して接続されている場合には、トラフィックは IP 転送などの IP 設定を必要としないレベルでのみ機能します。

第4章 sVirt

sVirt は Red Hat Enterprise Linux 6 に導入されている技術のことで、SELinux と仮想化を統合します。sVirt はゲスト仮想マシンの使用時には Mandatory Access Control (MAC) を適用してセキュリティーを強化し、ハイパーバイザー内のバグに対してシステムを堅牢にします。これはホスト物理マシンや他のゲスト仮想マシン上の攻撃を防ぐのにとくに役立ちます。 
本章では、Red Hat Enterprise Linux 6 での sVirt による仮想化技術の統合について説明します。
非仮想化環境

非仮想化環境では、ホスト物理マシンは物理的に相互に分離しているため、各ホスト物理マシンは web サーバーや DNS サーバーなどのサービスで構成される自己完結型の環境を有しています。こうしたサービスは独自のユーザー空間や、ホスト物理マシンのカーネル、および物理ハードウェアと直接通信し、ネットワークにそれぞれのサービスを直接提供します。以下の図は、非仮想化環境を示しています。

14

ユーザー空間: すべてのユーザーモードのアプリケーションと一部のドライバーが実行されるメモリー領域です。

2

Web アプリケーション (web アプリケーションサーバー): ブラウザーでアクセスできる Web コンテンツを配信します。

36

ホストカーネル: ホスト物理マシンの特権カーネル、カーネル拡張およびほとんどのデバイスドライバーを実行する目的で厳密に確保されます。

5

DNS サーバー: DNS レコードを保存し、ユーザーが IP アドレスではなく論理名を使って Web ページにアクセスできるようにします。
仮想化環境

仮想化環境では、複数の仮想オペレーティングシステムを、ホスト物理マシン上にある単一のカーネル上で稼働させることができます。以下の図は、仮想化環境を示しています。

4.1. セキュリティーと仮想化

サービスを仮想化していない場合、マシンは物理的に分離されています。ネットワーク攻撃は別として、セキュリティー上の弱点は通常、攻撃を受けたマシンに内在します。複数のサービスを仮想化環境に集めると、追加の脆弱性がシステム内に発生します。ゲスト仮想マシンが不正利用する可能性のあるセキュリティー上の不具合がハイパーバイザーにある場合、このゲスト仮想マシンはホスト物理マシンだけでなく、そのホスト物理マシン上で実行している他のゲスト仮想マシンも攻撃できることになります。こうした攻撃は、ゲスト仮想マシンの範囲を超えて、他のゲスト仮想マシンを攻撃にさらす可能性もあります。
sVirt は、ゲスト仮想マシンを隔離して、不正利用されている場合に追加の攻撃を開始する能力を抑制するためのものです。以下の図が示すように、攻撃はゲスト仮想マシンの範囲を超えることはできず、他のゲスト仮想マシンに侵入することができません。
SELinux は、MAC (Mandatory Access Control) の実装内で仮想化インスタンス用のプラグ可能なセキュリティーフレームワークを導入します。sVirt のフレームワークにより、ゲスト仮想マシンとそのリソースに対する固有のラベル付けが可能になります。ラベルが付けられると、ルールの適用が可能になり、異なるゲスト間のアクセスを拒否できるようになります。

4.2. sVirt のラベル

SELinux の保護下にある他のサービスと同様に、sVirt はプロセスベースのメカニズムと制約を使用して、ゲスト仮想マシン全体に追加のセキュリティー層を提供します。通常の使用では、sVirt が背後で作動していることすら気づかないことでしょう。このセクションでは、sVirt のラベル付け機能について説明します。
以下の出力に示されるように、sVirt を使用すると、仮想化されるゲスト仮想マシンの各プロセスにラベル付けが行なわれ、動的に生成されるレベルで実行されるようになります。各プロセスは複数の異なるレベルにより、他の仮想マシンから分離されます。
# ps -eZ | grep qemu

system_u:system_r:svirt_t:s0:c87,c520 27950 ?  00:00:17 qemu-kvm
以下の出力で示されるように、実際のディスクイメージは、プロセスに一致するよう自動的にラベル付けされます。
# ls -lZ /var/lib/libvirt/images/*

  system_u:object_r:svirt_image_t:s0:c87,c520   image1
以下の表は、sVirt の使用時に割り当てられるさまざまなコンテキストラベルの概要を示しています。

表4.1 sVirt コンテキストラベル

SELinux コンテキストタイプ/説明
system_u:system_r:svirt_t:MCS1ゲスト仮想マシンのプロセスです。MCS1 はランダムな MCS フィールドです。約 50万種のラベルに対応しています。
system_u:object_r:svirt_image_t:MCS1ゲスト仮想マシンのイメージです。同じ MCS フィールドを持つ svirt_t プロセスのみがこれらのイメージの読み込みと書き込みを行なうことができます。
system_u:object_r:svirt_image_t:s0ゲスト仮想マシンの共有する読み込み/書き込みコンテンツです。すべての svirt_t プロセスは svirt_image_t:s0 ファイルに書き込みを行なうことができます。
sVirt を使用する際、静的なラベル付けを行なうこともできます。静的なラベルを使用すると、管理者はゲスト仮想マシンに、MCS/MLS フィールドを含む特殊なラベルを選択することができます。管理者が静的にラベル付けした、仮想化されたゲスト仮想マシンを実行する場合は、イメージファイルにも正しいラベルを設定してください。ゲスト仮想マシンは、常にそのラベルで起動することになるため、静的にラベル付けされた仮想化マシンのコンテンツの修正を sVirt システムが行なうことはありません。これにより、sVirt コンポーネントが MLS 環境で実行できるようになります。また、要件に応じて 1 つのシステム上で機密度のレベルの異なる複数のゲスト仮想マシンを実行することもできます。

第5章 KVM のライブマイグレーション

本章では、あるホスト物理マシンで実行中のゲスト仮想マシンを別のホスト物理マシンに移行する方法について説明します。どちらのインスタンスでも、ホスト物理マシンは KVM ハイパーバイザーを実行しています。
移行とは、ゲスト仮想マシンをあるホスト物理マシンから別のホスト物理マシンに移行するプロセスです。移行が可能である理由は、ゲスト仮想マシンはハードウェア上で直接実行されておらず、仮想化環境内で実行されているためです。移行は以下の点で有用となります。
  • 負荷分散: ホスト物理マシンに負荷がかかりすぎた場合に使用率の低いホスト物理マシンにゲスト仮想マシンを移動したり、別のホスト物理マシンの使用率が低くなっている場合にそちらにゲスト仮想マシンを移動して負荷分散をすることができます。
  • ハードウェアの非依存性: ホスト物理マシン上のハードウェアデバイスのアップグレード、追加または削除などを行う必要がある場合、ゲスト仮想マシン群を安全に別のホスト物理マシンに移動することができます。つまり、テスト仮想マシンはハードウェアを改善する際に生じ得るダウンタイムを経験することはありません。
  • 省エネ: ゲスト仮想マシンを別のホスト物理マシンに再配分し、電源をオフにして節電することで使用量の低い時間帯にコストを節約することができます。
  • 地理的な移行: ゲスト仮想マシンは、待ち時間を短縮するため、または重大な状況が発生した場合に別の場所に移動することができます。
ゲスト仮想マシンのメモリーと仮想化しているデバイスの状態を移行先ホスト物理マシンに送信することで移行が行なわれます。移行するゲスト仮想マシンのイメージは、ネットワーク接続されている共有ストレージに格納することをお勧めします。また、仮想マシンを移行する際の共有ストレージには libvirt 管理のストレージプールを使用することをお勧めします。
移行はライブまたはオフラインのいずれでも実行することができます。
ライブマイグレーションでは、ゲスト仮想マシンをソースのホスト物理マシン上で稼働させたままそのメモリーページを移行先ホスト物理マシンに順番に転送します。移行時に、KVM はすでに転送されたページに変更がないかソースを監視し、最初のページがすべて転送されるとこれらの検出した変更の転送を開始します。また、KVM は移行時の転送速度を推定できるため、データ残量の転送時間が一定の設定時間になると (デフォルトでは 10 ミリ秒)、オリジナルのゲスト仮想マシンを停止して残りのデータを転送し、移行先ホスト物理マシンでその同じゲスト仮想マシンを再開します。
ライブでは行なわない移行の場合には、ゲスト仮想マシンをいったん停止してからゲスト仮想マシンのメモリーイメージを移行先ホスト物理マシンに移行します。移行後に移行先ホスト物理マシンでゲスト仮想マシンを再開し、ソースのホスト物理マシンでゲスト仮想マシンが使用していたメモリーを解放します。この移行が完了するまでに要する時間はネットワークの帯域幅および待ち時間によって異なります。ネットワークが混雑している場合や帯域幅が狭い場合は、移行にかかる時間も長くなります。
オリジナルのゲスト仮想マシンが KVM が移行先ホスト物理マシンに移行するよりも速い速度でページを変更する場合、ライブマイグレーションがいつまでも完了しない状態になるため、オフライン移行を使用してください。

5.1. ライブマイグレーションの要件

ゲスト仮想マシンの移行には以下が必要になります。

移行の要件

  • 次のいずれかのプロトコルを使用してゲスト仮想マシンを共有ストレージにインストールする場合:
    • ファイバーチャンネルベースの LUN
    • iSCSI
    • FCoE
    • NFS
    • GFS2
    • SCSI RDMA プロトコル (SCSI RCP): Infiniband および 10GbE iWARP アダプターで使用されているブロックエクスポートプロトコル
  • 表5.1「ライブマイグレーションの互換性」の表で移行できるプラットフォームとバージョンを確認してください。また、Red Hat Enterprise Linux 6 は、共有ストレージ上で raw および qcow2 イメージを使用したゲスト仮想マシンのライブマイグレーションに対応していることに注意してください。
  • 両方のシステムで適切な TCP/IP ポートを開いておく必要があります。ファイアウォールが使用されている場合には、ポートの詳細について、「仮想化のファイアウォール情報」を参照してください。
  • 共有ストレージ媒体のエクスポートを行うシステムが別途必要になります。ストレージは、移行に使用する 2 つのホスト物理マシンのいずれにも存在させないようにしてください。
  • 共有ストレージは、ソースシステムと移行先システムの同じ場所にマウントします。マウントするディレクトリー名も同一にする必要があります。異なるパスでイメージを維持することは可能ですが、推奨されていません。virt-manager を使って移行を行なう予定の場合、パス名は同一である必要があります。ただし、virsh を使って移行を行なう予定の場合は、移行する際に --xml オプションや pre-hooks を使うと異なるネットワーク設定やマウントディレクトリーを使用することができます。共有ストレージがなくても、--copy-storage-all オプションを使って移行を完了することも可能です (非推奨)。prehooks についての詳細は、libvirt.org を参照してください。また、XML オプションについては、21章ドメイン XML の操作 をご覧ください。
  • 公共のブリッジタップネットワーク内の既存のゲスト仮想マシンで移行を行う場合、ソースのホスト物理マシンと移行先ホスト物理マシンは同じネットワーク内になければなりません。ネットワークが異なると、ゲスト仮想マシンのネットワークが移行後に機能しなくなります。
  • Red Hat Enterprise Linux 5 および 6 では、KVM ゲスト仮想マシンのデフォルトキャッシュモードは none に設定されおり、これがディスク状態の不整合を回避します。(たとえば、virsh attach-disk cache none を使って) キャッシュオプションを none に設定すると、仮想ゲストマシンのファイルすべてが (open システムコール呼び出しの際に) O_DIRECT フラグを使って開かれるようになり、ホスト物理マシンのキャッシュが迂回され、仮想ゲストマシンにのみキャッシュが提供されます。キャッシュモードを none に設定すると潜在的な不整合問題が回避され、仮想マシンのライブ移行が可能になります。キャッシュを none に設定することについての詳細情報は、「ゲストにストレージデバイスを追加する」 を参照してください。
libvirtd サービスが有効になっていること (# chkconfig libvirtd on)、またこのサービスを実行していること (# service libvirtd start) を確認します。移行を効率的に行なえるかどうかは /etc/libvirt/libvirtd.conf 設定ファイル内のパラメーターの設定によって決まる点にも十分に注意してください。

手順5.1 libvirtd.conf の設定

  1. libvirtd.conf を開くには、root で次のコマンドを実行する必要があります。
    # vim /etc/libvirt/libvirtd.conf
  2. 必要に応じてパラメーターを変更し、ファイルを保存します。
  3. libvirtd サービスを再起動します。
    # service libvirtd restart

5.2. ライブマイグレーションと Red Hat Enterprise Linux バージョンの互換性

サポートされているライブマイグレーションは、以下の 表5.1「ライブマイグレーションの互換性」 に示されています。

表5.1 ライブマイグレーションの互換性

移行の方法リリースタイプライブマイグレーションサポートの有無注記
上位メジャーリリース5.x → 6.yサポートなし
上位マイナーリリース5.x → 5.y (y>x, x>=4)完全サポート問題がある場合はご報告ください
上位マイナーリリース6.x → 6.y (y>x, x>=0)完全サポート問題がある場合はご報告ください
下位メジャーリリース6.x → 5.yサポートなし 
下位マイナーリリース5.x → 5.y (x>y,y>=4)サポートあり既知の問題については 移行に関するトラブルシューティングを参照してください
下位マイナーリリース6.x → 6.y (x>y, y>=0)サポートあり既知の問題については 移行に関するトラブルシューティングを参照してください

移行に関するトラブルシューティング

  • SPICE に関する問題 — 6.0 → 6.1 の移行を行う場合、SPICE に互換性のない変更点があることが判明しました。この場合、クライアントを切断してから接続し直すとオーディオとビデオの機能が一時的に失われます。これは一時的であり、すべてのサービスは再開されます。
  • USB に関する問題 — Red Hat Enterprise Linux 6.2 では、移行サポートを含む USB 機能を追加していますが、USB デバイスをリセットすると、そのデバイスで実行されていたすべてのアプリケーションは中断されてしまいました。この問題は Red Hat Enterprise Linux 6.4 で解決されており、今後のバージョンでは発生しないはずです。6.4 より前のバージョンでこの問題が生じることを防ぐには、USB デバイスを使用中に移行を行なわないようにしてください。
  • 移行プロトコルに関する問題 — 下位移行で「unknown section error」が出される場合、このエラーは一時的なエラーの可能性があるため移行プロセスを繰り返してみてください。これにより、問題が修復される可能性があります。解決できなかった場合には問題の報告してください。
ネットワークストレージの設定

共有ストレージを設定してその共有ストレージにゲスト仮想マシンをインストールします。

または、「共有ストレージの例: NFS を使用した単純な移行」にある NFS の例を使用します。

5.3. 共有ストレージの例: NFS を使用した単純な移行

重要

この例では、NFS を使ってゲスト仮想マシンのイメージを他の KVM ホスト物理マシンと共有します。これは大規模なインストールでは現実的な方法ではありませんが、ここでは移行手法を説明する目的で使用しています。移行や実行するゲスト仮想マシンが数台以上になる場合には、この例を適用しないでください。また、sync パラメーターが有効である必要があります。これは、NFS ストレージを適切にエクスポートするために必要です。また、NFS がソースのホスト物理マシンにマウントされていることが強く推奨されます。ゲスト仮想マシンのイメージは、ソースのホスト物理マシンに直接マウントされている NFS で作成される必要があります。NFS ファイルロックは KVM でサポートされていないので、使用しないでください。
大規模な導入には iSCSI ストレージを選択するのがよいでしょう。設定の詳細については、「iSCSI ベースのストレージプール」を参照してください。
また、このセクションの内容は 『Red Hat Linux ストレージ管理ガイド』 に記載されている詳細な説明の代わりとなるものではありません。NFS の設定方法や、IP テーブルの開き方、およびファイアウォールの設定方法などの詳細については、『Red Hat Linux ストレージ管理ガイド』 を参照してください。
  1. ディスクイメージ用ディレクトリーを作成する

    この共有 ディレクトリーには、ゲスト仮想マシン用のディスクイメージを格納します。このため、/var/lib/libvirt/images とは別の場所にディレクトリーを作成します。例を示します。
    # mkdir /var/lib/libvirt-img/images
  2. NFS 設定ファイルに新規ディレクトリーパスを追加する

    NFS 設定ファイルはテキストファイルで、/etc/exports に格納されています。このファイルを開き、上記ステップ 1 で作成したファイルへのパスを追加します。
    # echo "/var/lib/libvirt-img/images" >> /etc/exports/[NFS-Config-FILENAME.txt]
  3. NFS を起動する

    1. NFS のポートが iptables (2049 など) で開かれていることを確認します。また、NFS を /etc/hosts.allow ファイルに追加します。
    2. NFS サービスを起動します。
      # service nfs start
  4. ソースおよび移行先に共有ストレージをマウントする

    以下のコマンドをソースシステム上で 1 回、さらに移行先システム上でもう 1 回実行して、/var/lib/libvirt/images ディレクトリーを両方のシステムにマウントします。
    # mount source_host:/var/lib/libvirt-img/images /var/lib/libvirt/images

    警告

    この手順で作成されたディレクトリーが 「ライブマイグレーションの要件」 にある要件にしたがっていることを確認してください。また、ディレクトリーには適切な SELinux ラベルが付けられている必要がある場合があります。詳細情報は、Red Hat Enterprise Linux 6 ストレージ管理ガイド の NFS の章を参照してください。

5.4. virsh を使用した KVM のライブマイグレーション

ゲスト仮想マシンは virsh コマンドで別のホスト物理マシンに移行することができます。migrate コマンドは以下の形式のパラメーターを受け入れます。
# virsh migrate --live GuestName DestinationURL
ライブマイグレーションが不要な場合は、--live オプションは省略しても構いません。その他のオプションについては、「virsh migrate コマンドのオプション」をご覧ください。
GuestName パラメーターは移行するゲスト仮想マシンの名前を表します。
DestinationURL パラメーターは移行先ホスト物理マシンの接続 URL です。移行先システムでも Red Hat Enterprise Linux の同じバージョンを稼働していなければなりません。また、同じハイパーバイザーを使用し libvirt を実行しておく必要があります。

注記

通常の移行とピアツーピアの移行では、DestinationURL パラメーターの意味が異なります。
  • 通常の移行の場合: DestinationURL は、ソースのゲスト仮想マシンから見た移行先ホスト物理マシンの URL になります。
  • ピアツーピア移行の場合: DestinationURL は、ソースのホスト物理マシンから見た移行先ホスト物理マシンの URL になります。
コマンドを入力すると、移行先システムの root パスワードの入力が求められます。

重要

移行が正常に行なわれるには、移行先ホスト物理マシンのエントリーがソースサーバーの /etc/hosts 内になければなりません。以下の例のように、このファイル内に移行先ホスト物理マシンの IP アドレスとホスト名を入力します。移行先ホスト物理マシンの IP アドレスとホスト名をそれぞれ適切なものに置き換えてください。
10.0.0.20	host2.example.com
例: virsh を使用したライブマイグレーション

この例では host1.example.com から host2.example.com に移行を行っています。環境に適したホスト物理マシンの名前を使用してください。この例では guest1-rhel6-64 という名前の仮想マシンを移行しています。

この例では、共有ストレージが正しく設定されており、前提条件をすべて満たしていると仮定しています (移行の要件 を参照)。
  1. ゲスト仮想マシンが実行中であることを確認する

    ソースシステム host1.example.comguest1-rhel6-64 が実行中であることを確認します。
    [root@host1 ~]# virsh list
    Id Name                 State
    ----------------------------------
     10 guest1-rhel6-64     running
  2. ゲスト仮想マシンを移行する

    次のコマンドを実行してゲスト仮想マシンを移行先となる host2.example.com にライブマイグレーションします。移行先 URL の末尾に /system を追加し、libvirt にフルアクセスが必要であることを伝えます。
    # virsh migrate --live guest1-rhel6-64 qemu+ssh://host2.example.com/system
    コマンドを入力すると、移行先システムの root パスワードの入力が求められます。
  3. 待機する

    負荷やゲスト仮想マシンのサイズにより移行にかかる時間は異なります。virsh はエラーが発生した場合しか報告しません。ゲスト仮想マシンは、移行が完全に終了するまでソースのホストマシンで継続的に実行されます。
  4. ゲスト仮想マシンが移行先ホストに到達していることを確認する

    移行先システムの host2.example.comguest1-rhel6-64 が実行中であることを確認します。
    [root@host2 ~]# virsh list
    Id Name                 State
    ----------------------------------
     10 guest1-rhel6-64     running
これでライブマイグレーションが完了しました。

注記

libvirt では、TLS/SSL、UNIX ソケット、SSH、および暗号化されていない TCP などの各種のネットワーク方式に対応しています。他の方式を利用する方法についての詳細は、6章ゲストのリモート管理 を参照してください。

注記

稼働していないゲスト仮想マシンの移行は virsh migrate では行えません。稼働していないゲスト仮想マシンを移行するには、次のスクリプトを使用してください。
virsh dumpxml Guest1 > Guest1.xml
virsh -c qemu+ssh://<target-system-FQDN>  define Guest1.xml
virsh undefine Guest1

5.4.1. virsh を使用した移行に関するヒント

複数の移行を別々のコマンドシェルで実行する同時ライブマイグレーションが可能です。ただし、それぞれの移行インスタンスは (ソースと移行先) それぞれの MAX_CLIENT 値を使用するため、この移行は慎重に計算した上で行なわなければなりません。デフォルトの設定値は 20 なので、10 インスタンスまでは設定を変更せずに行なうことができます。設定値を変更する必要がある場合は、手順5.1「libvirtd.conf の設定」の手順を参照してください。
  1. 手順5.1「libvirtd.conf の設定」の手順に従って libvirtd.conf ファイルを 開きます。
  2. Processing controls セクションを見つけます。
    #################################################################
    #
    # Processing controls
    #
    
    # The maximum number of concurrent client connections to allow
    # over all sockets combined.
    #max_clients = 20
    
    
    # The minimum limit sets the number of workers to start up
    # initially. If the number of active clients exceeds this,
    # then more threads are spawned, upto max_workers limit.
    # Typically you'd want max_workers to equal maximum number
    # of clients allowed
    #min_workers = 5
    #max_workers = 20
    
    
    # The number of priority workers. If all workers from above
    # pool will stuck, some calls marked as high priority
    # (notably domainDestroy) can be executed in this pool.
    #prio_workers = 5
    
    # Total global limit on concurrent RPC calls. Should be
    # at least as large as max_workers. Beyond this, RPC requests
    # will be read into memory and queued. This directly impact
    # memory usage, currently each request requires 256 KB of
    # memory. So by default upto 5 MB of memory is used
    #
    # XXX this isn't actually enforced yet, only the per-client
    # limit is used so far
    #max_requests = 20
    
    # Limit on concurrent requests from a single client
    # connection. To avoid one client monopolizing the server
    # this should be a small fraction of the global max_requests
    # and max_workers parameter
    #max_client_requests = 5
    
    #################################################################
  3. max_clientsmax_workers のパラメーター設定値を変更します。この 2 つのパラメーターの数字を同一にしておくことを推奨しています。max_clients は移行ごとに 2 つのクライアントを使用し (ソース側と移行先に 1 つずつ)、max_workers は実行フェーズではソース側で 1 worker、移行先で 0 worker を使用し、終了フェーズでは移行先で 1 worker を使用します。

    重要

    max_clientsmax_workers のパラメーター設定値は、全ゲスト仮想マシンの libvirtd サービスへの接続により生じます。つまり、同じゲスト仮想マシンを使用し、同時に移行を行なっているユーザーはすべて max_clientsmax_workers パラメーターに設定された制限値に影響を受けます。このため、同時ライブマイグレーションを行なう際は、まず最大値を注意深く検討する必要があります。
  4. ファイルを保存してサービスを再起動します。

    注記

    移行中に接続が中断される場合がありますが、これは開始後に認証が行なわれていない SSH セッションが多すぎる場合に発生します。デフォルトでは、sshd で認証前の状態が許可されるのは 10 セッションのみです。この設定は sshd 設定ファイル (/etc/ssh/sshd_config) 内の MaxStartups パラメーターで制御されています。このパラメーターは調整する必要がある場合があります。DoS 攻撃 (リソースの過剰な消費) などを防ぐ目的でこの制限が設けられているため、このパラメーターを調整する際は注意が必要です。この値を高く設定しすぎると、当初の目的が意味がなくなってしまいます。パラメーターを変更する場合は、/etc/ssh/sshd_config を編集して MaxStartups 行の先頭にある # を削除し、 10 (デフォルト値) の値をさらに大きな数値に変更します。ファイルを保存して sshd サービスを再起動するのを忘れないようにしてください。詳細は、sshd_config の man ページを参照してください。

5.4.2. virsh migrate コマンドのオプション

--live のほかにも、virsh migrate コマンドは次のようなオプションを受け取ります。
  • --direct - ダイレクト移行に使用します。
  • --p2p - ピアツーピア移行に使用します。
  • --tunnelled - トンネル化する移行に使用します。
  • --persistent - ドメインを移動先ホスト物理マシンでもそのまま永続的な状態に維持します。
  • --undefinesource - ソースのホスト物理マシンのゲスト仮想マシンを削除します。
  • --suspend - ドメインを移動先ホスト物理マシンでもそのまま一時停止の状態に維持します。
  • --copy-storage-all (非推奨) - 共有しないストレージでディスクの完全コピーを行なう移行を示します。
  • --copy-storage-inc (非推奨) - 共有しないストレージで増分コピーを行なう移行を示します (ソースと移動先間で共有する同じベースイメージ)。いずれの場合も、ディスクのイメージは移動先ホスト物理マシン上になければなりません。--copy-storage-*. (非推奨) オプションは、libvirt に対し、ソースのホスト物理マシン上にあるイメージからのデータを移動先ホスト物理マシン上の同じ場所にあるイメージに転送するよう指示するだけです。詳細は、カスタマーポータル上の Does kvm support live migration with non-shared storage? を参照してください。
  • --change-protection - 移行の実行中に、互換性のない設定変更がドメインに対して行なわれないよう強制します。このフラグは、ハイパーバイザーでサポートされている場合に暗黙的に有効になります。ただし、ハイパーバイザーに変更保護のサポート機能がない場合には、これを明示的に使用して移行を拒否することができます。
  • --unsafe - 移行を強制的に実施し、安全のための手順はすべて無視します。
  • --verbose - 移行実施中の進捗状況を表示します。
  • [--abort-on-error] - ソフトエラー (I/O エラーなど) が移行プロセス中に発生する場合に移行をキャンセルします。
  • [--migrateuri] - 移行 URI、通常は省略されます。
  • [--domain <string>]- ドメイン名、id または uuid
  • [--desturi <string>] - クライアント(通常の移行)またはソース(P2P 移行)から見える移動先ホスト物理マシンの接続 URI
  • [--migrateuri] - 移行 URI(通常は省略可)
  • --timeout <seconds> - ライブマイグレーションカウンターが N 秒を超えるとゲスト仮想マシンを強制的に一時停止します。ライブマイグレーションでしか使用できません。タイムアウトが開始されると、一時停止しているゲスト仮想マシンで移行が続行されます。
  • dname - 移行中にドメイン名を新しい名前に変更する場合に使用します。このオプションも通常は省略できます。
  • [--dname] <string> - 移行中にゲスト仮想マシンの名前を新しい名前に変更します (サポートされる場合)
  • --xml - 基礎となるストレージにアクセスする際にソースと移動先間で異なる名前を構成するなど、ドメイン XML のホスト固有の部分に多数の変更を加える場合、指定するファイル名を使用して、移動先で使用する代替 XML ファイルを与えることができます。このオプションは通常は省略します。
詳細については virsh の man ページを参照してください。

5.5. virt-manager を使用した移行

このセクションでは、virt-manager を使ってあるホスト物理マシンから別のホスト物理マシンに KVM ゲスト仮想マシンを移行する方法について説明します。
  1. virt-manager を開く

    virt-manager を開きます。メインメニューバーで アプリケーションシステムツール仮想マシンマネージャー の順に選択し virt-manager を起動します。
    Virt-Manager のメインメニュー

    図5.1 Virt-Manager のメインメニュー

  2. 移動先のホスト物理マシンに接続する

    ファイル メニューをクリックし、次に 接続を追加 をクリックして移動先ホスト物理マシンに接続します。
    「接続を追加」のウィンドウを開く

    図5.2 「接続を追加」のウィンドウを開く

  3. 接続を追加する

    接続を追加 のウィンドウが表示されます。
    移動先のホスト物理マシンへの接続を追加する

    図5.3 移動先のホスト物理マシンへの接続を追加する

    以下のような詳細を入力します。
    • ハイパーバイザー: QEMU/KVM を選択します。
    • メソッド: 接続方式を選択します。
    • ユーザー名: リモートのホスト物理マシンのユーザー名を入力します。
    • ホスト名: リモートのホスト物理マシンのホスト名を入力します。
    接続 ボタンをクリックします。この例では SSH 接続を使用しているため、次のステップで指定ユーザーのパスワードを入力する必要があります。
    パスワードの入力

    図5.4 パスワードの入力

  4. ゲスト仮想マシンを移行する

    ソースのホスト物理マシン内にあるゲストの一覧を開き (ホスト名の左側にある小さい三角をクリックし)、移行するゲスト (この例では guest1-rhel6-64) を右クリックしてから マイグレーション をクリックします。
    移行するゲストの選択

    図5.5 移行するゲストの選択

    新しいホスト フィールドのドロップダウンリストを使い、ゲスト仮想マシンの移行先とするホスト物理マシンを選択し、マイグレーション をクリックします。
    移行先ホスト物理マシンの選択と移行プロセスの開始

    図5.6 移行先ホスト物理マシンの選択と移行プロセスの開始

    進捗ウィンドウが表示されます。
    進捗ウィンドウ

    図5.7 進捗ウィンドウ

    virt-manager には、移行先ホストで実行されている新たに移行したゲスト仮想マシンが表示されるようになります。ソースのホスト物理マシンで実行されていたゲスト仮想マシンは「停止中」の状態で表示されます。
    移行先ホスト物理マシンで実行される移行済みゲスト仮想マシン

    図5.8 移行先ホスト物理マシンで実行される移行済みゲスト仮想マシン

  5. オプション - ホスト物理マシンのストレージの詳細を表示する

    編集 メニューの 接続の詳細 をクリックすると、接続の詳細ウィンドウが表示されます。
    ストレージ タブをクリックします。移行先ホスト物理マシンの iSCSI ターゲットの詳細が表示されます。移行済みゲスト仮想マシンがストレージを使用しているマシンとして一覧表示されることに注意してください。
    ストレージの詳細

    図5.9 ストレージの詳細

    このホストは以下の XML 設定で定義されていました。
    
    <pool type='iscsi'>
        <name>iscsirhel6guest</name>
        <source>                            
            <host name='virtlab22.example.com.'/>
            <device path='iqn.2001-05.com.iscsivendor:0-8a0906-fbab74a06-a700000017a4cc89-rhevh'/>                           
        </source>                   
        <target>
            <path>/dev/disk/by-path</path>
        </target>
    </pool>
      ...
    

    図5.10 移行先ホスト物理マシンの XML 設定

第6章 ゲストのリモート管理

このセクションでは、 ssh または TLS と SSL を使用してゲストをリモートで管理する方法を説明します。SSH についての詳細は、『Red Hat Enterprise Linux 導入ガイド』 をご覧ください。

6.1. SSH によるリモート管理

ssh パッケージは、リモートの仮想化サーバーに安全に管理機能を送信できる暗号化されたネットワークプロトコルを提供します。ここで説明される方法では、SSH 接続を介して安全にトンネル化した libvirt 管理用接続を使ってリモートのマシン群を管理します。認証はすべてローカルの SSH エージェントで収集したパスフレーズまたはパスワード、および SSH パブリックキーの暗号を使って行われます。さらに、各ゲストの VNC コンソールも SSH 経由でトンネル化されます。
SSH を使って仮想マシンをリモートで管理する場合は、以下の点に注意してください。
  • 仮想マシンの管理を行う場合、リモートのマシンには root でログインしてアクセスする必要があります。
  • 初期接続のセットアップには時間がかかる場合があります。
  • すべてのホストまたはゲスト上でユーザーのキーを無効にする場合の標準的な方法や普通の方法というものはありません。
  • リモートマシンの台数が多くなると、SSH ではスケーラビリティーが低下します。

注記

Red Hat Enterprise Virtualization を利用すると多数の仮想マシン群のリモート管理が可能になります。詳細は、Red Hat Enterprise Virtualization のドキュメントを参照してください。
SSH アクセスには以下のパッケージが必要になります。
  • openssh
  • openssh-askpass
  • openssh-clients
  • openssh-server
virt-managerSSH アクセスを設定する - パスワードなしの場合とパスワードを必要とする場合

次の手順では、まだ SSH キーのセットアップを行なっていないゼロの状態から開始することを想定しています。SSH キーのセットアップや他のシステムへのキーのコピーがすでに完了している場合は、この手順は省略して構いません。

重要

SSH キーはユーザー固有となるため所有者以外は使用できません。キーの所有者はそのキーを生成した人になります。キーの共有はできません。
リモートホストへの接続を行う場合、そのキーを所有しているユーザーが virt-manager を実行しなければなりません。つまり、リモートのシステムが root 以外のユーザーによって管理されている場合、virt-manager は特権のないモードで実行されなければなりません。リモートのシステムがローカルの root ユーザーによって管理されている場合は、root ユーザーに SSH キーを作成させて所有させる必要があります。
ローカルホストは、特権を持たないユーザーで virt-manager を使って管理することはできません。
  1. オプション: ユーザーの切り替え

    必要に応じてユーザーの切り替えを行います。ここでは、他のホストおよびローカルホストをリモートで管理するためにローカルの root ユーザーを使用します。
    $ su -
  2. SSH キーペアの生成

    virt-manager を使用するマシン上でパブリックキーを生成します。ここではキーの格納先にデフォルトの ~/.ssh/ ディレクトリーを使用します。
    # ssh-keygen -t rsa
  3. キーをリモートのホスト群にコピー

    パスワードがないリモートログインまたはパスフレーズがあるリモートログインには、管理を行うシステムに SSH キーを配信しておく必要があります。ssh-copy-id コマンドを使って、指定されたシステムアドレス (この例では root@host2.example.com) の root ユーザーにキーをコピーします。
    # ssh-copy-id -i ~/.ssh/id_rsa.pub root@host2.example.com
    root@host2.example.com's password:
    ここで、ssh root@host2.example.com コマンドを使ってマシンにログインしてみます。.ssh/authorized_keys ファイルに予期しないキーが追加されていないことを確認します。
    必要に応じて、他のシステムにも同じ手順を繰り返します。
  4. オプション: パスフレーズを ssh-agent に追加

    既存の ssh-agent にパスフレーズを追加する方法を以下に示します。この作業は ssh-agent を実行していないと失敗します。エラーや競合を避けるため、SSH パラメーターが正しく設定されていることを確認してください。詳細は、『Red Hat Enterprise Linux 導入ガイド』 を参照してください。
    必要に応じて、SSH キーのパスフレーズを ssh-agent に追加します。ローカルのホストで次のコマンドを使い、パスフレーズを追加して (ある場合) パスワード入力をしないログインを有効にします。
    # ssh-add ~/.ssh/id_rsa
    SSH キーがリモートのシステムに追加されます。
libvirt デーモン (libvirtd)

libvirt デーモンは仮想マシンの管理用のインターフェースを提供します。libvirtd デーモンをインストールし、管理を必要とするすべてのリモートホストで実行しておく必要があります。

$ ssh root@somehost
# chkconfig libvirtd on
# service libvirtd start
libvirtdSSH の設定が完了したら、仮想マシンへのリモートアクセスおよびリモート管理が可能になるはずです。また、この時点で VNC を使ったゲストへのアクセスも可能になるはずです。
virt-manager でリモートホスト群にアクセスする

リモートホスト群は virt-manager GUI ツールで管理することができます。パスワード入力をしないログインを行うには、virt-manager を実行するユーザーが SSH キーを所有していなければなりません。

  1. virt-manager を起動します。
  2. ファイル->接続を追加 の順に開きます。
    接続を追加のメニュー

    図6.1 接続を追加のメニュー

  3. ドロップダウンメニューを使ってハイパーバイザーのタイプを選択し、リモートホストに接続 のチェックボックスをクリックして接続の メソッド (この例では SSH 経由のリモートトンネル) を開き、ユーザー名ホスト名 を入力します。次に 接続 をクリックします。

6.2. TLS と SSL 経由のリモート管理

TLS と SSL を使って仮想マシンを管理することができます。TLS と SSL によりスケーラビリティーが向上しますが、SSH を使用する場合より複雑になります (「SSH によるリモート管理」を参照)。TLS と SSL は安全な接続を確保するために Web ブラウザーで使用される同一のテクノロジーです。libvirt 管理接続は、着信接続用の TCP ポートを開きます。この接続には安全な暗号化が行なわれ、x509 証明書に基づいて認証されます。TLS と SSL での管理に必要な認証用証明書を作成し、実装する方法を以下に示します。

手順6.1 TLS 管理の認証局 (CA) キーを作成する

  1. まず最初に certtool ユーティリティーがインストールされていることを確認します。インストールされていない場合は、以下を実行します。
    # yum install gnutls-utils
  2. 次のコマンドを使ってプライベートキーを生成します。
    # certtool --generate-privkey > cakey.pem
  3. キーを生成したら、次にキーに自己署名できるよう署名ファイルを作成します。署名の詳細を含むファイルを作成して、ca.info という名前を付けます。このファイルには次の行を含めてください。
    # vim ca.info
    cn = Name of your organization
    ca
    cert_signing_key
  4. 自己署名キーを次のコマンドで生成します。
    # certtool --generate-self-signed --load-privkey cakey.pem --template ca.info --outfile cacert.pem
    ファイルを生成し終わったら、rm コマンドで ca.info ファイルは削除して構いません。生成プロセスで作成されたファイルには cacert.pem という名前が付けられます。このファイルがパブリックキー (証明書) になります。ロードしたファイル cakey.pem がプライベートキーです。このファイルは共有スペースには保管しないようにし、このキーは機密扱いにしてください。
  5. cacert.pem 認証局証明書ファイルをすべてのクライアントおよびサーバーの /etc/pki/CA/cacert.pem ディレクトリーにインストールし、この認証局で発行した証明書は信頼できる証明書であることを通知します。このファイルの内容を表示させる場合は、次のコマンドを実行します。
    # certtool -i --infile cacert.pem
    認証局の設定は以上です。認証局のプライベートキーは安全な場所に保管してください。クライアントやサーバーの証明書を発行する際に必要となります。

手順6.2 サーバーの証明書を発行する

以下の手順は、X.509 CommonName (CN) フィールドをサーバーのホスト名に設定して証明書を発行する方法を示しています。CN は、クライアントがサーバーに接続する際に使用するホスト名と一致しなければなりません。この例では、クライアントは qemu://mycommonname/system という URI を使用してサーバーに接続するので、CN フィールドも同様に mycommonname にします。
  1. サーバーのプライベートキーを作成します。
    # certtool --generate-privkey > serverkey.pem
  2. まず server.info という名前のテンプレートファイルを作成して認証局のプライベートキー用の署名を生成します。CN にはサーバーのホスト名と同じ名前を必ず設定してください。
    organization = Name of your organization
    cn = mycommonname
    tls_www_server
    encryption_key
    signing_key
  3. 次のコマンドで証明書を作成します。
    # certtool --generate-certificate --load-privkey serverkey.pem --load-ca-certificate cacert.pem --load-ca-privkey cakey.pem \ --template server.info --outfile servercert.pem
  4. 次の 2 種類のファイルが生成されます。
    • serverkey.pem - サーバーのプライベートキー
    • servercert.pem - サーバーのパブリックキー
    プライベートキーを保存する場所は機密扱いにしてください。ファイルの内容を表示するには、次のコマンドを実行します。
    # certtool -i --inifile servercert.pem
    このファイルを開いた場合、CN= パラメーターが前の手順で設定した CN と同じであることを確認してください。この例の場合は mycommonname になります。
  5. この 2 つのファイルを次の場所にインストールします。
    • serverkey.pem - サーバーのプライベートキーです。このファイルは「/etc/pki/libvirt/private/serverkey.pem」に配置します。
    • servercert.pem - サーバーの証明書です。このファイルはサーバーの「 /etc/pki/libvirt/servercert.pem」に配置します。

手順6.3 クライアントの証明書を発行する

  1. すべてのクライアント (virt-manager など libvirt でリンクしているすべてのプログラム) について、適切な名前に設定された X.509 Distinguished Name (DN) で証明書を発行する必要があります。これについては企業レベルで検討する必要があります。
    たとえば、次のような情報を使用します。
    C=USA,ST=North Carolina,L=Raleigh,O=Red Hat,CN=name_of_client
    この手順は 手順6.2「サーバーの証明書を発行する」とよく似ていますが、次の点が異なります。
  2. プライベートキーを次のコマンドで作成します。
    # certtool --generate-privkey > clientkey.pem
  3. まず最初に client.info という名前のテンプレートファイルを作成して、認証局のプライベートキーの署名を生成します。ファイルには次の行が含めます (地域や場所に応じてフィールドをカスタマイズしてください)。
    country = USA
    state = North Carolina
    locality = Raleigh
    organization = Red Hat
    cn = client1
    tls_www_client
    encryption_key
    signing_key
  4. 次のコマンドで証明書に署名します。
    # certtool --generate-certificate --load-privkey clientkey.pem --load-ca-certificate cacert.pem \ --load-ca-privkey cakey.pem --template client.info --outfile clientcert.pem
  5. 証明書をクライアントマシンにインストールします。
    # cp clientkey.pem /etc/pki/libvirt/private/clientkey.pem
    # cp clientcert.pem /etc/pki/libvirt/clientcert.pem

6.3. トランスポートモード

リモート管理用に、libvirt では次のようなトランスポートモードに対応しています。
Transport Layer Security (TLS)

Transport Layer Security TLS 1.0 (SSL 3.1) で認証され、暗号化される TCP/IP ソケットは、通常パブリックポート番号でリッスンします。これを使用するには、クライアントとサーバーの証明書を生成する必要があります。標準のポートは 16514 です。

UNIX ソケット

UNIX ドメインソケットはローカルマシン上でのみアクセス可能となります。ソケットは暗号化されず、認証には SELinux または UNIX のパーミッションを使用します。標準のソケット名は /var/run/libvirt/libvirt-sock/var/run/libvirt/libvirt-sock-ro (読み取り専用接続) です。

SSH

Secure Shell protocol (SSH) 接続経由でトランスポートされます。Netcat (nc パッケージ) をインストールしておく必要があります。libvirt デーモン (libvirtd) がリモートマシン上で実行されている必要があります。SSH アクセス用にポート 22 を開けておく必要があります。いずれかの SSH キー管理 (ssh-agent など) を使用しないとパスワードの入力が求められます。

ext

ext パラメーターは、libvirt の対象範囲外となる手段でリモートマシンに接続を行う外部プログラムに使用されます。このパラメーターはサポートされていません。

TCP

暗号化されていない TCP/IP ソケットです。実稼働での使用には推奨されません。通常は無効になっていますが、テストを行う場合や信頼できるネットワークで使用する場合などには管理者によって有効にされることがあります。デフォルトのポートは 16509 です。

他に指定がない場合、デフォルトのトランスポートモードは TLS です。
リモート URI

URI (Uniform Resource Identifier) は、リモートホストに接続するために virshlibvirt によって使用されます。また URI は virsh コマンドに --connect パラメータを付けて使用すると、リモートホストで単一コマンドや移行を実行することができます。リモート URI は一般的なローカル URI を取り、ホスト名またはトランスポート名を追加して形成されます。特殊なケースとして、「リモート」の URI スキームを使用すると、リモート libvirtd サーバーは最適なハイパーバイザードライバーを探索するように指示されます。これはローカル接続用に NULL URI を渡すのと同等です。

libvirt URI は汎用の形式を取ります (角括弧 [] 内の内容はオプションの関数を表します)。
driver[+transport]://[username@][hostname][:port]/path[?extraparameters]
ハイパーバイザー (ドライバー) が QEMU の場合、パスは必須になります。XEN の場合、パスはオプションになります。
以下は有効なリモート URI のいくつかの例です。
  • qemu://hostname/
  • xen://hostname/
  • xen+ssh://hostname/
外部の場所を対象とする場合は、トランスポートメソッドまたはホスト名を指定する必要があります。詳細は、http://libvirt.org/guide/html/Application_Development_Guide-Architecture-Remote_URIs.html を参照してください。

リモート管理の例

  • host2 という名前のリモート KVM ホストに接続します。SSH トランスポートを使用し、SSH ユーザー名は virtuser です。connect コマンドは connect [<name>] [--readonly] です。ここでの <name> は、説明されている有効な URI になります。virsh connect コマンドについての詳細は、「connect」 を参照してください。
    qemu+ssh://virtuser@hot2/
  • ホスト上にある host2 という名前のリモート KVM ハイパーバイザーに接続します。TLS を使用します。
    qemu://host2/

テスト事例

  • ローカルの KVM ハイパーバイザーに非標準の UNIX ソケットで接続します。この例では、UNIX ソケットへの完全パスが明示的に指定されています。
    qemu+unix:///system?socket=/opt/libvirt/run/libvirt/libvirt-sock
  • 暗号化していない TCP/IP 接続で libvirt デーモンに接続します。IP アドレスが 10.1.1.10 でポートが 5000 のサーバーへの接続です。この例ではデフォルト設定で test ドライバーが使用されています。
    test+tcp://10.1.1.10:5000/default
追加の URI パラメーター

追加パラメーターをリモート URI に追加することができます。以下の表に認識されているパラメーターを示します (表6.1「追加の URI パラメーター」)。これ以外のパラメーターはすべて無視されます。パラメーターの値は URI エスケープにしなければならない点に注意してください (つまり、疑問符 (?) をパラメーターの前に付けると、特殊文字が URI 形式に変換されます)。

表6.1 追加の URI パラメーター

名前トランスポートモード詳細使用事例
nameすべてのモードname がリモートの virConnectOpen 関数に渡されます。name は通常、リモート URI からトランスポート、ホスト名、ポート番号、ユーザー名および追加パラメーターを取り除いたものになります。ただし、非常に複雑なケースでは、name を明示的に指定する方がよい場合があります。name=qemu:///system
commandssh と ext外部コマンドです。ext トランスポートの場合に必要です。ssh の場合、デフォルトは ssh です。command の PATH が検索されます。command=/opt/openssh/bin/ssh
socketunix と sshUNIX ドメインソケットへのパスで、デフォルトを上書きします。ssh トランスポートの場合、これがリモートの netcat コマンドに渡されます (netcat を参照)。socket=/opt/libvirt/run/libvirt/libvirt-sock
netcatssh
リモートシステムに接続する場合に netcat コマンドを使用することができます。デフォルトの netcat パラメーターは nc コマンドを使用します。SSH トランスポートの場合、libvirt により以下の形式で SSH コマンドが構成されます。
command -p port [-l username] hostname
netcat -U socket
portusername、および hostname の各パラメーターをリモート URI の一部として指定できます。commandnetcat、および socket は他の追加パラメーターから取られたものです。
netcat=/opt/netcat/bin/nc
no_verifytlsゼロ以外の値に設定すると、クライアント側のサーバー証明書のチェックが無効になります。サーバー側のクライアント証明書のチェックまたは IP アドレスのチェックを無効にする場合は、libvirtd 設定を変更する必要があります。no_verify=1
no_ttysshゼロ以外の値に設定すると、リモートマシンに自動的にログインできない場合に SSH がパスワードの入力を求めてこないようにします。ターミナルにアクセスできない場合にこれを使用します。no_tty=1

第7章 KVM でのオーバーコミット

7.1. はじめに

KVM ハイパーバイザーは、CPU およびメモリーのオーバーコミットに対応しています。システム上に実際に存在する物理的なリソースの容量を超える仮想化 CPU または仮想化メモリーを割り当てるのがオーバーコミットです。CPU のオーバーコミットを行うことで、使用率の低い仮想化サーバーやデスクトップをより少数のサーバーで実行することができるため、リソースとしてのシステム数が節約でき、節電効果や冷却効果、サーバーのハードウェアに対する投資効果などの実質的な効果を得ることができます。
ほとんどのプロセスで割り当てられたメモリーを常に 100% 必要とすることはありません。KVM ではこの性質を利用することで、ホスト物理マシンに実際にある物理的なメモリー以上のメモリーをゲスト仮想マシンに割り当てることができます。これをリソースのオーバーコミットと呼びます。

重要

オーバーコミットがあらゆるメモリー関連の問題に対する理想的なソリューションとなるわけではありません。メモリー不足に対処するための推奨される方法は、すべてのゲストのメモリー (およびホスト OS の 4GB) の合計がホスト物理マシンの物理的なメモリーより少なくなるよう、ゲストに少な目のメモリーを割り当てることです。ゲスト仮想マシンにさらに多くのメモリーが必要な場合は、ゲスト仮想マシンの swap 領域を増やします。それでもなお、オーバーコミットを採用する場合には慎重に行なうようにしてください。
KVM ハイパーバイザーで実行しているゲスト仮想マシン群には、そのマシン群専用に割り当てられた物理的な RAM ブロックはありません。代わりに、各ゲスト仮想マシンはホスト物理マシンの Linux プロセスとして動作します。つまり、メモリーが要求された場合にのみホスト物理マシンの Linux カーネルによってメモリーが割り当てられます。また、ホスト物理マシンのメモリー管理機能により、物理的なメモリーと swap 領域間でゲスト仮想マシンのメモリーを移動させることができます。オーバーコミットを採用する際は、すべてのゲスト仮想マシンだけでなく物理ホストのプロセスも処理できるよう、ホスト物理マシン上に十分な swap 領域を配分する必要があるのはこのためです。原則として、ホスト物理マシンのオペレーティングシステムには最大 4GB のメモリーと最小 4GB の swap 領域が必要となります。詳細は、例7.1「メモリーのオーバーコミット例」 を参照してください。
Red Hat ナレッジベース には、swap パーティションのサイズを安全かつ効率的に確定する方法について記載されています。

注記

以下の例は、swap を設定する方法のみを説明するために提供されています。記載されている設定がご使用の環境には適さない場合もありますので注意してください。

例7.1 メモリーのオーバーコミット例

この例では、オーバーコミットに必要な swap 領域を計算する方法について説明しています。簡単に見えるかもしれませんが、オーバーコミットによる影響を無視しないようにしてください。先に進む前に、まず 重要 をご覧ください。
ExampleServer1 に物理 RAM が 32GB あるとします。このシステムは 50 ゲスト仮想マシンを実行するように設定されています。各ゲストには 1GB の仮想化メモリーが必要になります。前述のように、ホスト物理マシンのシステム自体にも最大 4GB のメモリー (ゲスト仮想マシンのメモリーとは別) と swap 領域が最小でも 4GB が追加で必要になります。
swap 領域は以下のように計算します。
  • すべてのゲスト仮想マシンに必要なメモリーの合計量を計算します。この例では、50 ゲスト仮想マシン * 1GB メモリー (1 ゲスト仮想マシンあたり) = 50GB になります。
  • ホスト物理マシンのオペレーティングシステムおよびホスト物理マシンの最小 swap 領域に必要なメモリー量に、ゲスト仮想マシンメモリー量を加えます。この例では、50GB ゲスト仮想マシンメモリー + 4GB ホスト物理マシン OS + 4GB swap 最小サイズ = 58GB になります。
  • この値からシステム上にある物理 RAM の容量を引きます。この例では、58GB - 32GB = 26GB になります。
  • 算出される値は割り当てる必要のある swap 領域になります。この例では、26GB になります。

注記

オーバーコミットはすべてのゲスト仮想マシンで役に立つわけではありませんが、集中的なメモリー使用が最小限となるデスクトップ仮想化の設定や、同一の設定の複数のゲスト仮想マシンを KSM で実行する場合などに機能することが明らかになっています。swap やメモリーのオーバーコミットの設定は、それぞれの環境や設定が異なるため、プラグインのように簡単に採用できるものではなく、また設定の際に決まった定形があるわけでもありません。 設定を変更する前に慎重に検討し、ご使用の環境や設定を完全に理解した上で変更を行なってください。
KSM およびオーバーコミットについての詳細は、8章KSM を参照してください。

7.2. 仮想化 CPU のオーバーコミット

KVM ハイパーバイザーは、仮想化した CPU のオーバーコミットに対応しています。仮想化した CPU は、ゲスト仮想マシンで許可できる負荷の限界までオーバーコミットすることができます。VCPU (仮想化 CPU) をオーバーコミットする際は、負荷が 100% に近づくと要求がドロップされたり、使用不可となるレスポンスタイムが発生する恐れがあるため十分に注意してください。
仮想 CPU (VCPU) のオーバーコミットを行う最適な状態は、単一のホスト物理マシンに複数のゲスト仮想マシンがある場合です。ここでは、ゲストは同一の VCPU を共有しません。このタイプの負荷には、Linux スケジューラーが非常に効率的です。KVM が安全にサポートするのは単一ホスト物理マシンにおいて、負荷が 100% 未満のゲスト仮想マシンで、(5 台の仮想マシン上の) 5 つの VCPU に対して1 つの物理 CPU という割合の場合です。KVM はこれら全マシン間で切り替えを実行し、負荷のバランスを取ります。
物理的なプロセッシングコア数を超えた状態の完全対称型マルチプロセッシングのゲスト仮想マシンはオーバーコミットできません。たとえば、VCPU 数が 4 つのゲスト仮想マシンは、デュアルコアプロセッサーのホスト物理マシンでは実行すべきではありません。実際の物理プロセッシングコア数を超えた状態の完全対称型マルチプロセッシングのゲスト仮想マシンをオーバーコミットすると、パフォーマンスが大幅に低下する原因となります。
ゲスト仮想マシンに割り当てる VCPU 数は、最大でも物理的なコア数と同数にするのが適切であり、その場合は予想通りの動作となります。たとえば、クアッドコア (プロセッサーコア数が 4 つ) のホストなら VCPU 数が 4つのゲスト仮想マシンを実行できます。この場合、負荷が 100% 未満なら、この設定で効率的に動作するはずです。

重要

十分な検証を行っていない状態で、実稼働環境でのメモリーや CPU のオーバコミットは実施しないでください。オーバーコミットしている環境では、メモリーやプロセッシングリソースを 100% 使用するアプリケーションは不安定になる可能性があります。導入する前にテストを行ってください。
仮想マシンでのパフォーマンスを最適化する方法については、Red Hat Enterprise Linux 6 仮想化のチューニングと最適化ガイド を参照してください。

第8章 KSM

最近のオペレーティングシステムでは共有メモリーという概念が一般的になってきました。たとえば、プログラムが初めて起動する際に、そのプログラムはその親プログラムとすべてのメモリーを共有します。子プログラムまたは親プログラムのいずれかがメモリーの変更を試行すると、カーネルによって新しいメモリー領域が割り当てられ、元のコンテンツがコピーされます。これにより、プログラムがこの新たな範囲を変更できるようになります。これがコピーオンライト (copy on write) と呼ばれるものです。
KSM はこの概念を逆に応用した Linux の新しい機能になります。KSM により、カーネルはすでに実行中の複数のプログラムを検査し、それらのメモリーを比較することができます。メモリーの領域またはページがまったく同一である場合は、KSM は複数ある同一メモリーページを 1 つのページに減らし、このページにはコピーオンライトのマークが付けられます。ページのコンテンツがゲスト仮想マシンによって変更された場合は、そのゲスト仮想マシン用に新しいページが作成されます。
KSM は KVM を使った仮想化に便利です。ゲスト仮想マシンの起動時に、ゲスト仮想マシンは親の qemu-kvm プロセスからのメモリーしか継承しません。同じオペレーティングシステムやアプリケーションを複数のゲストが実行している場合、ゲスト仮想マシンがゲスト仮想マシンのオペレーティングシステムのコンテンツを実行し始めると、イメージを共有することができるようになります。KSM はまったく同一のページのみを識別し、マージします。このため、ゲスト仮想マシンが干渉されたり、ホスト物理マシンやゲストの安全に影響を与えることはありません。KSM の機能によって KVM は同一のゲスト仮想マシンのメモリー領域が共有されるよう要求することができます。
KSM によってメモリーの速度やその用途が広がります。KSM を使用すると、共通の処理データはキャッシュやメインメモリーに格納されます。これにより KVM ゲストのキャッシュミスが低減するため、一部のアプリケーションやオペレーティングシステムのパフォーマンスを向上させることができます。また、メモリーを共有することにより、ゲストの全体的なメモリー使用を抑えるため、より多くのリソースを有効に活用できるようになります。

注記

Red Hat Enterprise Linux 6.5 より、KSM は NUMA 対応になりました。これにより、ページコアレッシングの実行時に NUMA ローカリティーが考慮されることになり、リモートノードに移行されるページに関連するパフォーマンスの低下を防ぐことができるようになります。Red Hat は、KSM の使用時にはノード間のメモリーマージを控えることを推奨します。KSM が使用中の場合には、/sys/kernel/mm/ksm/merge_across_nodes 調整可能パラメーターを 0 に変更し、複数の NUMA ノード間でのページのマージを防ぎます。多量のノード間マージが実行されると、カーネルメモリーのアカウンティング統計は相反する結果となる可能性があります。そのため、numad も KSM デーモンが多量のメモリーをマージした後に混乱する可能性があります。システムに大量の空きメモリーがある場合、KSM デーモンをオフにし、無効にすることでパフォーマンスを向上させることができます。NUMA についての詳細は、『Red Hat Enterprise Linux パフォーマンスチューニングガイド』 を参照してください。
Red Hat Enterprise Linux では、KSM の管理に以下の 2 種類の方法を使用しています。
  • ksm サービス: KSM カーネルスレッドの起動と停止を行います。
  • ksmtuned サービス: ksm の制御と調整を行い、同じページのマージを動的に管理します。この ksmtuned サービスは ksm を起動し、メモリー共有が必要ない場合には ksm サービスを停止します。新規のゲストが作成されたり、ゲストが破棄された場合には、retune パラメーターを使い、この ksmtuned サービスに対して実行の指示を出さなければなりません。
いずれのサービスも標準のサービス管理ツールで制御されます。
KSM サービス

ksm サービスは qemu-kvm パッケージに含まれています。Red Hat Enterprise Linux 6 の KSM はデフォルトではオフになっています。 ただし、Red Hat Enterprise Linux 6 を KVM ホスト物理マシンとして使用する場合は ksm/ksmtuned サービスによってオンになる可能性があります。

ksm サービスを起動していない場合は、KSM で共有されるページは 2000 ページのみになります。このデフォルト値ではページ数が少ないため、メモリー節約で得られる利点も限られます。
ksm サービスを起動すると、KSM は最大でホスト物理マシンシステムのメインメモリーの 50% まで共有するようになります。ksm サービスを起動して KSM がより多くのメモリーを共有できるようにします。
# service ksm start
Starting ksm:                                              [  OK  ]
ksm サービスをデフォルトのスタートアップ順序に追加することができます。chkconfig コマンドを使って ksm サービスを永続化します。
# chkconfig ksm on
KSM チューニングサービス

ksmtuned サービスにはオプションがありません。ksmtuned サービスはループして ksm の調整を行います。ゲスト仮想マシンが作成されたり、破棄された場合は、libvirt によって ksmtuned サービスに通知されます。

# service ksmtuned start
Starting ksmtuned:                                         [  OK  ]
ksmtuned サービスは retune パラメーターを使って調整できます。retune パラメーターの指示によって ksmtuned は手動によるチューニング機能を実行します。
ファイル内のパラメーターを変更する前に、以下の用語を明確に理解しておく必要があります。
  • thres - キロバイト単位のアクティブ化しきい値です。thres 値とすべての qemu-kvm プロセスによって消費されるメモリー量である RSZ 値の合計がシステムメモリーの合計を上回ると、KSM サイクルがトリガーされます。このパラメーターは、KSM_THRES_COEF に定義されるパーセンテージをキロ単位で表したものと同等です。
/etc/ksmtuned.conf ファイルは ksmtuned サービスの設定ファイルになります。デフォルトの ksmtuned.conf ファイルの出力を以下に示します。
# Configuration file for ksmtuned.

# How long ksmtuned should sleep between tuning adjustments
# KSM_MONITOR_INTERVAL=60

# Millisecond sleep between ksm scans for 16Gb server.
# Smaller servers sleep more, bigger sleep less.
# KSM_SLEEP_MSEC=10

# KSM_NPAGES_BOOST is added to the npages value, when free memory is less than thres.
# KSM_NPAGES_BOOST=300

# KSM_NPAGES_DECAY Value given is subtracted to the npages value, when free memory is greater than thres.
# KSM_NPAGES_DECAY=-50

# KSM_NPAGES_MIN is the lower limit for the npages value.
# KSM_NPAGES_MIN=64

# KSM_NAGES_MAX is the upper limit for the npages value.
# KSM_NPAGES_MAX=1250

# KSM_TRES_COEF - is the RAM percentage to be calculated in parameter thres.
# KSM_THRES_COEF=20

# KSM_THRES_CONST - If this is a low memory system, and the thres value is less than KSM_THRES_CONST, then reset thres value to KSM_THRES_CONST value.
# KSM_THRES_CONST=2048

# uncomment the following to enable ksmtuned debug information
# LOGFILE=/var/log/ksmtuned
# DEBUG=1
KSM の変数とモニタリング

KSM はモニタリングデータを /sys/kernel/mm/ksm/ ディレクトリーに格納します。このディレクトリー内のファイルはカーネルによって更新されるため、KSM の使用量と統計値の正確な記録となります。

以下に示す変数も /etc/ksmtuned.conf ファイル内にある設定可能な変数となります。

/sys/kernel/mm/ksm/ 以下のファイル

full_scans
実行された完全スキャン数
pages_shared
共有されたページの合計数
pages_sharing
現在共有されているページ数
pages_to_scan
スキャンされなかったページ数
pages_unshared
共有されなくなったページ数
pages_volatile
揮発性のページ数
run
KSM プロセスが実行しているかどうか
sleep_millisecs
スリープのミリ秒数
/etc/ksmtuned.conf ファイルに DEBUG=1 の行を追加すると、KSM チューニングのアクティビティーが /var/log/ksmtuned ログファイルに格納されます。LOGFILE パラメーターを使用するとログファイルの場所を変更することができます。ただし、ログファイルの場所を変更すると、SELinux 設定に特殊な設定が必要となる場合があるため、この変更はお勧めできません。
KSM の無効化

KSM にはパフォーマンス上のオーバーヘッドがあり、特定の環境やホスト物理マシンシステムには負荷が大きすぎる場合があります。

ksmtunedksm サービスを停止すると KSM を非アクティブ化することができます。これらのサービスの停止により KSM は非アクティブ化されますが、再起動後は元に戻ります。
# service ksmtuned stop
Stopping ksmtuned:                                         [  OK  ]
# service ksm stop
Stopping ksm:                                              [  OK  ]
再起動後も KSM の非アクティブな状態を永続化するには、chkconfig コマンドを使用します。 サービスをオフにするには次のコマンドを実行します。
# chkconfig ksm off
# chkconfig ksmtuned off

重要

KSM を使用する場合であっても、コミットする RAM に対して swap サイズの大きさが十分であることを確認してください。KSM は同一または同様のゲストの RAM 使用量を低減します。十分な swap 領域がなくても KSM を使ってゲストをオーバーコミットすることはおそらく可能ですが、ゲスト仮想マシンのメモリー使用によってページが共有されなくなる可能性があるため推奨されません。

第9章 ゲスト仮想マシンの高度な管理

本章では、システムリソースがゲスト仮想マシンで利用可能な場合に、それらのリソースの微調整を行ったり、制御したりするための高度な管理ツールについて説明します。

9.1. コントロールグループ (cgroup)

Red Hat Enterprise Linux 6 では、コントロールグループ と呼ばれる新たなカーネル機能を搭載しています。この機能は cgroup とも呼ばれています。cgroup により、ユーザーは CPU 時間、システムメモリー、ネットワーク帯域幅などのリソースやそれらのリソースの組み合わせをシステム上で実行中のユーザー定義のタスクグループ (プロセス) に割り当てることができるようになります。また、設定した cgroup のモニタリングを行ったり、特定のリソースに対する cgroup のアクセスを拒否することができるほか、稼働中のシステムで cgroup を動的に再設定することもできます。
cgroup 機能は libvirt で完全にサポートされています。デフォルトでは、各ゲストは libvirt により各種コントローラー用の別々のコントロールグループに配置されます (メモリー、CPU、blkio、デバイスなど)。
ゲストは起動される時点ですでに cgroup に属します。ここで必要な設定は cgroup でのポリシーの設定のみになります。cgroup についての詳細は、『Red Hat Enterprise Linux リソース管理ガイド』 を参照してください。

9.2. Huge page のサポート

はじめに

通常、x86 CPU は 4kB ページ単位でメモリーに対応しますが、huge page とも言われる大容量ページを使用することも可能です。KVM ゲストは huge page メモリーサポートとデプロイすることで、TLB (Transaction Lookaside Buffer) の CPU キャッシュヒット率を増加させてパフォーマンスを向上させることができます。huge page により、とくに大量のメモリーやメモリー集約型のワークロードに対するパフォーマンスが大幅に向上します。Red Hat Enterprise Linux 6 では、huge page の使用によってページサイズを拡大することで、大量のメモリーを効率的に管理することができます。

KVM ゲストに huge page を使用すると、ページテーブルに使用するメモリーが少なくなり、TLB (Translation Lookaside Buffer) ミスが減少します。これにより、とくにメモリー集約的な状況の場合にパフォーマンスが大幅に改善します。
Transparent huge page

Transparent huge pages (THP) とは、アプリケーションに必要な TLB エントリーを削減するカーネル機能のことです。また、すべての空きメモリーをキャッシュとして使用できるようにするためパフォーマンスが向上します。

Transparent huge page を使用する場合、qemu.conf ファイルに特別な設定は必要ありません。/sys/kernel/mm/redhat_transparent_hugepage/enabledalways に設定されている場合、Huge page がデフォルトで使用されます。
Transparent huge page によって hugetlbfs が使用できなくなるわけではありません。ただし、hugetlbfs を使用しない場合には、通常の 4 kb ページサイズではなく Transparent hugepage が KVM によって使用されます。

注記

Huge page を使用したメモリーパフォーマンスのチューニングの手順については、Red Hat Enterprise Linux 7 Virtualization Tuning and Optimization Guide を参照してください。

9.3. Hyper-V ハイパーバイザー上で Red Hat Enterprise Linux をゲスト仮想マシンとして実行する

Red Hat Enterprise Linux ゲスト仮想マシンは、Microsoft Windows Hyper-V ハイパーバイザーを実行する Microsoft Windows ホスト物理マシン上で実行することが可能です。特に以下の機能強化により、Red Hat Enterprise Linux ゲスト仮想マシンの導入と管理がより簡単になりました。
  • アップグレードされた VMBUS プロトコル - VMBUS プロトコルが Windows 8 レベルにアップグレードされました。この機能強化の一環として、VMBUS 割り込みがゲストの利用可能なすべての仮想 CPU で処理できるようになりました。さらに、Red Hat Enterprise Linux ゲスト仮想マシンと Windows ホスト物理マシン間のシグナルプロトコルが最適化されています。
  • 統合フレームバッファードライバー - グラフィックスパフォーマンスを強化し、Red Hat Enterprise Linux デスクトップのユーザーに対して優れた解像度を提供します。
  • ライブ仮想マシンバックアップサポート - ライブ Red Hat Enterprise Linux ゲスト仮想マシンの中断なしのバックアップサポートを提供します。
  • 固定サイズの Linux VHD を動的に拡張 - ライブのマウントされている固定サイズの Red Hat Enterprise Linux VHD の拡張を可能にします。
詳細は、Enabling Linux Support on Windows Server 2012 R2 Hyper-V の記事を参照してください。

注記

Hyper-V ハイパーバイザーでは、ディスクの未使用最終部分をユーザーが使用できるようにすることで、最後のパーティションの後に空きスペースがある場合に Red Hat Enterprise Linux ゲスト上で GPT でパーティションされたディスクの圧縮をサポートします。しかし、この操作によってディスクの 2 番目の GPT ヘッダーが警告を発することなく削除され、ゲストによってパーティションテーブルが検証されるとエラーメッセージが発生することがあります (parted でパーティションテーブルを出力するときなど)。これは、Hyper-V の既知の制限です。回避策として gdisk および e コマンドでエクスパートメニューを使用して、GPT ディスクを圧縮した後に 2 番目の GPT ヘッダーを手動でリストアすることが可能です。さらに、Hyper-V マネージャーの expand オプションを使用すると、ディスクの最後以外の場所に 2 番目の GPT ヘッダーを置くこともできますが、parted で移動できます。これらのコマンドの詳細は、 gdisk および parted の man ページを参照してください。

9.4. ゲスト仮想マシンのメモリー割り当て

以下の手順は、ゲスト仮想マシンにメモリーを割り当てる方法を示しています。以下に示す割り当て作業が有効になるのは起動時のみであり、メモリーの値に変更を加えた場合は次の起動時まで有効になりません。1 ゲストあたりに割り当てることのできる最大メモリーは 4 TiB です。ただし、このメモリー割り当てはホスト物理マシンのリソースが提供できる範囲を超えない場合にのみ有効です。
有効なメモリーの単位:
  • バイト、b または bytes
  • キロバイト、KB (103 または 1,000 バイト)
  • キビバイト、k または KiB (210 または 1024 バイト)
  • メガバイト、MB (106 または 1,000,000 バイト)
  • メビバイト、M または MiB (220 または 1,048,576 バイト)
  • ギガバイト、GB (109 または 1,000,000,000 バイト)
  • ギビバイト、G または GiB (230 または 1,073,741,824 バイト)
  • テラバイト、TB (1012 または 1,000,000,000,000 バイト)
  • テビバイト、T または TiB (240 または 1,099,511,627,776 バイト)
libvirt により値はすべて直近のキビバイトに切り上げられ、またハイパーバイザーで対応できる単位までさらに切り上げられる場合があるので注意してください。また、ハイパーバイザーの中には、4000KiB (または 4000 x 210 または 4,096,000 バイト) などの最小値を強制するものがあります。この値の単位は memory unit というオプションの属性で確定されます。この属性では、測定単位がキビバイト (KiB) にデフォルト設定されます (210 または 1024 バイトブロック単位)。
ゲスト仮想マシンがクラッシュする場合、オプションの属性 dumpCore を使用して、ゲスト仮想マシンのメモリーを生成されるコアダンプに含ませる (dumpCore='on') か、または含ませない (dumpCore='off') かの制御を行なうことができます。デフォルト設定は on になります。つまり、パラメーターが off に設定されていない限り、ゲスト仮想マシンのメモリーはコアダンプに含まれることになります。
currentMemory 属性でゲスト仮想マシンの実際のメモリー割り当てを確定します。ゲスト仮想マシンのオンザフライでのメモリーバルーニングを許可するには、この値を最大割り当て値よりも小さくすることができます。この値の設定を省略すると、memory 要素と同じ値にデフォルト設定されます。単位の属性の動作はメモリーの属性と同じです。
このセクションのすべてのケースでは、ドメイン XML を以下のように変更する必要があります。
<domain>
  
  <memory unit='KiB' dumpCore='off'>524288</memory>
  <!-- changes the memory unit to KiB and does not allow the guest virtual machine's memory to be included in the generated coredump file -->
  <currentMemory unit='KiB'>524288</currentMemory>
  <!-- makes the current memory unit 524288 KiB -->
  ...
</domain>

9.5. ゲスト仮想マシンを自動的に起動する

このセクションでは、ホスト物理マシンシステムの起動フェーズでゲスト仮想マシンを自動的に起動させる方法について説明します。
以下の例では、virsh を使ってゲスト仮想マシンの TestServer がホスト物理マシンの起動時に自動的に起動するようにしています。
# virsh autostart TestServer
Domain TestServer marked as autostarted
これでゲスト仮想マシンが、ホスト物理マシンで自動的に起動するようになりました。
ゲスト仮想マシンの自動起動を停止するには、--disable パラメーターを使用します。
# virsh autostart --disable TestServer
Domain TestServer unmarked as autostarted
これでゲスト仮想マシンがホスト物理マシンで自動的に起動しなくなります。

9.6. ゲスト仮想マシンの SMART ディスクモニタリングを無効にする

仮想ディスクおよび物理的なストレージデバイスはホスト物理マシンで管理されるため、SMART ディスクモニタリングは安全に無効にすることができます。
# service smartd stop
# chkconfig --del smartd

9.7. VNC サーバーを設定する

VNC サーバーを設定するには、システム > 設定 にある リモートデスクトップ アプリケーションを使用します。または、vino-preferences コマンドを実行することもできます。
次の手順に従って、専用 VNC サーバーセッションのセットアップを行ないます。
必要であれば、~/.vnc/xstartup ファイルを作成し、vncserver が起動した場合は常に GNOME セッションを起動するよう編集します。vncserver スクリプトを初めて実行する際に、VNC セッションに使用するパスワードの入力が求められます。vnc サーバーファイルについての詳細は、『Red Hat Enterprise Linux インストールガイド』 を参照してください。

9.8. 固有の MAC アドレスを新たに生成する

ゲスト仮想マシンに固有の MAC アドレスを新たに生成しなければならない場合があります。本ガイドの作成時点では、新しい MAC アドレスを生成するための使用できるコマンドラインツールはありません。このため、ここでは以下に示すスクリプトを使用してゲスト仮想マシンの新しい MAC アドレスを生成することができます。このスクリプトには macgen.py という名前を付けてゲスト仮想マシンに保存します。そのディレクトリーから ./macgen.py コマンドを使ってスクリプトを実行します。これで新しい MAC アドレスが生成されます。出力例を以下に示します。
$ ./macgen.py 
00:16:3e:20:b0:11
#!/usr/bin/python
# macgen.py script to generate a MAC address for guest virtual machines
#
import random
#
def randomMAC():
	mac = [ 0x00, 0x16, 0x3e,
		random.randint(0x00, 0x7f),
		random.randint(0x00, 0xff),
		random.randint(0x00, 0xff) ]
	return ':'.join(map(lambda x: "%02x" % x, mac))
#
print randomMAC()

9.8.1. ゲスト仮想マシンの新しい MAC を作成する別の方法

python-virtinst の組み込みモジュールを使って、ゲスト仮想マシンの設定ファイルで使用する新しい MAC アドレスと UUID を生成することもできます。
# echo  'import virtinst.util ; print\
 virtinst.util.uuidToString(virtinst.util.randomUUID())' | python
# echo  'import virtinst.util ; print virtinst.util.randomMAC()' | python
上記のスクリプトは以下のようにスクリプトファイルとして実装することもできます。
#!/usr/bin/env python
#  -*- mode: python; -*-
print ""
print "New UUID:"
import virtinst.util ; print virtinst.util.uuidToString(virtinst.util.randomUUID())
print "New MAC:"
import virtinst.util ; print virtinst.util.randomMAC()
print ""

9.9. ゲスト仮想マシンのレスポンスタイムを改善する

特定の負荷や使用パターンによって、ゲスト仮想マシンの応答が遅くなるときがあります。ゲスト仮想マシンの応答が遅くなる、または応答しなくなる原因となる状況のいくつかを以下に示します。
  • 過度にメモリーをオーバーコミットしている
  • プロセッサーの使用率が高い状態でメモリーをオーバーコミットしている
  • その他のビジーなプロセスや停止しているプロセスがホスト物理マシン上にある (qemu-kvm プロセス以外)
KVM ゲスト仮想マシンは Linux プロセスとして機能します。Linux プロセスはメインメモリー (物理 RAM) に永続的に保持されることはなく、それらが使用されていない場合などはとくに swap 領域 (仮想メモリー) に置かれます。ゲスト仮想マシンが長時間にわたって非アクティブな状態の場合は、ホスト物理マシンのカーネルはゲスト仮想マシンを swap に移動することがあります。この場合、swap は物理メモリーよりも速度が遅いため、ゲストが応答していないように見えるかもしれません。しかし、ゲストがメインメモリーにいったんロードされるとこの状態は変わります。ゲスト仮想マシンを swap からメインメモリーにロードするプロセスには、ゲスト仮想マシンに割り当てられる RAM の 1 ギガバイトごとに数秒の時間がかかる場合があることに注意してください (ただし所要時間は swap に使用されるストレージのタイプや各種コンポーネントのパフォーマンスによって異なります)。
メモリーがオーバーコミットしているかどうかやメモリー全体の使用量に関係なく、KVM ゲスト仮想マシンのプロセスを swap に移動させることができます。
安全ではないオーバーコミットレベルの使用や swap をオフにしたゲスト仮想マシンのプロセス、その他の重大なプロセスのオーバーコミットなどは推奨されません。メモリーのオーバーコミットを行なう際は、常にホスト物理マシンに十分な swap 領域があることを確認してください。
KVM でオーバーコミットを行う方法についての詳細は、「はじめに」を参照してください。

警告

仮想メモリーを使用すると、Linux システムがシステム上の物理 RAM に実際にあるメモリーより多くのメモリーを使用できるようになります。メモリーをあまり使用していないプロセスをスワップアウトし、アクティブなプロセスがメモリーを使用できるようにすることでメモリー使用率が改善されます。swap を無効にすると、すべてのプロセスが物理 RAM に格納されるため、メモリー使用率が減少します。
swap をオフにする場合、ゲスト仮想マシンのオーバーコミットを行わないでください。swap なしにゲスト仮想マシンをオーバーコミットすると、ゲスト仮想マシンまたはホスト物理マシンのシステムがクラッシュする可能性があります。

9.10. libvirt による仮想マシンのタイマー管理

ゲスト仮想マシン上で時間を正確に管理することは、仮想化プラットフォームにおける主要な課題となります。複数のハイパーバイザーが様々な方法で時間管理の問題を処理しようとします。libvirt では、ドメインの XML 内で <clock> と <timer> の要素を使い、ハイパーバイザーからは独立した時間管理の構成を提供します。ドメイン XML の編集は virsh edit コマンドを使って行います。詳細は、「ゲスト仮想マシンの設定ファイルの編集」を参照してください。
<clock> 要素は、ゲスト仮想マシンのクロックとホスト物理マシンのクロックとの同期方法を決定するために使用されます。clock 要素には次のような属性があります。
  • offset: ゲスト仮想マシンのクロックをどのようにホスト物理マシンのクロックでオフセットするかを判別します。offset 属性の値は以下の値になります。

    表9.1 Offset 属性の値

    詳細
    utcゲスト仮想マシンのクロックは、起動時に UTC に同期されます。
    localtimeゲスト仮想マシンのクロックは、起動時にホスト物理マシンの設定タイムゾーンに同期されます (該当する場合)。
    timezoneゲスト仮想マシンのクロックは、timezone 属性で指定したタイムゾーンに同期されます。
    variableゲスト仮想マシンのクロックは UTC の任意のオフセットに同期されます。UTC に対する差分を adjustment 属性を使って秒数単位で指定します。ゲスト仮想マシンは RTC (リアルタイムクロック) を自由に調整することができ、行われた調整は再起動後も維持されます。これは RTC の調整が再起動するたびすべて失われる utc モードとは対照的です。

    注記

    デフォルトでは、utc の値が仮想マシンのクロックオフセットとして設定されます。ただし、ゲスト仮想マシンのクロックが localtime の値を使って実行される場合、ゲスト仮想マシンのクロックをホスト物理マシンのクロックと同期させるために、クロックオフセットを別の値に変更する必要があります。
  • timezone 属性は、ゲスト仮想マシンのクロックに使用されるタイムゾーンを決定します。
  • adjustment 属性は、ゲスト仮想マシンのクロック同期の差分を指定します。UTC に対して増減する秒数を指定します。

例9.1 常に UTC に同期する

<clock offset="utc" />

例9.2 常にホスト物理マシンのタイムゾーンに同期する

<clock offset="localtime" />

例9.3 任意のタイムゾーンに同期する

<clock offset="timezone" timezone="Europe/Paris" />

例9.4 UTC に同期させてから任意の秒数を増減させる

<clock offset="variable" adjustment="123456" />

9.10.1. timer は clock の子要素です。

clock 要素には子要素として、ゼロまたはそれ以上の timer 要素を持たせることができます。timer 要素には以下の属性を含めます。name のみが必須の属性となり、これ以外の属性はすべてオプションです。
name 属性は、使用するタイムソースを決定するもので、以下のいずれかになります。

表9.2 name 属性の値

詳細
pitProgrammable Interval Timer - 定期的な割り込みが付いたタイマーです。
rtcReal Time Clock - 継続的に実行するタイマーで、定期的な割り込みが付いています。
tscTime Stamp Counter - リセット後のティック数をカウントします。割り込みなしです。
kvmclockKVM クロック - KVM ゲスト仮想マシン用に推奨しているクロックソースです。KVM の pvclock または kvm-clock によりゲスト仮想マシンがホスト物理マシンのウォールクロックタイムを読み込みます。

9.10.2. track

track 属性は、タイマーで追跡する対象を指定します。name の値の rtc にのみ使用します。

表9.3 track 属性の値

詳細
boot旧オプションの host physical machine に該当します。これは未対応の追跡オプションです。
guestRTC が常にゲスト仮想マシンの時間を追跡します。
wallRTC が常にホストの時間を追跡します。

9.10.3. tickpolicy

tickpolicy 属性は、ゲスト仮想マシンにティックを渡すために使用されるポリシーです。以下の値を受け付けます。

表9.4 tickpolicy 属性の値

詳細
delay通常レートで配信を継続します (ティックが遅延する)。
catchup遅れを取り戻すため、高めのレートで配信します。
merge複数のティックを単一のティックにマージします。
discardミスしたティックはすべて破棄します。

9.10.4. frequency、mode、および present

frequency 属性は、Hz で測定される固定周波数を設定するために使用されます。この属性は、name 要素の値が tsc の場合にのみ使用されます。それ以外のすべてのタイマーは固定周波数 (pitrtc) で動作します。
mode は、タイムソースをゲスト仮想マシンに公開する方法を指定します。この属性は name の値が tsc の場合にのみ使用されます。それ以外のすべてのタイマーは常にエミュレートされます。コマンドは、<timer name='tsc' frequency='NNN' mode='auto|native|emulate|smpsafe'/> のようになります。モードの定義を表に示します。

表9.5 mode 属性の値

詳細
autoTSC が不安定な場合はネイティブです。これ以外はネイティブな TSC アクセスを許可します。
native常にネイティブな TSC アクセスを許可します。
emulate常に TEC をエミュレートします。
smpsafe常に TSC とインターロックの SMP をエミュレートします。
present は、ゲスト仮想マシンに見えるデフォルトのタイマーセットを上書きします。

表9.6 present 属性の値

詳細
yesこのタイマーをゲスト仮想マシンに見えるよう強制します。
noこのタイマーがゲスト仮想マシンに見えないように強制します。

9.10.5. クロック同期を使用した例

例9.5 RTC タイマーおよび PIT タイマーを使ってローカル時間に同期しているクロック

以下の例では、クロックは RTC タイマーおよび PIT タイマーを使ってローカル時間に同期しています。
<clock offset="localtime">
	<timer name="rtc" tickpolicy="catchup" track="guest virtual machine" />
	<timer name="pit" tickpolicy="delay" />
	
</clock>

注記

PIT clocksource は、以下の条件の下で、64 ビットのホストで実行される 32 ビットのゲスト (PIT を使用できない) と共に使用することができます。
  • ゲスト仮想マシンには 1 つの CPU のみ。
  • APIC タイマーは無効にされている必要がある ("noapictimer" コマンドラインオプションを使用)。
  • NoHZ モードはゲストで無効にされている必要がある ("nohz=off" コマンドラインオプションを使用)。
  • 高解像度タイマーモードはゲストで無効にされている必要がある ("highres=off" コマンドラインオプションを使用)。
  • PIT clocksource は高解像度タイマーモードまたは NoHz モードのいずれとも互換性がない。

9.11. PMU を使用してゲスト仮想マシンのパフォーマンスを監視する

Red Hat Enterprise Linux 6.4 では、vPMU (仮想 PMU) がテクニカルプレビューとして採用されました。vPMU は Intel の PMU (Performance Monitoring Units) をベースとし、Intel マシン上でのみ使用できます。PMU により、ゲスト仮想マシンがどのように動作しているのかを示す統計値を追跡することができます。
パフォーマンスモニタリングを使用すると、開発を行なう場合など、プロファイリング用のパフォーマンスツールを使いながら CPU の PMU カウンターも使用することができます。仮想パフォーマンスモニタリングユニットの機能により、仮想マシンのユーザーは、ゲスト仮想マシン内でパフォーマンス関連の問題を招く可能性のある要因を特定できるようになるため、KVM ゲスト仮想マシンのプロファイリング機能が改善されます。
この機能を有効にする場合は -cpu host フラグを設定する必要があります。
この機能に対応するのは Red Hat Enterprise Linux 6 を稼働しているゲスト仮想マシンのみで、この機能はデフォルトでは無効にされています。この機能は Linux perf ツールを使用しないと正しく動作しません。次のコマンドを使って perf パッケージを必ずインストールしてください。
# yum install perf.
perf コマンドについての詳細は、perf の man ページをご覧ください。

9.12. ゲスト仮想マシンの電力管理

Libvirt の Domain XML 内にある次のパラメーターを変更すると、ゲスト仮想マシンのオペレーティングシステムに対する BIOS の広告を強制的に有効にしたり無効にしたりすることが可能です。
...
  <pm>
    <suspend-to-disk enabled='no'/>
    <suspend-to-mem enabled='yes'/>
  </pm>
  ...
pm 要素を使用すると、S3 (suspend-to-disk) と S4 (suspend-to-mem) の ACPI スリープ状態に対する BIOS サポートを有効 ('yes') にしたり無効 ('no') にしたりすることができます。何も指定しないと、ハイパーバイザーはそのデフォルト値のままになります。

第10章 ゲスト仮想マシンデバイスの設定

Red Hat Enterprise Linux 6 は、ゲスト仮想マシンの以下の 3 つのクラスのデバイスに対応します。
  • エミュレートされたデバイス は、実際のハードウェアを模倣する純粋の仮想デバイスです。変更されていないゲストオペレーティングシステムは標準のインボックスドライバーを使ってこれらのデバイスと動作できるようになります。Red Hat Enterprise Linux 6 は、最高 216 の virtio デバイスに対応します。
  • Virtio デバイス は、仮想マシン内で最適に動作するように設計された純粋の仮想デバイスです。Virtio デバイスは、エミュレートされたデバイスと似ていますが、Linux 以外の仮想マシンにはこれらのデバイスが必要とするドライバーがデフォルトで含まれていません。仮想マシンマネージャー (virt-manager) や Red Hat Enterprise Virtualization Hypervisor といった仮想化管理ソフトウェアは、対応する Linux 以外のゲストオペレーティングシステムにこれらのドライバーを自動的にインストールします。Red Hat Enterprise Linux 6 は最高 700 の scsi ディスクに対応します。
  • 割り当てデバイス は、仮想マシンに公開されている物理デバイスです。この方法は、パススルーとも呼ばれます。デバイス割り当てにより、仮想マシンによる幅広いタスクでの PCI デバイスへの排他アクセスが可能になり、PCI デバイスをゲストオペレーティングシステムに物理的にアタッチされているかのように表示させ、動作させることが可能になります。Red Hat Enterprise Linux 6 は、仮想マシン 1 台あたり最高 32 の割り当てデバイスに対応します。
デバイス割り当ては、一部のグラフィックスデバイスを含め PCIe デバイス上でサポートされています。Nvidia K シリーズ Quadro、GRID、および Tesla グラフィックスカード GPU 機能が Red Hat Enterprise Linux 6 のデバイス割り当てでサポートされるようになりました。パラレル PCI デバイスは割り当てデバイスとしてサポートされますが、セキュリティーとシステム設定の競合により厳しい制限があります。

注記

仮想マシンにアタッチできるデバイス数は、いくつかの要素に左右されます。そのうちの 1 つは、QEMU プロセス (/etc/security/limits.conf で設定。/etc/libvirt/qemu.conf によるオーバーライドが可能) が開くファイル数です。この他には、仮想バスで利用可能なスロット数や sysctl で設定されたシステム全体でのオープンファイルの制限があります。
特定デバイスの詳細および制限の詳細は、「デバイス」 を参照してください。
Red Hat Enterprise Linux 6 は、仮想マシンへの単一機能のスロットとして公開されるデバイスの PCI ホットプラグをサポートします。単一機能のホットデバイスとマルチ機能のホットデバイスの個別の機能は、このサポートを有効にするように設定できます。デバイスを仮想マシンへのマルチ機能の PCI スロットとして公開する設定は、ノンホットプラグアプリケーションに推奨されます。

注記

割り込み再マッピングのプラットフォームサポートは、割り当てデバイスを持つゲストをホストから完全に分離するために必要です。このサポートがない場合、ホストは悪意のあるゲストからの割り込み挿入攻撃に対して脆弱になる可能性があります。ゲストが信頼される環境では、管理者は vfio_iommu_type1 モジュールに対して allow_unsafe_interrupts オプションを使用する PCI デバイス割り当て許可を選択できます。これは、以下を含む .conf ファイル (例: local.conf) を /etc/modprobe.d に追加することで永続的に実行できます。
options vfio_iommu_type1 allow_unsafe_interrupts=1
または、sysfs エントリーを動的に使用することも同じことが実行できます。
# echo 1 > /sys/module/vfio_iommu_type1/parameters/allow_unsafe_interrupts

10.1. PCI デバイス

PCI デバイス割り当ては、Intel VT-d または AMD IOMMU 対応のハードウェアプラットフォーム上でのみ利用可能です。PCI デバイス割り当てが機能するには、Intel VT-d または AMD IOMMU の仕様が BIOS で有効化されている必要があります。

手順10.1 Intel システムでの PCI デバイス割り当て準備

  1. Intel VT-d 仕様の有効化

    Intel VT-d 仕様は、物理デバイスを直接仮想マシンに割り当てるためのハードウェアサポートを提供します。この仕様は、Red Hat Enterprise Linux で PCI デバイス割り当てを使用するために必要なものです。
    Intel VT-d 仕様は、BIOS で有効化されている必要があります。システムメーカーの中には、この仕様をデフォルトで無効としているところもあります。この仕様に使う用語はメーカーによって異なります。使用されている用語に関しては、システムメーカーの資料を参照してください。
  2. カーネル内で Intel VT-d をアクティブ化する

    カーネル内で Intel VT-d をアクティブ化するには、intel_iommu=on パラメーターを /etc/sysconfig/grub ファイルの GRUB_CMDLINX_LINUX 行の終わりの引用符の内側に追加します。
    以下の修正例は、grub ファイルで Intel VT-d がアクティブ化されたものです。
    GRUB_CMDLINE_LINUX="rd.lvm.lv=vg_VolGroup00/LogVol01 
    vconsole.font=latarcyrheb-sun16 rd.lvm.lv=vg_VolGroup_1/root 
    vconsole.keymap=us $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/
    rhcrashkernel-param || :) rhgb quiet intel_iommu=on"
  3. config file の再生成

    以下を実行して /boot/grub2/grub.cfg を再生成します。
    grub2-mkconfig -o /boot/grub2/grub.cfg
  4. 準備完了

    システムを再起動して、変更を有効にします。これでシステムは、PCI デバイス割り当てに対応します。

手順10.2 AMD システムでの PCI デバイス割り当て準備

  1. AMD IOMMU 仕様の有効化

    AMD IOMMU 仕様は、Red Hat Enterprise Linux で PCI デバイス割り当てを使用するために必要なものです。この仕様は、BIOS で有効化されている必要があります。システムメーカーのなかには、この仕様をデフォルトで無効としているところもあります。
  2. IOMMU カーネルサポートの有効化

    amd_iommu=on/etc/sysconfig/grub の GRUB_CMDLINX_LINUX 行の終わりの引用符の内側に追加し、AMD IOMMU 仕様が起動時に有効にされるようにします。
  3. config file の再生成

    以下を実行して /boot/grub2/grub.cfg を再生成します。
    grub2-mkconfig -o /boot/grub2/grub.cfg
  4. 準備完了

    システムを再起動して、変更を有効にします。これでシステムは、PCI デバイス割り当てに対応します。

10.1.1. virsh を使用した PCI デバイスの割り当て

このステップでは、KVM ハイパーバイザー上の仮想マシンに PCI デバイスを割り当てる方法を説明します。
以下の例では、PCI 識別子コード pci_0000_01_00_0 の PCIe ネットワークコントローラーと guest1-rhel6-64 という名前の完全仮想化ゲストマシンを使います。

手順10.3 virsh を使用した PCI デバイスのゲスト仮想マシンへの割り当て

  1. デバイスの特定

    最初に、仮想マシンへのデバイス割り当てに指定されているPCI デバイスを特定します。lspci コマンドを使用して利用可能な PCI デバイスを一覧表示します。lspci の出力は grep で絞り込むことができます。
    この例では、以下の出力で強調表示されているイーサネットコントローラーを使用します。
    # lspci | grep Ethernet
    00:19.0 Ethernet controller: Intel Corporation 82567LM-2 Gigabit Network Connection
    01:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    01:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    このイーサネットコントローラーは 00:19.0 の短い識別子で表示されています。この PCI デバイスを仮想マシンに割り当てるには、virsh が使用する詳細な識別子を見つける必要があります。
    これを実行するには、virsh nodedev-list コマンドを使用して、ホストマシンにアタッチされている特定の種類 (pci) のデバイスをすべて一覧表示します。次に、使用するデバイスの短い識別子にマップされている文字列の出力を探します。
    この例では、短い識別子 00:19.0 でイーサネットコントローラーにマップする文字列を強調表示しています。詳細な識別子では、:. の文字がアンダースコアに置き換えられています。
    # virsh nodedev-list --cap pci
    pci_0000_00_00_0
    pci_0000_00_01_0
    pci_0000_00_03_0
    pci_0000_00_07_0
    pci_0000_00_10_0
    pci_0000_00_10_1
    pci_0000_00_14_0
    pci_0000_00_14_1
    pci_0000_00_14_2
    pci_0000_00_14_3
    pci_0000_00_19_0
    pci_0000_00_1a_0
    pci_0000_00_1a_1
    pci_0000_00_1a_2
    pci_0000_00_1a_7
    pci_0000_00_1b_0
    pci_0000_00_1c_0
    pci_0000_00_1c_1
    pci_0000_00_1c_4
    pci_0000_00_1d_0
    pci_0000_00_1d_1
    pci_0000_00_1d_2
    pci_0000_00_1d_7
    pci_0000_00_1e_0
    pci_0000_00_1f_0
    pci_0000_00_1f_2
    pci_0000_00_1f_3
    pci_0000_01_00_0
    pci_0000_01_00_1
    pci_0000_02_00_0
    pci_0000_02_00_1
    pci_0000_06_00_0
    pci_0000_07_02_0
    pci_0000_07_03_0
    使用するデバイスを呼び出す PCI デバイス番号は他のステップで必要になるので、その番号を書き留めます。
  2. デバイス情報の確認

    ドメインやバスおよび情報については、virsh nodedev-dumpxml コマンドからの出力を参照することができます。
    virsh nodedev-dumpxml pci_0000_00_19_0
    <device>
      <name>pci_0000_00_19_0</name>
      <parent>computer</parent>
      <driver>
        <name>e1000e</name>
      </driver>
      <capability type='pci'>
        <domain>0</domain>
        <bus>0</bus>
        <slot>25</slot>
        <function>0</function>
        <product id='0x1502'>82579LM Gigabit Network Connection</product>
        <vendor id='0x8086'>Intel Corporation</vendor>
        <iommuGroup number='7'>
          <address domain='0x0000' bus='0x00' slot='0x19' function='0x0'/>
        </iommuGroup>
      </capability>
    </device>

    注記

    IOMMU グループは、IOMMU から見たデバイスの可視性と分離度に基づいて決定されます。それぞれの IOMMU グループには、1 つ以上のデバイスが含まれる可能性があります。複数のデバイスが表示される場合、IOMMU グループ内のすべてのエンドポイントが、ゲストに割り当てられるグループ内のすべてのデバイスに対して要求される必要があります。これは、追加のエンドポイントをゲストに割り当てるか、または virsh nodedev-detach を使用してそれらをホストから分離させるかのいずれかの方法で実行できます。単一グループに含まれるデバイスは、複数のゲスト間で分割したり、ホストとゲストの間で分割したりすることができないことがあります。PCIe ルートポート、スイッチポート、およびブリッジなどのノンエンドポイントのデバイスはホストドライバーから切り離せず、これらはエンドポイントの割り当てを妨げることはありません。
    IOMMU グループ内のデバイスは、virsh nodedev-dumpxml 出力の iommuGroup セクションを使用して判別できます。グループの各メンバーは、別個の「アドレス」フィールドで指定されます。この情報は、以下を使用して sysfs 内に見つけることもできます。
    $ ls /sys/bus/pci/devices/0000:01:00.0/iommu_group/devices/
    この出力の一例を示します。
    0000:01:00.0  0000:01:00.1
    0000.01.00.0 のみをゲストに割り当てるには、ゲストを起動する前に、使用されていないエンドポイントをホストから切り離す必要があります。
    $ virsh nodedev-detach pci_0000_01_00_1
  3. 必要な設定詳細の決定

    設定ファイルで必要な値については、virsh nodedev-dumpxml pci_0000_00_19_0 コマンドの出力を参照します。
    サンプルのデバイスでは、以下の値が使用されています。bus = 0、slot = 25、function = 0。10 進法の設定では、これらの値を使用します。
    bus='0'
    slot='25'
    function='0'
  4. 設定詳細の追加

    仮想マシン名を特定して virsh edit を実行し、<source> セクションにデバイスエントリーを追加し、PCI デバイスをゲスト仮想マシンに割り当てます。
    # virsh edit guest1-rhel6-64
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
         <address domain='0' bus='0' slot='25' function='0'/>
      </source>
    </hostdev>
    または、仮想マシン名とゲストの XML ファイルを特定して virsh attach-device を実行します。
    virsh attach-device guest1-rhel6-64 file.xml
  5. 仮想マシンの開始

    # virsh start guest1-rhel6-64
これで PCI デバイスは正しく仮想マシンに割り当てられ、ゲストオペレーティングシステムにアクセスできます。

10.1.2. virt-manager を使用した PCI デバイスの割り当て

PCI デバイスは、グラフィカルな virt-manager ツールを使ってゲスト仮想マシンに追加することができます。以下の手順では、Gigabit イーサネットコントローラーをゲスト仮想マシンに追加します。

手順10.4 virt-manager を使用した PCI デバイスのゲスト仮想マシンへの割り当て

  1. ハードウェア設定を開く

    ゲスト仮想マシンを開き、ハードウェアを追加 ボタンをクリックして新規デバイスを仮想マシンに追加します。
    The virtual machine hardware window with the Information button selected on the top taskbar and Overview selected on the left menu pane.

    図10.1 仮想マシンのハードウェア情報ウィンドウ

  2. PCI デバイスの選択

    左側の ハードウェア リストから PCI Host Device を選択します。
    未使用の PCI デバイスを選択します。別のゲストが使用している PCI デバイスを選択する場合、エラーが発生する可能性があります。以下の例では、予備の 82576 ネットワークデバイスが使用されます。完了 をクリックしてセットアップを終了します。
    The Add new virtual hardware wizard with PCI Host Device selected on the left menu pane, showing a list of host devices for selection in the right menu pane.

    図10.2 新たな仮想ハードウェア追加ウィザード

  3. 新規デバイスの追加

    セットアップが完了し、ゲスト仮想マシンはこれで PCI デバイスに直接アクセスできます。
    The virtual machine hardware window with the Information button selected on the top taskbar and Overview selected on the left menu pane, displaying the newly added PCI Device in the list of virtual machine devices in the left menu pane.

    図10.3 仮想マシンのハードウェア情報ウィンドウ

注記

デバイスの割り当てに失敗する場合、ホストに依然としてアタッチされている他のエンドポイントが同じ IOMMU グループ内にある可能性があります。virt-manager を使用してグループ情報を検索する方法はありませんが、virsh コマンドを使用して、IOMMU グループの範囲を分析し、必要な場合はデバイスを分離することができます。
IOMMU グループについての詳細および virsh を使用したエンドポイントデバイスを切り離す方法については、「virsh を使用した PCI デバイスの割り当て」注記 を参照してください。

10.1.3. virt-install を使用した PCI デバイスの割り当て

virt-install を使用して PCI デバイスを割り当てるには、--host-device パラメーターを使います。

手順10.5 virt-install を使用したゲスト仮想マシンへのPCI デバイス割り当て

  1. デバイスの特定

    ゲスト仮想マシンへのデバイス割り当てに指定されているPCI デバイスを特定します。
    # lspci | grep Ethernet
    00:19.0 Ethernet controller: Intel Corporation 82567LM-2 Gigabit Network Connection
    01:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    01:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    virsh nodedev-list コマンドがシステムにアタッチされている全デバイスを一覧表示し、各 PCI デバイスを文字列で特定します。出力を PCI デバイスに限定するには、以下のコマンドを実行します。
    # virsh nodedev-list --cap pci
    pci_0000_00_00_0
    pci_0000_00_01_0
    pci_0000_00_03_0
    pci_0000_00_07_0
    pci_0000_00_10_0
    pci_0000_00_10_1
    pci_0000_00_14_0
    pci_0000_00_14_1
    pci_0000_00_14_2
    pci_0000_00_14_3
    pci_0000_00_19_0
    pci_0000_00_1a_0
    pci_0000_00_1a_1
    pci_0000_00_1a_2
    pci_0000_00_1a_7
    pci_0000_00_1b_0
    pci_0000_00_1c_0
    pci_0000_00_1c_1
    pci_0000_00_1c_4
    pci_0000_00_1d_0
    pci_0000_00_1d_1
    pci_0000_00_1d_2
    pci_0000_00_1d_7
    pci_0000_00_1e_0
    pci_0000_00_1f_0
    pci_0000_00_1f_2
    pci_0000_00_1f_3
    pci_0000_01_00_0
    pci_0000_01_00_1
    pci_0000_02_00_0
    pci_0000_02_00_1
    pci_0000_06_00_0
    pci_0000_07_02_0
    pci_0000_07_03_0
    PCI デバイス番号は他のステップで必要になるので、その番号を書き留めます。
    ドメインやバスおよび機能の情報は、virsh nodedev-dumpxml コマンドからの出力を参照することができます。
    # virsh nodedev-dumpxml pci_0000_01_00_0
    <device>
      <name>pci_0000_01_00_0</name>
      <parent>pci_0000_00_01_0</parent>
      <driver>
        <name>igb</name>
      </driver>
      <capability type='pci'>
        <domain>0</domain>
        <bus>1</bus>
        <slot>0</slot>
        <function>0</function>
        <product id='0x10c9'>82576 Gigabit Network Connection</product>
        <vendor id='0x8086'>Intel Corporation</vendor>
        <iommuGroup number='7'>
          <address domain='0x0000' bus='0x00' slot='0x19' function='0x0'/>
        </iommuGroup>
      </capability>
    </device>

    注記

    IOMMU グループに複数のエンドポイントがあり、それらのすべてがゲストに割り当てられている訳ではない場合、ゲストを起動する前に以下のコマンドを実行して、他のエンドポイントをホストから手動で切り離す必要があります。
    $ virsh nodedev-detach pci_0000_00_19_1
    IOMMU グループの詳細は、「virsh を使用した PCI デバイスの割り当て」注記 を参照してください。
  2. デバイスの追加

    virsh nodedev コマンドからの PCI 識別子の出力を --host-device パラメーターの値として使います。
    virt-install \
    --name=guest1-rhel6-64 \
    --disk path=/var/lib/libvirt/images/guest1-rhel6-64.img,size=8 \
    --nonsparse --graphics spice \
    --vcpus=2 --ram=2048 \
    --location=http://example1.com/installation_tree/RHEL6.0-Server-x86_64/os \
    --nonetworks \
    --os-type=linux \
    --os-variant=rhel6
    --host-device=pci_0000_01_00_0
  3. インストールの完了

    これでゲストインストールが完了しました。PCI デバイスはゲストに割り当てられています。

10.1.4. 割り当てた PCI デバイスの切り離し

ホストの PCI デバイスがゲストマシンに割り当てられると、ホストはこのデバイスを使用できなくなります。このセクションでは、virsh または virt-manager を使ってデバイスをゲストから切り離す方法を説明します。これによって、ホストがデバイスを使えるようになります。

手順10.6 virsh を使用した PCI デバイスのゲストからの切り離し

  1. デバイスの切り離し

    以下のコマンドを使ってゲストの XML ファイル内から PCI デバイスを削除することで、ゲストから PCI デバイスを切り離します。
    # virsh detach-device name_of_guest file.xml
  2. デバイスのホストへの再割り当て (オプション)

    デバイスが managed モードの場合は、このステップを飛ばします。デバイスは自動的にホストに戻ります。
    デバイスが managed モードでない場合は、以下のコマンドを使用して PCI デバイスをホストマシンに再度割り当てます。
    # virsh nodedev-reattach device
    たとえば、pci_0000_01_00_0 デバイスをホストに再度割り当てるには、以下のようにします。
    virsh nodedev-reattach pci_0000_01_00_0
    これでこのデバイスはホストで使用できます。

手順10.7 virt-manager を使用した PCI デバイスのゲストからの切り離し

  1. 仮想ハードウェアの詳細ウィンドウを開く

    virt-manager で、対象のデバイスを含む仮想マシンをダブルクリックします。仮想ハードウェアの詳細表示 ボタンを選択し、仮想ハードウェアのリストを表示させます。
    The Show virtual hardware details button.

    図10.4 仮想ハードウェア詳細ボタン

  2. デバイスの選択および削除

    左パネルの仮想デバイスリストから切り離す PCI デバイスを選択します。
    The PCI device details and the Remove button.

    図10.5 切り離す PCI デバイスの選択

    削除 ボタンをクリックします。これでデバイスがホストで使用可能になります。

10.1.5. PCI ブリッジの作成

PCI (Peripheral Component Interconnect) ブリッジは、ネットワークカード、モデムおよび音声カードなどのデバイスに割り当てるために使用されます。物理デバイスと同様に、仮想デバイスも PCI ブリッジに割り当てることができます。かつてゲスト仮想マシンに追加できる PCI デバイスの数は 31 のみでした。現在では、31 番目の PCI デバイスが追加されると、PCI ブリッジが自動的に 31 番目のスロットに配置され、追加の PCI デバイスはその PCI ブリッジに移行します。それぞれの PCI ブリッジには、追加の 31 デバイスに対応する 31 のスロットがあり、それらすべてをブリッジにすることができます。この方法で、900 を超えるデバイスをゲスト仮想マシンで利用可能にすることができます。

注記

このアクションは、ゲスト仮想マシンが実行中の場合は実行することができません。シャットダウンされているゲスト仮想マシンに PCI デバイスを追加する必要があります。

10.1.6. PCI パススルー

PCI ネットワーク (<source> 要素で指定される) は、汎用デバイスの パススルー を使用してゲストに直接割り当てられます。これは、最初にオプションとしてデバイスの MAC アドレスを設定済みの値に設定し、デバイスをオプションで指定した <virtualport> 要素を使用して 802.1Qbh 対応スイッチに関連付けた後に行なわれます (上記の type='direct' ネットワークデバイスに指定された virtualport の例を参照)。標準の単一ポート PCI イーサネットカードドライバーの設計上の制限により、この方法で割り当てられるのは、SR-IOV (シングルルート I/O 仮想化) の仮想機能 (VF) デバイスのみになります。標準の単一ポート PCI または PCIe イーサネットカードをゲストに割り当てるには、従来の <hostdev> デバイスの定義を使用します。
従来のレガシーの KVM デバイス割り当てではなく、VFIO デバイス割り当てを使用するには (VFIO は、UEFI Secure Boot と互換性のあるデバイス割り当ての新しい方法です)、<type='hostdev'> インターフェースに、name 属性を「vfio」に設定してオプションの driver サブ要素を持たせることができます (または、<driver='kvm'> が現在デフォルトになっているため、<driver> 要素を単純に省略することもできます)。

注記

ネットワークデバイスのインテリジェントパススルーは、標準の <hostdev> デバイスと非常によく似ています。違いは、この方法では パススルーデバイスの MAC アドレスと <virtualport> を指定できる点にあります。これらの機能が不要な場合で、標準の単一ポート PCI、PCIe、または SR-IOV をサポートしない (それゆえゲストドメインへの割り当て後のリセット時に設定済み MAC アドレスが失われる) USB ネットワークがあるか、または 0.9.11 より古いバージョンの libvirt を使用している場合は、デバイスをゲストに割り当てるのに、<interface type='hostdev'/> の代わりに標準の <hostdev> を使用する必要があります。

     <devices>
    <interface type='hostdev'>
      <driver name='vfio'/>
      <source>
        <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
      </source>
      <mac address='52:54:00:6d:90:02'>
      <virtualport type='802.1Qbh'>
        <parameters profileid='finance'/>
      </virtualport>
    </interface>
  </devices>

図10.6 PCI デバイス割り当ての XML サンプル

10.1.7. SR-IOV デバイスの場合の PCI 割り当て (パススルー) の設定

このセクションは、SR-IOV デバイスのみを対象とします。SR-IOV ネットワークカードは、複数の 仮想機能 (VF) を提供します。これらの仮想機能は、それぞれ PCI デバイス割り当てを使用してゲスト仮想マシンに割り当てることができます。いったん割り当てられると、それぞれの仮想機能は完全物理ネットワークデバイスのように機能します。これにより、多くのゲスト仮想マシンが、ホスト物理マシン上で単一スロットのみを使用していても、直接の PCI デバイス割り当てによるパフォーマンス上の利点を得られます。
これらの仮想機能 (VF) は、要素 <hostdev> を使用して従来の方法によりゲスト仮想マシンに割り当てられますが、SR-IOV VF ネットワークデバイスには永続的な固有の MAC アドレスがないため、ホスト物理マシンが再起動されるたびにゲスト仮想マシンのネットワーク設定を再設定する必要があるという問題が生じます。この問題を修復するには、VF をホスト物理マシンに割り当てる前に MAC アドレスを設定する必要があり、この設定はゲスト仮想マシンの起動時に毎回行う必要があります。他のオプションと同様にこの MAC アドレスを割り当てるには、以下で説明されている手順を参照してください: 手順10.8「SR-IOV での PCI デバイス割り当てのための MAC アドレス、vLAN、および仮想ポートの設定」

手順10.8 SR-IOV での PCI デバイス割り当てのための MAC アドレス、vLAN、および仮想ポートの設定

まず、<hostdev> 要素は、MAC アドレス割り当て、vLAN タグ ID 割り当て、または仮想ポートの割り当てなどの機能固有のアイテムに使用することはできないことに留意してください。その理由は、<mac><vlan>、および <virtualport> 要素は <hostdev> の有効な子ではないからです。それらは <interface> で有効であるため、新規インターフェースタイプのサポートが追加されました (<interface type='hostdev'>)。この新規インターフェースのデバイスタイプは <interface><hostdev> のハイブリッドとして機能します。そのため、PCI デバイスをゲスト仮想マシンに割り当てる前に、libvirt は、ゲスト仮想マシンの XML 設定ファイルに示されるネットワーク固有のハードウェアまたはスイッチ (MAC アドレスの設定、vLAN タグの設定、および/または 802.1Qbh スイッチとの関連付け) を初期化します。vLAN タグの設定についての情報は、「vLAN タグの設定」 を参照してください。
  1. ゲスト仮想マシンをシャットダウンします。

    virsh shutdown コマンド (「ゲスト仮想マシンのシャットダウン」 を参照) を使用して、guestVM という名前のゲスト仮想マシンをシャットダウンします。
    # virsh shutdown guestVM
  2. 情報を収集します。

    <interface type='hostdev'> を使用するには、SR-IOV 対応ネットワークカード、また Intel VT-d または AMD IOMMU 拡張のいずれかをサポートするホスト物理マシンハードウェアが必要であり、割り当てる VF の PCI アドレスを知っておく必要があります。
  3. XML ファイルを開いて編集します。

    編集する XML ファイルを開くには、# virsh save-image-edit コマンドを実行します (詳細は、「ドメイン XML 設定ファイルの編集」 を参照してください)。ゲスト仮想マシンを以前の実行状態に戻したい場合は、--running を使用できます。この例の設定ファイルの名前は、ゲスト仮想マシンの名前が guestVM なので guestVM.xml になります。
     # virsh save-image-edit guestVM.xml --running 
    ユーザーのデフォルトエディターで guestVM.xml が開かれます。
  4. XML ファイルを編集します。

    以下のような <devices> エントリーを持たせるように設定ファイル (guestVM.xml) を更新します。
    
     <devices>
       ...
       <interface type='hostdev' managed='yes'>
         <source>
           <address type='pci' domain='0x0' bus='0x00' slot='0x07' function='0x0'/> <!--these values can be decimal as well-->
         </source>
         <mac address='52:54:00:6d:90:02'/>                                         <!--sets the mac address-->
         <virtualport type='802.1Qbh'>                                              <!--sets the virtual port for the 802.1Qbh switch-->
           <parameters profileid='finance'/>
         </virtualport>
         <vlan>                                                                     <!--sets the vlan tag-->
          <tag id='42'/>
         </vlan>
       </interface>
       ...
     </devices>

    図10.7 hostdev interface type のドメイン XML のサンプル

    MAC アドレスを指定しない場合、それ以外のタイプのインターフェースデバイスと同様に、そのアドレスは自動的に生成されます。さらに、<virtualport> 要素は、802.11Qgh ハードウェアスイッチ (802.11Qbg (別名「VEPA」) に接続される場合にのみ使用されます。これらのスイッチは現在サポートされていません。
  5. ゲスト仮想マシンを再起動します。

    最初のステップでシャットダウンしたゲスト仮想マシンを再開するために virsh start コマンドを実行します (例では、ゲスト仮想マシンのドメイン名として guestVM を使用しています)。詳細は、「定義されたドメインの起動」 を参照してください。
     # virsh start guestVM 
    ゲスト仮想マシンが起動すると、設定済みの MAC アドレスと共に、物理ホストマシンのアダプターによって指定されたネットワークデバイスが表示されます。この MAC アドレスは、ゲスト仮想マシンと物理ホストマシンの起動時に変更されることはありません。

10.1.8. SR-IOV 仮想機能のプールから PCI デバイス割り当てを設定する

特定の 仮想機能 (VF) の PCI アドレスをゲストの設定にハードコーディングする上で、2 つの重大な制限があります。
  • 指定した VF は、ゲスト仮想マシンの起動時にはいつでも利用可能な状態でなければなりません。つまり、これは管理者が単一のゲスト仮想マシンに対してそれぞれの VF を永久的に割り当てなければならないことを意味しています (またはそれぞれのゲスト仮想マシンの起動時に、現在使用されていない VF の PCI アドレスを指定するためにすべてのゲスト仮想マシンの設定ファイルを修正する必要があります)。
  • ゲスト仮想マシンが別のホスト物理マシンに移行する場合、そのホスト物理マシンには、PCI バス上の同じ場所に全く全く同じハードウェアがなければなりません (または、ここでも起動前にゲスト仮想マシンの設定を変更する必要があります)。
これらの問題は、いずれも SR-IOV デバイスのすべての VF を含むデバイスプールと共に libvirt ネットワークを作成することによって回避することができます。いったんこれが実行されると、このネットワークを参照するようにゲスト仮想マシンを設定できます。ゲストが起動するたびに、単一の VF がプールからゲスト仮想マシンに割り当てられます。ゲスト仮想マシンが停止すると、VF は別のゲスト仮想マシンが使用できるようにのプールに戻ります。

手順10.9 デバイスプールの作成

  1. ゲスト仮想マシンをシャットダウンします。

    virsh shutdown コマンド (「ゲスト仮想マシンのシャットダウン、再起動および強制終了」 を参照) を使用して、guestVM という名前のゲスト仮想マシンをシャットダウンします。
    # virsh shutdown guestVM
  2. 設定ファイルの作成

    任意のエディターを使用して、/tmp ディレクトリーに XML ファイル (例:passthrough.xml という名前のファイル) を作成します。pf dev='eth3' は、各自の SR-IOV デバイスの物理機能 (PF) に置き換えるようにしてください。
    以下は、物理機能 (PF) がホスト物理マシンの「eth3」に設定された、SR-IOV アダプターのすべての VF のプールを利用可能にするネットワーク定義のサンプルです。
                
    <network>
       <name>passthrough</name>                                                <!--This is the name of the file you created-->
       <forward mode='hostdev' managed='yes'>
         <pf dev='myNetDevName'/>                                              <!--Use the netdev name of your SR-IOV devices PF here-->
       </forward>
    </network>
    

    図10.8 ネットワーク定義ドメインの サンプル XML

  3. 新しい XML ファイルをロードします。

    /tmp/passthrough.xml を直前のステップで作成した XML ファイルの名前と場所に置き換え、以下のコマンドを実行します。
    # virsh net-define /tmp/passthrough.xml
  4. ゲストの再起動

    passthrough.xml を直前のステップで作成した XML ファイルの名前に置き換え、以下を実行します。
     # virsh net-autostart passthrough # virsh net-start passthrough 
  5. ゲスト仮想マシンを再起動します。

    最初のステップでシャットダウンしたゲスト仮想マシンを再開するために virsh start コマンドを実行します (例では、ゲスト仮想マシンのドメイン名として guestVM を使用しています)。詳細は、「定義されたドメインの起動」 を参照してください。
     # virsh start guestVM 
  6. デバイスのパススルーの開始

    単一デバイスのみが表示されていますが、libvirt は、ゲスト仮想マシンの初回起動時に、PF に関連付けられたすべての VF の一覧を自動的に派生させます。この起動には、以下のようなドメイン XML 内のインターフェース定義が使用されます。
             
    <interface type='network'>
       <source network='passthrough'>
    </interface>
    

    図10.9 インターフェースネットワーク定義のサンプルドメイン XML

  7. 検証

    検証は、ネットワークを使用する最初のゲストの起動後に virsh net-dumpxml passthrough コマンドで実行できます。以下のような出力が得られます。
          
    <network connections='1'>
       <name>passthrough</name>
       <uuid>a6b49429-d353-d7ad-3185-4451cc786437</uuid>
       <forward mode='hostdev' managed='yes'>
         <pf dev='eth3'/>
         <address type='pci' domain='0x0000' bus='0x02' slot='0x10' function='0x1'/>
         <address type='pci' domain='0x0000' bus='0x02' slot='0x10' function='0x3'/>
         <address type='pci' domain='0x0000' bus='0x02' slot='0x10' function='0x5'/>
         <address type='pci' domain='0x0000' bus='0x02' slot='0x10' function='0x7'/>
         <address type='pci' domain='0x0000' bus='0x02' slot='0x11' function='0x1'/>
         <address type='pci' domain='0x0000' bus='0x02' slot='0x11' function='0x3'/>
         <address type='pci' domain='0x0000' bus='0x02' slot='0x11' function='0x5'/>
       </forward>
    </network>
    

    図10.10 XML ダンプファイル passthrough の内容

10.2. USB デバイス

このセクションでは、USB デバイスの処理に必要なコマンドを扱います。

10.2.1. ゲスト仮想マシンへの USB デバイスの割り当て

web カメラ、カードリーダー、キーボード、マウスなどのほとんどのデバイスは、USB ポートとケーブルを使ってコンピューターに接続されます。これらのデバイスをゲスト仮想マシンに渡す方法として 2 つの方法があります。
  • USB パススルーの使用 - これには、ゲスト仮想マシンをホストしているホスト物理マシンに、デバイスを物理的に接続している必要があります。この場合、SPICE は必要ではありません。ホスト上の USB デバイスは、コマンドラインまたは virt-manager を使用してゲストに渡すことができます。virt manager の指示については、「USB デバイスをゲスト仮想マシンに割り当てる」 を参照してください。

    注記

    virt-manager は、ホットプラグまたはホットアンプラグデバイスで使用することはできません。USB デバイスのホットプラグまたはホットアンプラグが必要な場合は、手順15.1「ゲスト仮想マシンが使用する USB デバイスのホットプラグ」 を参照してください。
  • USB リダイレクトの使用 - USB リダイレクトは、ホスト物理マシンがデータセンターで実行されている場合に最適に使用されます。ユーザーは、ローカルマシンまたはシンクライアントからゲスト仮想マシンに接続します。このローカルマシンには、1 つの SPICE クライアントがあります。ユーザーは、任意の USB デバイスをシンクライアントに割り当てることができ、SPICE クライアントはデータセンターのホスト物理マシンにこのデバイスをリダイレクトするので、これをシンクライアント上で実行されているゲスト仮想マシンで使用することができます。virt-manager を使用した USB リダイレクトについての説明は、「USB デバイスをゲスト仮想マシンに割り当てる」を参照してください。USB リダイレクトは、TCP プロトコルを使用して実行することができないことに注意してください (BZ#1085318 を参照してください)。

10.2.2. USB デバイスのリダイレクトに制限を設ける

フィルターを使って特定のデバイスをリダイレクトの対象から外すには、フィルタープロパティーを -device usb-redir に渡します。フィルタープロパティーはフィルタールールで構成される文字列を取ります。ルールの形式は次の通りです。
<class>:<vendor>:<product>:<version>:<allow>
-1 を使用すると、特定フィールドで任意の値を受け入れるように指定できます。| を区切りに使用することにより、同じコマンドラインで複数のルールを使用することができます。

重要

デバイスがルールフィルターのいずれにも一致しない場合、これをリダイレクトすることができません。

例10.1 Windows ゲスト仮想マシンに関するリダイレクトの制限を設ける場合の例

  1. Windows 7 ゲスト仮想マシンを用意します。
  2. 次のコードの抜粋をゲスト仮想マシンのドメイン XML ファイルに追加します。
        <redirdev bus='usb' type='spicevmc'>
          <alias name='redir0'/>
          <address type='usb' bus='0' port='3'/>
        </redirdev>
        <redirfilter>
          <usbdev class='0x08' vendor='0x1234' product='0xBEEF' version='2.0' allow='yes'/>
          <usbdev class='-1' vendor='-1' product='-1' version='-1' allow='no'/>
        </redirfilter>
  3. ゲスト仮想マシンを起動し、次のコマンドを実行して設定の変更を確認します。
    #ps -ef | grep $guest_name
    -device usb-redir,chardev=charredir0,id=redir0,/
    filter=0x08:0x1234:0xBEEF:0x0200:1|-1:-1:-1:-1:0,bus=usb.0,port=3
  4. USB デバイスをホスト物理マシンに挿入し、virt-manager を使ってゲスト仮想マシンに接続します。
  5. メニュー内の Redirect USB Service をクリックします。これにより、「Some USB devices are blocked by host policy」というメッセージが生成されます。OK をクリックして確認し、続行します。
    フィルターが適用されます。
  6. フィルターよるキャプチャーが正しく動作するよう USB デバイスの製造元と製品を確認し、USB リダイレクトが可能になるよう、ゲスト仮想マシンのドメイン XML に次の変更を加えます。
       <redirfilter>
          <usbdev class='0x08' vendor='0x0951' product='0x1625' version='2.0' allow='yes'/>
          <usbdev allow='no'/>
        </redirfilter>
  7. ゲスト仮想マシンを再起動し、virt-viewer を使ってゲスト仮想マシンに接続します。USB デバイスがトラフィックをゲスト仮想マシンにリダイレクトするようになります。

10.3. デバイスコントローラーの設定

ゲスト仮想マシンのアーキテクチャーにより、一部のデバイスバスは、仮想コントローラーに関連付けられた仮想デバイスのグループと共に、複数回表示されることがあります。通常、libvirt は、明示的な XML マークアツプを必要とせずに、このようなコントローラーを自動的に推定できますが、仮想コントローラーの要素を明示的に設定した方がよい場合があります。

  ...
  <devices>
    <controller type='ide' index='0'/>
    <controller type='virtio-serial' index='0' ports='16' vectors='4'/>
    <controller type='virtio-serial' index='1'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </controller>
    ...
  </devices>
  ...

図10.11 仮想コントローラーのドメイン XML サンプル

各コントローラーには必須属性 <controller type> があります。これは、以下のいずかである必要があります。
  • ide
  • fdc
  • scsi
  • sata
  • usb
  • ccid
  • virtio-serial
  • pci
<controller> 要素には、(<address> 要素の controller 属性で使用される) バスコントローラーが出現する順序を記述する 10 進整数の必須属性 <controller index> があります。<controller type ='virtio-serial'> の場合、コントローラー経由で接続できるデバイスの数を制御する 2 つの追加のオプション属性 (portsvectors という名前) があります。Red Hat Enterprise Linux 6 では、デバイスにつき 32 vectors の使用までしかサポートされないことに注意してください。これ以上の vectors を使用すると、ゲスト仮想マシンの移行が失敗します。
<controller type ='scsi'> の場合、以下の値を取ることのできるオプション属性 model モデルがあります。
  • auto
  • buslogic
  • ibmvscsi
  • lsilogic
  • lsisas1068
  • lsisas1078
  • virtio-scsi
  • vmpvscsi
<controller type ='usb'> の場合、次の値を取ることのできるオプション属性 model モデルがあります。
  • piix3-uhci
  • piix4-uhci
  • ehci
  • ich9-ehci1
  • ich9-uhci1
  • ich9-uhci2
  • ich9-uhci3
  • vt82c686b-uhci
  • pci-ohci
  • nec-xhci

注記

USB バスをゲスト仮想マシンに対して明示的に無効にする必要がある場合は、<model='none'> を使用することができます。
コントローラー自体が PCI または USB バス上のデバイスである場合、オプションのサブ要素 <address> は、「デバイスのアドレス設定」 に示される形式を使用して、コントローラーとマスターバスとの正確な関係を指定することができます。
オプションのサブ属性 <driver> は、ドライバー固有のオプションを指定することができます。現在、これはコントローラーのキューの数を指定する属性 queues のみをサポートします。パフォーマンスを最大化するには、vCPU の数に一致する値を指定することが推奨されます。
USB コンパニオンコントローラーには、コンパニオンとマスターコントローラーとの正確な関係を指定するためのオプションのサブ要素 <master> があります。コンパニオンコントローラーは、そのマスターと同じバスにあり、コンパニオンの index 値は等しくなければなりません。
使用できる XML の例を示します。
   
     ...
  <devices>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0' bus='0' slot='4' function='7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0' bus='0' slot='4' function='0' multifunction='on'/>
    </controller>
    ...
  </devices>
  ...

図10.12 USB コントローラーのドメイン XML サンプル

PCI コントローラーには、以下の値を持てるオプションの model 属性があります。
  • pci-root
  • pcie-root
  • pci-bridge
  • dmi-to-pci-bridge
root コントローラー (pci-rootpcie-root) には、オプションの pcihole64 要素があります。この要素は、64 ビット PCI ホールのサイズを指定します (キロバイト単位、または pcihole64unit 属性で指定される単位)。一部のゲスト仮想マシン ( Windows Server 2003 など) は、unit が無効に (0 に設定: unit='0') されない場合、クラッシュを生じさせる可能性があります。
暗黙的な PCI バスを提供するマシンタイプの場合、index='0' が指定された pci-root コントローラーは自動的に追加され、PCI デバイスを使用するために必要になります。pci-root にはアドレスがありません。PCI ブリッジは、デバイスの数が多すぎて model='pci-root' で指定される 1 つのバスに入らない場合や、ゼロより大きい PCI バスの数が指定されている場合に自動的に追加されます。さらに、PCI ブリッジを手動で指定することができますが、それらのアドレスは、すでに指定された PCI コントローラーによって提供される PCI バスのみを参照するものである必要があります。PCI コントローラーの index にギャップがあると、設定が無効になる可能性があります。以下の XML サンプルを <devices> セクションに追加することができます。

  ...
  <devices>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='pci' index='1' model='pci-bridge'>
      <address type='pci' domain='0' bus='0' slot='5' function='0' multifunction='off'/>
    </controller>
  </devices>
  ...

図10.13 PCI ブリッジのドメイン XML サンプル

暗黙的な PCI Express (PCIe) バスを提供するマシンタイプ (たとえば、Q35 チップセットに基づくマシンタイプ) の場合、index='0' が指定された pcie-root コントローラーがドメインの設定に自動的に追加されます。さらに、pcie-root にはアドレスがありませんが、31 スロット (1-31 までの番号) を提供し、PCIe デバイスを割り当てるためにのみ使用できます。pcie-root コントローラーを持つシステムの標準 PCI デバイスを接続するために、model='dmi-to-pci-bridge' が設定された pci コントローラーが自動的に追加されます。dmi-to-pci-bridge コントローラーは PCIe スロット (pcie-root によって提供される) にプラグインされ、それ自体は 31 の標準 PCI スロット (ホットプラグ不可能) を提供します。ホットプラグ可能な PCI スロットをゲストシステム内で使用するには、pci-bridge コントローラーが自動的に作成され、自動作成される dmi-to-pci-bridge コントローラーのスロットの 1 つに接続され、libvirt で自動判別される PCI アドレスを持つすべてのゲストデバイスが、この pci-bridge デバイス上に置かれます。
   
     ...
  <devices>
    <controller type='pci' index='0' model='pcie-root'/>
    <controller type='pci' index='1' model='dmi-to-pci-bridge'>
      <address type='pci' domain='0' bus='0' slot='0xe' function='0'/>
    </controller>
    <controller type='pci' index='2' model='pci-bridge'>
      <address type='pci' domain='0' bus='1' slot='1' function='0'/>
    </controller>
  </devices>
  ...

図10.14 PCIe (PCI express) のドメイン XML サンプル

10.4. デバイスのアドレス設定

多くのデバイスには、ゲスト仮想マシンに提示されるデバイスが仮想バス上のどこに配置されるかを説明するオプションの <address> サブ要素があります。アドレス (またはアドレス内のオプション属性) が入力で省略されている場合、libvirt は適切なアドレスを生成しますが、レイアウトにより多くの制御が必要な場合は明示的なアドレスが必要になります。<address> 要素を含むドメイン XML のデバイスサンプルについては、図10.6「PCI デバイス割り当ての XML サンプル」 を参照してください。
すべてのアドレスには、デバイスが置かれるバスを記述する必須の属性 type があります。指定されるデバイスに使用するアドレスを選択することは、デバイスおよびゲスト仮想マシンのアーキテクチャーによって部分的に制限されます。たとえば、<ディスク> デバイスは type='drive' を使用し、<コンソール> デバイスは、i686 または x86_64 ゲスト仮想マシンのアーキテクチャーで type='pci' を使用します。さらに、各アドレスの type には、表で説明されるように、バス上のデバイスの配置される場所を制御するオプションの属性があります。

表10.1 サポートされているデバイスアドレスのタイプ

アドレスタイプ説明
type='pci'PCI アドレスには以下の追加属性があります。
  • domain (2 バイトの 16 進整数。 現在は qemu によって使用されていません)
  • bus (0 から 0xff までの 16 進値)
  • slot (0x0 から 0x1f までの 16 進値)
  • function (0 から 7 までの値)
  • multifunction は、PCI コントロールレジスターに特定のスロット/機能のマルチファンクションビットをオンにするように制御します。この属性は、デフォルトで 'off' になりますが、マルチファンクションが使用されるスロットのファンクション 0 では 'on' に設定する必要があります。
type='drive'ドライブアドレスには、以下の追加属性があります。
  • controller (2 桁のコントローラー番号)
  • bus (2 桁のバス番号)
  • target (2 桁のバス番号)
  • unit (バス上の 2 桁のユニット番号)
type='virtio-serial'それぞれの virtio-serial アドレスには以下の追加属性があります。
  • controller (2 桁のコントローラー番号)
  • bus (2 桁のバス番号)
  • slot (バス内の 2 桁のスロット)
type='ccid'スマートカードに使用される CCID アドレスには、以下の追加属性があります。
  • bus (2 桁のバス番号)
  • slot 属性 (バス内の 2 桁のスロット)
type='usb'USB アドレスには以下の追加属性があります。
  • bus (0 から 0xfff までの 16 進数)
  • port (1.2 または 2.1.3.1 などの最高 4 つのオクテットからなるドット区切りの表記)
type='isa'ISA アドレスには以下の追加属性があります。
  • iobase
  • irq

10.5. ゲスト仮想マシンのストレージコントローラーの管理

Red Hat Enterprise Linux 6.4 より、Red Hat Enterprise Linux 6.4 以降を実行するゲスト仮想マシンに SCSI と virtio-SCSI デバイスが追加することがサポートされています。virtio ディスクとは異なり、SCSI デバイスには、ゲスト仮想マシン内にコントローラーが存在することが求められます。Virtio-SCSI は、SCSI LUN に直接接続する機能を提供し、virtio-blk と比較するとスケーラビリティーが改善されています。virtio-SCSI の利点は、28 デバイスしか処理できず、PCI スロットを使い果たす virtio-blk とは異なり、数百のデバイスを処理できる点にあります。Virtio-SCSI は、以下の機能を使ってターゲットデバイスの機能セットを継承することを可能にします。
  • virtio-scsi コントローラーを介して仮想ハードドライブまたは CD を割り当てる
  • QEMU scsi-block デバイスを介して物理 SCSI デバイスをホストからゲストにパススルーする
  • 28-デバイスの制限のある virtio-blk とは異なり、1 ゲストごとに数百のデバイスの使用を可能にする
このセクションでは、仮想 SCSI コントローラー (別名 "ホストバスアダプター": HBA) を作成し、ゲスト仮想マシンに SCSI ストレージを追加するために必要なステップを詳しく説明します。

手順10.10 仮想 SCSI コントローラーを作成する

  1. ゲスト仮想マシン (Guest1) の設定を表示して、事前に存在している SCSI コントローラーを探します。
    # virsh dumpxml Guest1 | grep controller.*scsi
    デバイスコントローラーが存在する場合は、このコマンドが以下のように一行または複数行の出力を行います。
    <controller type='scsi' model='virtio-scsi' index='0'/>
  2. 先のステップでデバイスコントローラーが表示されない場合、新しいファイルでその 1 つを記述し、それを以下のステップを実行して仮想マシンに追加します。
    1. 新しいファイルに <controller> 要素を書き込むことによってデバイスコントローラーを作成し、このファイルを XML 拡張子を付けて保存します。たとえば、NewHBA.xml のようになります。
      <controller type='scsi' model='virtio-scsi'/>
    2. virtio-scsi-controller.xml で作成したばかりのデバイスコントローラーを使用中のゲスト仮想マシン (例: Guest1) に関連付けます。
      # virsh attach-device --config Guest1 ~/virtio-scsi-controller.xml
      この例では、 --config オプションはディスク接続の場合と同様の動作をします。詳細については 手順14.2「ゲストに物理ブロックデバイスを追加する」 を参照してください。
  3. 新しい SCSI ディスクまたは CD-ROM を追加します。「ゲストにファイルベースのストレージを追加する」「ゲストにハードドライブと他のブロックデバイスを追加する」 のセクションに記載されている方法に従って、新しいディスクを追加します。SCSI ディスクを作成するには、sd で始まるターゲットデバイス名を指定してください。
    # virsh attach-disk Guest1 /var/lib/libvirt/images/FileName.img sdb --cache none
    ゲスト仮想マシン内のドライバーのバージョンによっては、新しいディスクが実行中のゲスト仮想マシンですぐには検出されない場合があります。『Red Hat Enterprise Linux ストレージ管理ガイド』 の手順に従ってください。

10.6. 乱数ジェネレーター (RNG) デバイス

virtio-rng は、RNG データをゲスト仮想マシンのオペレーティングシステムにフィードし、これにより、要求されるとゲスト仮想マシンの新規エントロピーを提供する仮想 RNG (乱数ジェネレーター) デバイスです。
RNG の使用は、キーボード、マウスおよびその他の入力がゲスト仮想マシンのエントロピーを十分に生成しない場合に特に便利です。virtio-rng デバイスは、Red Hat Enterprise Linux と Windows ゲスト仮想マシンの両方で使用できます。Windows 要件のインストールについての説明は、注記 を参照してください。特筆されない限り、以下の説明は、Red Hat Enterprise Linux と Windows ゲスト仮想マシンの両方に当てはまります。
virtio-rng が Linux ゲスト仮想マシンで有効にされると、chardev が /dev/hwrng の場所にあるゲスト仮想マシンに作成されます。次に、この chardev が開かれ、ホスト物理マシンからエントロピーを取得するために読み込まれます。ゲスト仮想マシンのアプリケーションが virtio-rng デバイスの乱数度を透過的に使用することから利点を得られるようにするには、/dev/hwrng からの入力が、ゲスト仮想マシン内のカーネルエントロピープールに中継される必要があります。これは、この場所にある情報が rgnd デーモン (rng-tools 内に格納される) と対で使用される場合に実行できます。
この結合により、エントロピーがゲスト仮想マシンの /dev/random ファイルに経路指定されます。このプロセスは、Red Hat Enterprise Linux 6 ゲスト仮想マシンでは手動で行なわれます。
Red Hat Enterprise Linux 6 ゲスト仮想マシンでは、以下のコマンドを実行して、この結合を行います。
# rngd -b -r /dev/hwrng -o /dev/random
ここに示されるコマンドの説明については、man rngd コマンドを実行してください。追加の例については、virtio-rng デバイスの設定に関する 手順10.11「コマンドラインツールを使用した virtio-rng の実装」 を参照してください。

注記

Windows ゲスト仮想マシンでは、ドライバー viorng がインストールされる必要があります。いったんインストールされると、仮想 RNG デバイスは、Microsoft によって提供される CNG (crypto next generation) API を使用して動作します。ドライバーがインストールされると、virtrng デバイスは RNG プロバイダーの一覧に表示されます。

手順10.11 コマンドラインツールを使用した virtio-rng の実装

  1. ゲスト仮想マシンをシャットダウンします。
  2. ターミナルウィンドウで、virsh edit domain-name コマンドを使用し、必要なゲスト仮想マシンの XML ファイルを開きます。
  3. 以下を含めるように <devices> 要素を編集します。
    
      ...
      <devices>
        <rng model='virtio'>
          <rate period="2000" bytes="1234"/>
          <backend model='random'>/dev/random</backend>
               <source mode='bind' service='1234'>
               <source mode='connect' host='192.0.2.1' service='1234'>
          </backend>
        </rng>
      </devices>
      ...

第11章 QEMU-img および QEMU ゲストエージェント

本章では、qemu-img パッケージを仮想ゲストマシンと共に使用する場合に役立つヒントを紹介します。QEMU トレースイベントおよび引数についての情報が必要な場合には、以下にある README ファイルを参照してください: /usr/share/doc/qemu-*/README.systemtap

11.1. qemu-img の使い方

qemu-img コマンドラインツールは、KVM で使用される各種ファイルシステムの編集や検証、およびフォーマットを行う際に使用されます。qemu-img のオプションとその使い方を以下に示します。
Check

ディスクイメージ filename の整合性チェックを実行します。

#  qemu-img check -f qcow2 --output=qcow2 -r all filename-img.qcow2

注記

qcow2vdi の形式のみが整合性チェックに対応しています。
-r を使用すると、チェック中に発見された不整合の修復を試みますが、-r leaks と使用するとクラスターリークが修復され、-r all と使用するとすべての種類のエラーが修復されます。これには間違ったフィクスを選択したり、既存の破損問題が隠れてしまうなどのリスクがあることに注意してください。
Commit

qemu-img commit コマンドを使って、指定ファイル (filename) に記録される変更をそのファイルのベースイメージにコミットします。オプションでファイルの形式タイプを指定できます (fmt)。

 # qemu-img commit [-f fmt] [-t cache] filename
Convert

認識しているイメージ形式を別のイメージ形式に変換する場合に convert オプションを使用します。

コマンド形式:
# qemu-img convert [-c] [-p] [-f fmt] [-t cache] [-O output_fmt] [-o options] [-S sparse_size] filename output_filename
-p パラメーターは、コマンドの進捗を表示し (オプションのため、すべてのコマンドに使用できる訳ではありません)、-S フラグは、ディスクイメージ内に含まれる スパースファイル の作成を可能にします。スパースファイルは実際上、ゼロのみを含む (つまり何も含まない) 物理ブロックの場合を除き、標準ファイルのように機能します。オペレーティングシステムがこのファイルを発見すると、いずれのディスク領域も使用していないものの、実際に存在し、実際のディスク領域を占めるものとしてこのファイルを処理します。これは、ディスクが実際に存在する以上のディスク領域を使っている様に表示されるため、ゲスト仮想マシンのディスクを作成する際にはとりわけ役に立ちます。たとえば、10Gb のディスクイメージで -S を 50Gb に設定する場合、実際に使用されているのは 10Gb のみであるのにもかかわらず、10Gb のディスク領域のサイズが 60Gb のように表示されます。
output_format 形式を使って、filename ディスクイメージを output_filename ディスクイメージに変換します。-c オプションを使うとディスクイメージをオプションで圧縮することができます。また、-o オプションを使い -o encryption のように設定すると暗号化することができます。-o パラメーターを付けるオプションは複数あり、選択する形式によって異なります。
暗号化や圧縮に対応しているのは qcow2 形式のみになります。qcow2 の暗号化では安全な 128 ビットキーによる AES 形式が使用されます。qcow2 の圧縮は読み取り専用になります。このため、qcow2 形式から圧縮セクターを変換する場合には、このセクターは圧縮されていないデータとして新しい形式に記述されます。
イメージ変換ではイメージを小さくすることができるため、qcowcow などの拡大する可能性のある形式を使用する場合にも便利です。空のセクターは検出されて、目的のイメージから削除されます。
Create

サイズが size、形式が format となる filename という新しいディスクイメージを作成します。

# qemu-img create [-f format] [-o options] filename [size][preallocation]
-o backing_file=filename でベースイメージを指定すると、作成するイメージとベースファイルとの差異のみが記録されることになります。commit コマンドを使用しない限り、バッキングファイルは変更されません。この場合、サイズの指定は必要ありません。
Preallocation は、qcow2 イメージの作成時にのみ使用可能なオプションです。使用可能な値は、-o preallocation=off|meta|full|falloc になります。事前割り当てのメタデータのあるイメージは、これがないものよりもサイズが大きくなります。ただし、イメージサイズが大きくなると、パフォーマンスは向上します。
割り振りで full を使用すると、大きいイメージでは時間がかかることに注意してください。割り振りで full を使用したいものの、時間に余裕がない場合は、falloc を使うと時間が節約できます。
Info

info パラメーターは、filename ディスクイメージの情報を表示します。 info オプションの形式を以下に示します。

# qemu-img info [-f format] filename
このコマンドはディスク上で予約されているサイズを検出する場合によく使用されます。予約サイズは表示サイズとは異なる場合があります。スナップショットがディスクイメージに格納されている場合は、それらも表示されます。このコマンドは、どの程度の領域がブロックデバイス上の qcow2 イメージによって使用されているかを表示します。これは、qemu-img を実行することによって行なわれます。使用中のイメージが qemu-img info コマンドと qemu-img check コマンドの出力に一致するものであることを確認できます。「qemu-img の使い方」を参照してください。
# qemu-img info /dev/vg-90.100-sluo/lv-90-100-sluo
image: /dev/vg-90.100-sluo/lv-90-100-sluo
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 0
cluster_size: 65536
Map

# qemu-img map [-f fmt] [--output=ofmt] filename のコマンドを実行すると、イメージ filename のメタデータとそのバッキングファイルチェーンがダンプされます。特にこのコマンドは、指定されたファイルの全セクターの割り振り状態と、そのファイルをバッキングファイルチェーンに割り振る最上位のファイルをダンプします。たとえば、c.qcow2 → b.qcow2 → a.qcow2 というチェーンがあったとすると、a.qcow がオリジナルファイル、b.qcow2 が a.qcow2 に加えた変更、c.qcow2 が b.qcow2 からの差分ファイルになります。このチェーンが作成される際には、イメージファイルは適切なイメージデータと何がどのファイルに、かつファイルのどこにあるかという情報とともに保存されます。この情報は、イメージのメタデータと呼ばれます。-f の形式オプションは、指定されたイメージファイルの形式です。raw、qcow2、vhdx および vmdk といった形式が使用されます。出力オプションには humanjson の 2 種類があります。

デフォルト設定は human です。これは人間にとって読みやすいものにするので、この形式は解析すべきではありません。プログラムがこれの解析を試みると、悪意のあるゲストイメージに誤った方向に導かれる場合があります。
明確さと簡素化のために、デフォルトの human 形式は、ファイルの既知の非ゼロエリアのみをダンプします。ファイルの既知のゼロ部分と、チェーンで割り振られていない部分はすべて除外されます。このコマンドを実行すると、qemu-img の出力がデータ読み取り可能なファイルと、ファイルないのオフセットを特定します。出力は 4 コラムの表が表示され、そのうちの最初の 3 つは 16 進数になります。
# qemu-img map -f qcow2 --output=human /tmp/test.qcow2 
Offset          Length          Mapped to       File
0               0x20000         0x50000         /tmp/test.qcow2
0x100000        0x80000         0x70000         /tmp/test.qcow2
0x200000        0x1f0000        0xf0000         /tmp/test.qcow2
0x3c00000       0x20000         0x2e0000        /tmp/test.qcow2
0x3fd0000       0x10000         0x300000        /tmp/test.qcow2
json または JSON (JavaScript Object Notation) は人間が読み取ることが可能ですが、プログラミング言語であることから、解析用に設計されています。たとえば、"qemu-img map" の出力をパーサーで解析するには、--output=json というフラグを使用します。
# qemu-img map -f qcow2 --output=json /tmp/test.qcow2 
[{ "start": 0, "length": 131072, "depth": 0, "zero": false, "data": true, "offset": 327680},
{ "start": 131072, "length": 917504, "depth": 0, "zero": true, "data": false},
JSON 形式の詳細情報については、qemu-img の man ページを参照してください。
Rebase

イメージのバッキングファイルを変更します。

# qemu-img rebase [-f fmt] [-t cache] [-p] [-u] -b backing_file [-F backing_fmt] filename
バッキングファイルが backing_file に変更され (filename の形式がこの機能に対応している場合)、バッキングファイルの形式は backing_format に変更されます。

注記

qcow2 形式のみがバッキングファイルの変更 (rebase) に対応します。
rebase の動作には、セーフ モードと アンセーフ モードの 2 種類があります。
デフォルトでは セーフモード が使用され、実際の rebase 動作が行われます。新しいバッキングファイルは古いバッキングファイルとは異なる可能性があるため、qemu-img rebase コマンドではゲスト仮想マシンに表示される filename のコンテンツは変更されないようにします。backing_file と古いバッキングファイルの filename 間の異なる部分は、バッキングファイルに変更が加えられる前に filename にマージされます。
セーフモードはイメージの変換と同様、時間を要する動作になります。正しく動作させるには古いバッキングファイルが必要になります。
qemu-img rebase-u オプションを渡すと アンセーフモード が使用されます。このモードでは、filename のバッキングファイル名と形式のみが変更され、ファイルのコンテンツに対するチェックは行われません。新しいバッキングファイルが正しく指定されていることを必ず確認してください。指定を誤ると、ゲストに表示されるイメージのコンテンツが破損することになります。
このモードはバッキングファイルの名前変更や移動を行う際に便利です。古いバッキングファイルへのアクセスを必要としません。たとえば、バッキングファイルがすでに移動されているか、またはファイルの名前が変更されているイメージの修正などに使用できます。
Resize

size サイズで作成された filename ディスクイメージであるかのようにディスクイメージのサイズ変更を行います。バージョンにかかわらず、サイズ変更が可能なのは raw 形式のイメージのみになります。Red Hat Enterprise Linux 6.1 以降には qcow2 形式のイメージを拡大できる機能が追加されています (縮小は不可)。

filename ディスクイメージのサイズを size バイトに設定する場合は以下のようにします。
# qemu-img resize filename size
ディスクイメージの現在のサイズに対してサイズを増減させることもできます。ディスクイメージのサイズを大きくする場合はバイト数の前に + を付け、小さくする場合はバイト数の前に - を付けます。単位の接尾辞を付けると、キロバイト (K)、メガバイト (M)、ギガバイト (G)、またはテラバイト (T) などの単位でイメージサイズを設定することができます。
# qemu-img resize filename [+|-]size[K|M|G|T]

警告

このコマンドを使ってディスクのイメージを小さくする場合はその前に、仮想マシン自体のファイルシステムとパーティション設定のツールを使用して、割り当てられているファイルシステムとパーティションのサイズをそれぞれ小さくしておく 必要があります。先にこれを行わないとデータを喪失することになります。
このコマンドを使ってディスクのイメージを拡大した後に、仮想マシン自体のファイルシステムとパーティション設定のツールを使用して、そのデバイス上で新しい領域を実際に使用し始める必要があります。
Snapshot

イメージ (filename) の既存のスナップショット (snapshot) の一覧表示、適用、作成、削除などを行います。

# qemu-img snapshot [ -l | -a snapshot | -c snapshot | -d snapshot ] filename
-l を使うと、指定したディスクイメージに関連付けられているスナップショットの全一覧が表示されます。適用のオプション -a を使うと、ディスクイメージ (filename) が以前に保存したスナップショット snapshot の状態に戻ります。-c を使うと、イメージ (filename) のスナップショット (snapshot) が作成されます。-d を使うと、指定したスナップショットが削除されます。
対応している形式

qemu-img は次のいずれかの形式にファイルを変換するよう設計されています。

raw
raw ディスクイメージ形式 (デフォルト) です。最も高速となるファイルベースの形式です。ファイルシステムで未割り当てのブロックに対応している場合 (linux なら ext2 または ext3、Windows なら NTFS)、書き込みが行われたセクターのみに領域が予約されます。イメージが使用する実際のサイズを取得する場合は qemu-img info を使用します。Unix/Linux の場合は ls -ls を使用します。raw イメージで最適なパフォーマンスを得ることができますが、利用できる機能は非常に基本的なものに限られます (スナップショットなどは不可)。
qcow2
QEMU イメージ形式です。最も用途が多様となる形式で、機能も最も充実しています。オプションの AES 暗号化、zlib ベースの圧縮、仮想マシンの複数のスナップショットに対するサポート、イメージを小さくするなどのオプションを付ける場合に使用します。これらは未割り当てのブロックに対応していないファイルシステムで役に立ちます (Windows 上の NTFS 以外のファイルシステム)。機能が充実している分、パフォーマンスは低下します。
ゲスト仮想マシンやホスト物理マシンでの実行に使用できるのは上記の形式のみになりますが、qemu-img では、以下の形式から raw または qcow2 形式のいずれかに変換できるよう、これらの形式も認識し、これらに対応しています。通常、イメージの形式は自動的に検出されます。raw または qcow2 形式への変換に加え、raw または qcow2 から元の形式への逆変換も可能です。
bochs
Bochs のディスクイメージ形式です。
cloop
Linux 圧縮ループ (Linux Compressed Loop) のイメージです。Knoppix CD-ROM などのように圧縮された CD-ROM イメージを直接再利用する場合にのみ役立ちます。
cow
ユーザーモード Linux コピーオンライト (User Mode Linux Copy On Write) のイメージ形式です。cow 形式が含まれているのは、単に旧バージョンとの互換性を持たせるためです。これは Windows では動作しません。
dmg
Mac のディスクイメージ形式です。
nbd
ネットワークブロックデバイスです。
parallels
Parallels の仮想化ディスクイメージ形式です。
qcow
旧式の QEMU のイメージ形式です。これが含まれているのは、単に旧式のバージョンとの互換性を持たせるためです。
vdi
Oracle 仮想マシンの VirtualBox (Oracle VM VirtualBox) のハードディスクイメージ形式です。
vmdk
VMware 互換のイメージ形式です (バージョン 1 および 2 では読み取り/書き込みサポート、バージョン 3 では読み取り専用サポート)。
vpc
Windows 仮想 PC (Windows Virtual PC) のディスクイメージ形式です。vhd、または Microsoft の仮想ハードディスクのイメージ形式とも呼ばれます。
vvfat
仮想 VFAT のディスクイメージ形式です。

11.2. QEMU ゲストエージェント

QEMU ゲストエージェントは、ゲスト内で実行され、ホストマシンが libvirt を使用してゲストオペレーティングシステムに対してコマンドを実行できるようにします。ゲストオペレーティングシステムはその後、これらのコマンドに非同期的に応答します。本章では、libvirt コマンドおよびゲストエージェントが利用可能なオプションについて説明します。

重要

信頼されるゲストによって実行される場合にのみ、ゲストエージェントは安全であることに注意してください。信頼されていないゲストはゲストエージェントのプロトコルを悪意のある方法で無視したり、これを誤用したりする可能性があります。ホスト上のサービス拒否攻撃を回避するためのビルトイン保護プログラムは存在しますが、ホストは、操作が予想どおりに実行されるためにゲストの協力を必要とします。
Linux および Windows ゲスト上の QEMU ゲストエージェントのヘルプで、CPU のホットプラグおよびホットアンプラグがサポートされていることに注意してください。CPU はゲストの実行中に有効/無効にすることができるので、ホットプラグ機能を実装でき、かつアンプラグ機能を模倣することができます。詳細は、「仮想 CPU 数を設定する」 を参照してください。

11.2.1. ゲストエージェントのインストールおよび有効化

yum install qemu-guest-agent コマンドでゲスト仮想マシンに qemu-guest-agent をインストールし、これをサービス (qemu-guest-agent.service) として起動時に毎回自動的に実行させます。

11.2.2. ゲストエージェントとホスト間の通信設定

ホストマシンは、ホストとゲストマシン間の VirtIO シリアル接続でゲストエージェントと通信します。VirtIO シリアルチャンネルは、キャラクターデバイスドライバー (通常 Unix ソケット) 経由でホストに接続し、ゲストはこのシリアルチャンネルでリッスンします。以下の手順では、ゲストエージェントの使用に備えてホストおよびゲストマシンを設定する方法を説明します。

注記

Windows ゲストに QEMU ゲストエージェントをセットアップする方法については、こちら を参照してください。

手順11.1 ゲストエージェントとホスト間の通信設定

  1. ゲスト XML を開きます

    QEMU ゲストエージェント設定でゲスト XML を開きます。ファイルを開くにはゲスト名が必要になります。認識可能なゲストを一覧表示するには、ホスト物理マシン上でコマンド # virsh list を実行します。この例では、ゲスト名は rhel6 になります。
    # virsh edit rhel6
  2. ゲスト XML ファイルを編集します

    以下の要素を XML ファイルに追加し、変更を保存します。
    <channel type='unix'>
       <source mode='bind' path='/var/lib/libvirt/qemu/rhel6.agent'/>
       <target type='virtio' name='org.qemu.guest_agent.0'/>
    </channel>

    図11.1 QEMU ゲストエージェント設定のためのゲスト XML の編集

  3. ゲスト内の QEMU ゲストエージェントを起動します

    まだ実行していない場合は、yum install qemu-guest-agent を使用してゲスト仮想マシン内にゲストエージェントをダウンロードし、これをインストールします。いったんインストールしたら、以下のようにサービスを開始します。
    # service start qemu-guest-agent
これで設定されたキャラクターデバイスドライバー上で有効な libvirt コマンドを送信すると、ゲストと通信できます。

11.2.3. QEMU ゲストエージェントの使用

QEMU ゲストのエージェントプロトコル (QEMU GA) パッケージである qemu-guest-agent は Red Hat Enterprise Linux 6.5 以降で完全にサポートされています。ただし、isa-serial/virtio-serial トランスポートに関する以下の制限があります。
  • qemu-guest-agent は、クライアントがチャンネルに接続しているかどうかを検出できません。
  • qemu-guest-agent がバックエンドとの接続を切断したかまたは再接続したかをクライアントは検出できません。
  • virtio-serial デバイスがリセットされ、qemu-guest-agent がチャネルに接続されなくなった場合 (通常は再起動またはホットプラグによって引き起こされる)、クライアントからのデータはドロップされます。
  • virtio-serial デバイスがリセットされてから qemu-guest-agent がチャネルに接続されると、qemu-guest-agent がまだ実行中かまたは接続されているかどうかにかかわらず、クライアントからのデータはキューに入れられます (さらに使用可能なバッファーが消費されると、スロットリングされます)。

11.2.4. libvirt による QEMU ゲストエージェントの使用

QEMU ゲストエージェントをインストールすると、他のさまざまな libvirt コマンドをより強力にすることができます。ゲストエージェントは以下の virsh コマンドを強化します。
  • virsh shutdown --mode=agent - このシャットダウン方法は virsh shutdown --mode=acpi よりも信頼性があります。QEMU ゲストエージェントで使用される virsh shutdown は協力的なゲストをクリーンな状態でシャットダウンできるように保証されているためです。エージェントがない場合、libvirt は ACPI シャットダウンイベントの挿入に依存しなければなりませんが、一部のゲストはそのイベントを無視するため、シャットダウンされません。
    virsh reboot の場合と同じ構文で使用できます。
  • virsh snapshot-create --quiesce - スナップショットが作成される前に、ゲストがその I/O を安定した状態にフラッシュできるようにします。これにより、fsck を実行したり、データベーストランザクションを部分的に失うことなくスナップショットを使用することが可能になります。ゲストエージェントは、ゲストの協力を提供することで、ディスクコンテンツの高レベルの安定性を実現します。
  • virsh setvcpus --guest - ゲストに対して、CPU をオフラインにするように指示します。
  • virsh dompmsuspend - ゲストのオペレーティングシステムの電力管理機能を使用して稼働中のゲストを正常に一時停止します。

11.2.5. ゲスト仮想マシンディスクバックアップの作成

libvirtqemu-ga と通信し、ゲスト仮想マシンファイルシステムのスナップショットが内部で一貫しており、随時使用可能であることを保証します。Red Hat Enterprise Linux 6 に改善が加えられたことにより、ファイルとアプリケーションの両レベルの同期 (フラッシュ) が確実に実行されるようになりました。ゲストシステムの管理者はアプリケーション固有のフリーズ/フリーズ解除フックスクリプトを作成し、インストールすることができます。ファイルシステムをフリーズする前に、qemu-ga は主なフックスクリプト (qemu-ga パッケージ内に組み込まれている) を起動します。フリーズプロセスは、すべての仮想マシンアプリケーションを一時的に非アクティブにします。
ファイルシステムがフリーズされる前に、以下のアクションが発生します。
  • ファイルシステムのアプリケーション/データベースは作業バッファーを仮想ディスクにフラッシュし、クライアント接続の受け入れを停止します。
  • アプリケーションはそれらのデータファイルを一貫性のある状態にします。
  • メインフックスクリプトが返されます。
  • qemu-ga はファイルシステムをフリーズし、管理スタックはスナップショットを取得します。
  • スナップショットが確認されます。
  • ファイルシステムの機能が再開します。
フリーズ解除が逆の順序で生じます。
ゲストディスクのスナップショットを作成するには、snapshot-create-as コマンドを使用します。このコマンドに関する詳細情報は、「現在のドメインのスナップショットの作成」 を参照してください。

注記

アプリケーション固有のフックスクリプトは、正常に実行されるために各種の SELinux パーミッションを必要とする場合があります。これは、データベースと対話するためにスクリプトをソケットに接続する必要がある場合と同様です。通常、このような状況に備えて、ローカルの SELinux ポリシーを作成し、インストールしておく必要があります。表11.1「QEMU ゲストエージェントのパッケージコンテンツ」 内の /etc/qemu-ga/fsfreeze-hook.d/ のラベルが付いた行にある restorecon -FvvR コマンドを実行すると、ファイルシステムノードへのアクセスが設定なしで機能します。
qemu-guest-agent バイナリー RPM には以下のファイルが含まれます。

表11.1 QEMU ゲストエージェントのパッケージコンテンツ

ファイル名詳細
/etc/rc.d/init.d/qemu-gaQEMU ゲストエージェント用のサービス制御スクリプト (開始/停止)。
/etc/sysconfig/qemu-gaQEMU ゲストエージェントが /etc/rc.d/init.d/qemu-ga 制御スクリプトで読み込まれる際の QEMU ゲストエージェントの設定ファイル。設定内容はシェルスクリプトのコメントと共にファイルに記載されます。
/usr/bin/qemu-gaQEMU ゲストエージェントのバイナリーファイル。
/usr/libexec/qemu-ga/フックスクリプトの root ディレクトリー。
/usr/libexec/qemu-ga/fsfreeze-hookメインフックスクリプト。ここでの変更は必要ありません。
/usr/libexec/qemu-ga/fsfreeze-hook.d/個別の、アプリケーション固有のフックスクリプトのディレクトリー。ゲストのシステム管理者はこのディレクトリーにフックスクリプトを手動でコピーし、それらに適切なファイルモードビットが設定されていることを確認してから、このディレクトリー上で restorecon -FvvR を実行する必要があります。
/usr/share/qemu-kvm/qemu-ga/サンプルスクリプトのあるディレクトリー (例の参照目的のみ)。ここに含まれるスクリプトは実行されません。
メインのフックスクリプトである /usr/libexec/qemu-ga/fsfreeze-hook は、独自のメッセージを、アプリケーション固有スクリプトの標準出力およびエラーメッセージと共に /var/log/qemu-ga/fsfreeze-hook.log のログファイルに記録します。詳細情報は、wiki.qemu.org または libvirt.org の qemu-guest-agent wiki ページを参照してください。

11.3. Windows ゲスト上での QEMU ゲストエージェントの実行

Red Hat Enterprise Linux のホストマシンは、Windows ゲスト内で QEMU ゲストエージェントを実行することで Windows ゲストにコマンドを発行できます。これがサポートされるのは、Red Hat Enterprise Linux 6.5 以降を実行しているホスト内の以下の Windows ゲストオペレーティングシステムです。
  • Windows XP Service Pack 3 (VSS は対象外)
  • Windows Server 2003 R2 - x86 および AMD64 (VSS は対象外)
  • Windows Server 2008
  • Windows Server 2008 R2
  • Windows 7 - x86 および AMD64
  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows 8 - x86 および AMD64
  • Windows 8.1 - x86 および AMD64

注記

Windows ゲスト仮想マシンは、Windows 用の QEMU ゲストエージェントである qemu-guest-agent-win を必要とします。このエージェントは、Red Hat Enterprise Linux 上で実行される Windows ゲスト仮想マシンの VSS (Volume Shadow Copy Service) サポートに必要です。詳細は、こちら をご覧ください。

手順11.2 Windows ゲスト上で QEMU ゲストエージェントを設定する

Red Hat Enterprise Linux のホストマシン上で Windows ゲストを実行するには、以下のステップにしたがいます。
  1. Red Hat Enterprise Linux ホストマシンの準備

    以下のパッケージが Red Hat Enterprise Linux ホスト物理マシン上でインストールされていることを確認します。
    • /usr/share/virtio-win/ に格納されている virtio-win
    Windows ゲストにドライバーをコピーするには、以下のコマンドを使用して qxl ドライバーの *.iso ファイルを作成します。
    # mkisofs -o /var/lib/libvirt/images/virtiowin.iso /usr/share/virtio-win/drivers
  2. Windows ゲストの準備

    ドライバーを更新するために、*.iso を Windows ゲストにマウントして virtio-serial ドライバーをゲストにインストールします。ゲストを起動してから、以下のように driver .iso ファイルをゲストにアタッチします (ここでは hdb というディスクを使用)。
    # virsh attach-disk guest /var/lib/libvirt/images/virtiowin.iso hdb
    Windows の コントロールパネル を使用してドライバーをインストールするには、以下のメニューに移動します。
    • virtio-win ドライバーのインストール: ハードウェアとサウンド > デバイスマネージャー > virtio-serial driver を選択します。
  3. Windows ゲスト XML 設定ファイルの更新

    Windows ゲストのゲスト XML ファイルは Red Hat Enterprise Linux のホストマシン上にあります。このファイルにアクセスするには、Windows ゲスト名が必要になります。ホストマシンが認識可能なゲストを一覧表示するには、ホストマシン上で # virsh list コマンドを使用します。この例では、ゲスト名は win7x86 になります。
    # virsh edit win7x86 コマンドを使って、以下の要素を XML ファイルに追加し、変更を保存します。ソースのソケット名はホスト内で一意のものである必要があることに注意してください。この例では、win7x86.agent になります。
       ...
      <channel type='unix'>
          <source mode='bind' path='/var/lib/libvirt/qemu/win7x86.agent'/>
          <target type='virtio' name='org.qemu.guest_agent.0'/>
          <address type='virtio-serial' controller='0' bus='0' port='1'/>
       </channel>
       <channel type='spicevmc'>
          <target type='virtio' name='com.redhat.spice.0'/>
          <address type='virtio-serial' controller='0' bus='0' port='2'/>
       </channel>
       ...
    
    

    図11.2 Windows ゲストの XML を編集して QEMU ゲストエージェントを設定する

  4. Windows ゲストの再起動

    Windows ゲストを再起動して変更を適用します。
    # virsh reboot win7x86
  5. Windows ゲストでの QEMU ゲストエージェントの準備

    Windows ゲストでゲストエージェントを準備するには、以下を実行します。
    1. 最新の virtio-win パッケージをインストールします。

      Red Hat Enterprise Linux ホスト物理マシンのターミナルウィンドウで以下のコマンドを実行して、インストールするファイルを見つけます。以下に示されるファイルは、お使いのシステムで見つかるファイルと同一とは限りませんが、最新の公式バージョンが示されます。
      # rpm -qa|grep virtio-win
      virtio-win-1.6.8-5.el6.noarch
      
      # rpm -iv virtio-win-1.6.8-5.el6.noarch
    2. インストール完了の確認

      virtio-win パッケージのインストール完了後に /usr/share/virtio-win/guest-agent/ フォルダーを確認すると、以下のように qemu-ga-x64.msi または qemu-ga-x86.msi というファイルが見つかります。
      # ls -l /usr/share/virtio-win/guest-agent/
      
      total 1544
      
      -rw-r--r--. 1 root root 856064 Oct 23 04:58 qemu-ga-x64.msi
      
      -rw-r--r--. 1 root root 724992 Oct 23 04:58 qemu-ga-x86.msi
      
    3. .msi ファイルのインストール

      Windows ゲスト (例: win7x86) でファイルをダブルクリックして qemu-ga-x64.msi または qemu-ga-x86.msi をインストールします。インストール後は、システムマネージャー内の Windows ゲストに qemu-ga サービスとして表示されます。このマネージャーは、サービスステータスのモニタリングにも使用できます。

11.3.1. Windows ゲスト上での QEMU ゲストエージェントにおける libvirt コマンドの使用

QEMU ゲストエージェントは、Windows ゲストと以下の virsh コマンドが使用できます。
  • virsh shutdown --mode=agent - このシャットダウン方法は virsh shutdown --mode=acpi よりも信頼性があります。QEMU ゲストエージェントで使用される virsh shutdown は協力的なゲストをクリーンな状態でシャットダウンできるように保証されているためです。エージェントがない場合、libvirt は ACPI シャットダウンイベントの挿入に依存しなければなりませんが、一部のゲストはそのイベントを無視するため、シャットダウンされません。
    virsh reboot の場合と同じ構文で使用できます。
  • virsh snapshot-create --quiesce - スナップショットが作成される前に、ゲストがその I/O を安定した状態にフラッシュできるようにします。これにより、fsck を実行したり、データベーストランザクションを部分的に失うことなくスナップショットを使用することが可能になります。ゲストエージェントは、ゲストの協力を提供することで、ディスクコンテンツの高レベルの安定性を実現します。
  • virsh dompmsuspend - ゲストのオペレーティングシステムの電力管理機能を使用して稼働中のゲストを正常に一時停止します。

11.4. デバイスのリダイレクトに制限を設ける

リダイレクトからの特定のデバイスをフィルター処理するには、フィルタープロパティーを -device usb-redir に渡します。フィルタープロパティーはフィルタールールで構成される文字列を取ります。ルールの形式は以下の通りです。
<class>:<vendor>:<product>:<version>:<allow>
特定フィールドのいずれの値も受け入れるようにするには、-1 の値を使用します。「|」をセパレーターとして使用すると同一コマンドラインで複数のルールを使用することができます。デバイスがフィルタールールに一致しない場合、リダイレクトは許可されません。

例11.1 Windows ゲスト仮想マシンでのリダイレクト制限

  1. Windows 7 ゲスト仮想マシンを用意します。
  2. 次のコードの抜粋をゲスト仮想マシンの XML ファイルに追加します。
        <redirdev bus='usb' type='spicevmc'>
          <alias name='redir0'/>
          <address type='usb' bus='0' port='3'/>
        </redirdev>
        <redirfilter>
          <usbdev class='0x08' vendor='0x1234' product='0xBEEF' version='2.0' allow='yes'/>
          <usbdev class='-1' vendor='-1' product='-1' version='-1' allow='no'/>
        </redirfilter>
  3. ゲスト仮想マシンを起動し、次のコマンドを実行して設定の変更を確認します。
    # ps -ef | grep $guest_name
    -device usb-redir,chardev=charredir0,id=redir0,/
    filter=0x08:0x1234:0xBEEF:0x0200:1|-1:-1:-1:-1:0,bus=usb.0,port=3
  4. USB デバイスをホスト物理マシンに挿入し、virt-viewer を使ってゲスト仮想マシンに接続します。
  5. メニュー内の USB デバイスの選択 をクリックします。「Some USB devices are blocked by host policy (ホストのポリシーによりブロックされているデバイスがあります)」というようなメッセージが生成されます。確認の OK をクリックし、続行します。
    フィルターが適用されます。
  6. フィルターよるキャプチャーが正しく動作するよう USB デバイスの製造元と製品を確認し、次にホスト物理マシンのドメイン XML に次の変更を加えて USBリダイレクトを許可します。
       <redirfilter>
          <usbdev class='0x08' vendor='0x0951' product='0x1625' version='2.0' allow='yes'/>
          <usbdev allow='no'/>
        </redirfilter>
  7. ゲスト仮想マシンを再起動し、virt-viewer を使ってゲスト仮想マシンに接続します。USB デバイスがトラフィックをゲスト仮想マシンにリダイレクトするようになります。

11.5. 仮想 NIC に接続しているネットワークブリッジまたはホスト物理マシンを動的に変更する

このセクションでは、ゲスト仮想マシンを稼働したままで安全性を確保しながら、そのゲスト仮想マシンの vNIC をあるブリッジから別のブリッジに移動する方法について説明します。
  1. 次のような設定でゲスト仮想マシンを用意します。
    <interface type='bridge'>
          <mac address='52:54:00:4a:c9:5e'/>
          <source bridge='virbr0'/>
          <model type='virtio'/>
    </interface>
  2. インターフェースの更新用に XML ファイルを準備します。
    # cat br1.xml
    <interface type='bridge'>
          <mac address='52:54:00:4a:c9:5e'/>
          <source bridge='virbr1'/>
          <model type='virtio'/>
    </interface>
  3. ゲスト仮想マシンを起動し、ゲスト仮想マシンのネットワークが機能していることを確認してから、そのゲスト仮想マシンの vnetX が指定するブリッジに接続されていることを確認します。
    # brctl show
    bridge name     bridge id               STP enabled     interfaces
    virbr0          8000.5254007da9f2       yes                  virbr0-nic
    
    vnet0
    virbr1          8000.525400682996       yes                  virbr1-nic
  4. 次のコマンドを使って新しいインターフェースのパラメーターでゲスト仮想マシンのネットワークを更新します。
    # virsh update-device test1 br1.xml 
    
    Device updated successfully
    
  5. ゲスト仮想マシン上で service network restart を実行します。ゲスト仮想マシンが virbr1 の新しい IP アドレスを取得します。ゲスト仮想マシンの virbr0 が新しいブリッジ (virbr1) に接続されていることを確認します。
    # brctl show
    bridge name     bridge id               STP enabled     interfaces
    virbr0          8000.5254007da9f2       yes             virbr0-nic
    virbr1          8000.525400682996       yes             virbr1-nic     vnet0

第12章 ストレージの概念

本章では、ストレージデバイスの記述と管理に使用される概念を紹介します。ストレージプールやボリュームなどの用語はこれに続くセクションで説明します。

12.1. ストレージプール

ストレージプール は、ゲスト仮想マシンにストレージをプロビジョニングするために libvirt によって管理されるファイル、ディレクトリー、またはストレージデバイスです。ストレージプールはローカルにすることも、ネットワーク経由で共有することもできます。ストレージプールは、管理者 (ストレージ担当管理者であることが多い) がゲスト仮想マシンで使用できるように取り分けた一定量のストレージのことです。ストレージプールは、ストレージ管理者またはシステム管理者のいずれかによってストレージボリュームに分割され、これらのボリュームはブロックデバイスとしてゲスト仮想マシンに割り当てられます。つまり、ストレージボリュームとパーティションの関係は、ストレージプールとディスクの関係に等しくなります。ストレージプールは仮想コンテナーであるものの、ストレージプールは、qemu-kvm によって許可される最大サイズ、ホスト物理マシン上のディスクのサイズという 2 つの要素によって制限されます。ストレージプールは、ホスト物理マシン上のディスクのサイズを超えることはできません。最大サイズは以下の通りです。
  • virtio-blk = 2^63 バイトまたは 8 エクサバイト (raw ファイルまたはディスクを使用)
  • Ext4 = ~ 16 TB (4 KB ブロックサイズを使用)
  • XFS = ~8 エクサバイト
  • qcow2 とホストファイルシステムはそれぞれ独自のメタデータを維持し、非常に大きなイメージサイズを使用する場合はスケーラビリティーの評価または調整を行う必要があります。raw ディスクを使用すると、スケーラビリティーや最大サイズに影響を与える可能性のある層の数が少なくなります。
libvirt では、ディレクトリーベースのストレージプール、/var/lib/libvirt/images/ ディレクトリーをデフォルトのストレージプールとして使用します。このデフォルトストレージプールは別のストレージプールに変更可能です。
  • ローカルのストレージプール - ローカルのストレージプールは直接ホスト物理マシンサーバーに割り当てられます。ローカルのストレージプールには、ローカルのディレクトリー、直接割り当てられているディスク、物理パーティション、LVM ボリュームグループなどが含まれます。これらのストレージボリュームはゲスト仮想マシンのイメージを格納しているか、または追加ストレージとしてゲスト仮想マシンに割り当てられます。ローカルのストレージプールは直接ホスト物理マシンサーバーに割り当てられるため、ゲスト仮想マシンの移行や大量のゲスト仮想マシンを必要としない小規模の導入、テスト、および開発などを目的とする場合に便利です。ローカルのストレージプールはライブマイグレーションには対応していないため、多くの実稼働環境には適していません。
  • ネットワーク接続の (共有) ストレージプール - ネットワーク接続のストレージプールには、標準のプロトコルを使ってネットワーク経由で共有するストレージデバイスが含まれます。ホスト物理マシン間での仮想マシンの移行を行なう際、virt-manager を使用する場合はネットワーク接続のストレージが必須になりますが、virsh を使用する場合はオプションになります。ネットワーク接続のストレージプールは libvirt で管理します。ネットワーク接続のストレージプールに対応するプロトコルには、以下が含まれます。
    • ファイバーチャンネルベースの LUN
    • iSCSI
    • NFS
    • GFS2
    • SCSI RDMA プロトコル (SCSI RCP) - InfiniBand アダプターと 10GbE iWARP アダプターで使用されるブロックエクスポートプロトコル

注記

マルチパスのストレージプールは完全にはサポートされていないため、作成したり、使用したりしないでください。

12.2. ボリューム

ストレージプールは、さらにストレージボリュームに分割されます。ストレージボリュームは、物理パーティション、LVM 論理ボリューム、ファイルベースのディスクイメージ、および libvirt で処理される他のストレージタイプなどを抽象化したものです。ストレージボリュームは、基礎となるハードウェアに関係なく、ローカルストレージデバイスとしてゲスト仮想マシンに提示されます。
ボリュームの参照

特定のボリュームを参照する方法として、3 種類のアプローチが可能です。

ボリュームとストレージプールの名前
ボリュームが属しているストレージプールの識別子とボリューム名を使って参照します。 virsh コマンドラインの場合、 --pool storage_pool volume_name の形式になります。
例: guest_images プール内にある firstimage という名前のボリューム
# virsh vol-info --pool guest_images firstimage
Name:           firstimage
Type:           block
Capacity:       20.00 GB
Allocation:     20.00 GB

virsh #
ホスト物理システム上のストレージへの完全パス
ファイルシステム上のボリュームへの完全パスを使って参照することもできます。この方法を採用する場合、プールの識別子を含める必要はありません。
たとえば、ホスト物理マシンシステムに /images/secondimage.img として表示される secondimage.img という名前のボリュームの場合、このイメージは /images/secondimage.img としても参照されます。
# virsh vol-info /images/secondimage.img
Name:           secondimage.img
Type:           file
Capacity:       20.00 GB
Allocation:     136.00 kB
固有のボリュームキー
仮想化システムで初めてボリュームを作成すると、固有の識別子が生成され、割り当てられます。この固有の識別子は ボリュームキー と呼ばれます。ボリュームキーの形式は使用するストレージによって異なります。
LVM などのブロックベースのストレージで使用する場合には、ボリュームキーは以下のような形式になります。
c3pKz4-qPVc-Xf7M-7WNM-WJc8-qSiz-mtvpGn
ファイルベースのストレージで使用する場合には、ボリュームキーはそのボリュームストレージへの完全パスのコピーになる場合があります。
/images/secondimage.img
例: Wlvnf7-a4a3-Tlje-lJDa-9eak-PZBv-LoZuUr のボリュームキーを持つボリューム
# virsh vol-info Wlvnf7-a4a3-Tlje-lJDa-9eak-PZBv-LoZuUr
Name:           firstimage
Type:           block
Capacity:       20.00 GB
Allocation:     20.00 GB
virsh は、ボリューム名、ボリュームパス、またはボリュームキーの間で変換するコマンドを提供します。
vol-name
ボリュームパスまたはボリュームキーが指定されると、ボリューム名を返します。
# virsh vol-name /dev/guest_images/firstimage
firstimage
# virsh vol-name Wlvnf7-a4a3-Tlje-lJDa-9eak-PZBv-LoZuUr
vol-path
ボリュームキーまたはストレージプールの識別子とボリューム名が指定されると、ボリュームパスを返します。
# virsh vol-path Wlvnf7-a4a3-Tlje-lJDa-9eak-PZBv-LoZuUr
/dev/guest_images/firstimage
# virsh vol-path --pool guest_images firstimage
/dev/guest_images/firstimage
vol-key コマンド
ボリュームパスまたはストレージプールの識別子とボリューム名が指定されると、ボリュームキーを返します。
# virsh vol-key /dev/guest_images/firstimage
Wlvnf7-a4a3-Tlje-lJDa-9eak-PZBv-LoZuUr
# virsh vol-key --pool guest_images firstimage 
Wlvnf7-a4a3-Tlje-lJDa-9eak-PZBv-LoZuUr

第13章 ストレージプール

本章では、さまざまなタイプのストレージプールを作成する方法について説明しています。ストレージプール とは、管理者 (ストレージ担当管理者の場合が多い) によって確保される一定量のストレージで、仮想マシンなどに使用されます。ストレージプールは、ストレージ管理者またはシステム管理者のいずれかによってストレージボリュームに分割されることが多く、ボリュームはブロックデバイスとしてゲスト仮想マシンに割り当てられます。

例13.1 NFS ストレージプール

NFS サーバー担当のストレージ管理者が、ゲスト仮想マシンのデータを格納するための共有を作成するとしましょう。システム管理者は、ホスト物理マシン上のプールをこの共有の詳細で定義します (nfs.example.com:/path/to/share/vm_data にマウントされる)。プールが起動されると、libvirt は、指定ディレクトリーに共有をマウントしますが、これは、システム管理者がログインし、mount nfs.example.com:/path/to/share /vmdata を実行したかのような動作になります。プールが自動起動するように設定されている場合、libvirt は、 libvirt の起動時に指定ディレクトリー上に NFS 共有をマウントします。
プールが起動すると、NFS で共有しているファイルがボリュームとして報告され、ストレージボリュームのパスの問い合わせが libvirt API を使って行なわれます。次に、このボリュームのパスは、ゲスト仮想マシンの XML 定義ファイル内の、ゲスト仮想マシンのブロックデバイス用のソースストレージについて記述しているセクションにコピーされます。NFS では、libvirt API を使用するアプリケーションで、プールの制限サイズ (共有のストレージ最大容量) までプール内にボリュームを作成したり、そのボリュームを削除したりすることができます (NFS 共有内のファイル)。すべてのプールタイプがボリュームの作成や削除に対応している訳ではありません。プールを停止すると起動操作が無効になるような場合は、NFS 共有をアンマウントしてください。破棄操作で共有上にあるデータは変更されませんが、その名前は変更されます。詳細については man virsh をご覧ください。

注記

ゲスト仮想マシンが正常に機能するためにストレージプールとボリュームが必要な訳ではありません。プールとボリュームは、libvirt がストレージの一部をゲスト仮想マシンに使用できるようにする手段の一つです。ただし、独自にストレージを管理し、プールやボリュームを定義せずにゲスト仮想マシンを適切に動作させる方法を取る管理者もいます。プールを使用しないシステムでは、システム管理者は、各自が選択するツールを使ってゲスト仮想マシンのストレージの可用性を確保する必要があります。たとえば、NFS 共有をホスト物理マシンの fstab に追加して、その共有が起動時にマウントされるようにします。

13.1. ディスクベースのストレージプール

このセクションでは、ゲスト仮想マシン用にディスクベースのストレージデバイスを作成する方法について説明します。

警告

ゲストには、ブロックデバイスまたはディスク全体への書き込みアクセスを付与しないようにします (例: /dev/sdb)。パーティション (/dev/sdb1) または LVM ボリュームなどを利用するようにします。
ゲストにブロックデバイス全体を渡した場合、ゲストはそれにパーティションを設定するか、またはその上に独自の LVM グループを作成する可能性があります。この場合、ホスト物理マシンがこれらのパーティションや LVM グループを検出し、エラーの原因になります。

13.1.1. virsh でディスクベースのストレージプールを作成する

以下の手順では、virsh コマンドでディスクデバイスを使って新しいストレージプールを作成します。

警告

ディスクをストレージプール専用にすると、再フォーマットが行われ、ディスクデバイス上に現在格納されているすべてのデータが消去されます。以下の手順を開始する前に、ストレージデバイスをバックアップすることが強く推奨されます。
  1. ディスク上で GPT ディスクラベルを作成する

    ディスクには、GPT (GUID Partition Table) ディスクラベルによる再ラベル付けが必要になります。GPT ディスクラベルの使用により、各デバイス上に最大 128 個の大量のパーティションを作成することができます。MS-DOS パーティションテーブルに比べ、GPT のパーティションテーブルはより多くのパーティションでパーティションデータを格納することができます。
    # parted /dev/sdb
    GNU Parted 2.1
    Using /dev/sdb
    Welcome to GNU Parted! Type 'help' to view a list of commands.
    (parted) mklabel                                                          
    New disk label type? gpt                                                  
    (parted) quit                                                             
    Information: You may need to update /etc/fstab.                           
    #
  2. ストレージプールの設定ファイルを作成する

    新規デバイスに必要となるストレージプール情報が含まれた一時 XML テキストファイルを作成します。
    このファイルは、以下のような形式にし、また以下のフィールドを含める必要があります。
    <name>guest_images_disk</name>
    name パラメーターでストレージプールの名前を指定します。この例では、guest_images_disk という名前を使用しています。
    <device path='/dev/sdb'/>
    path 属性を持つ device パラメーターは、ストレージデバイスのデバイスパスを指定します。この例では、デバイス /dev/sdb を使用しています。
    <target> <path>/dev</path></target>
    path サブパラメーターを持つファイルシステム target パラメーターは、ホスト物理ファイルシステム上の位置を判別して、このストレージプールで作成されたボリュームを追加します。
    たとえば sdb1、 sdb2、 sdb3 などです。この例のように /dev/ を使用すると、このストレージプールから作成したボリュームは /dev/sdb1、/dev/sdb2、/dev/sdb3 としてアクセスできることになります。
    <format type='gpt'/>
    format パラメーターは、パーティションテーブルのタイプを指定します。この例では、前述のステップで作成した GPT ディスクラベルのタイプと一致するよう gpt を使用しています。
    テキストエディターでストレージプールデバイス用の XML ファイルを作成します。

    例13.2 ディスクベースのストレージデバイスのストレージプール

    <pool type='disk'>
      <name>guest_images_disk</name>
      <source>
        <device path='/dev/sdb'/>
        <format type='gpt'/>
      </source>
      <target>
        <path>/dev</path>
      </target>
    </pool>
  3. デバイスを割り当てる

    前述のステップで作成した XML 設定ファイルで virsh pool-define コマンドを使用しストレージプールの定義を追加します。
    # virsh pool-define ~/guest_images_disk.xml
    Pool guest_images_disk defined from /root/guest_images_disk.xml
    # virsh pool-list --all
    Name                 State      Autostart 
    -----------------------------------------
    default              active     yes       
    guest_images_disk    inactive   no
  4. ストレージプールを起動する

    virsh pool-start コマンドを使用してストレージプールを起動します。virsh pool-list --all コマンドを使用すると、プールが起動したかどうかを確認できます。
    # virsh pool-start guest_images_disk
    Pool guest_images_disk started
    # virsh pool-list --all
    Name                 State      Autostart 
    -----------------------------------------
    default              active     yes       
    guest_images_disk    active     no
  5. autostart をオンにする

    ストレージプールの autostart をオンにします。autostart は、サービスが開始するとストレージプールも起動するように libvirtd サービスを設定します。
    # virsh pool-autostart guest_images_disk
    Pool guest_images_disk marked as autostarted
    # virsh pool-list --all
    Name                 State      Autostart 
    -----------------------------------------
    default              active     yes       
    guest_images_disk    active     yes
  6. ストレージプールの設定を確認する

    ストレージプールが正しく作成されたこと、サイズが正しく報告されたこと、および状態が running として報告されていることを確認します。
    # virsh pool-info guest_images_disk
    Name:           guest_images_disk
    UUID:           551a67c8-5f2a-012c-3844-df29b167431c
    State:          running
    Capacity:       465.76 GB
    Allocation:     0.00 
    Available:      465.76 GB
    # ls -la /dev/sdb
    brw-rw----. 1 root disk 8, 16 May 30 14:08 /dev/sdb
    # virsh vol-list guest_images_disk
    Name                 Path
    -----------------------------------------
  7. オプション: 一時設定ファイルを削除する

    必要がない場合は、一時的なストレージプール XML 設定ファイルを削除します。
    # rm ~/guest_images_disk.xml
これでディスクベースのストレージプールが使用できるようになります。

13.1.2. virsh を使ってストレージプールを削除する

以下は、virsh を使ってストレージプールを削除する方法を説明しています。
  1. 同じプールを使用する他のゲスト仮想マシンとの問題を避けるには、ストレージプールを停止してから使用中のリソースをすべて解放するのが最良の方法です。
    # virsh pool-destroy guest_images_disk
  2. ストレージプールの定義を削除します。
    # virsh pool-undefine guest_images_disk

13.2. パーティションベースのストレージプール

このセクションでは、事前フォーマットされているブロックデバイス、つまりパーティションをストレージプールとして使用する方法を説明しています。
以下の例では、ホスト物理マシンは ext4 でフォーマットされた 500GB のままの単独パーティション (/dev/sdc1) である 500GB のハードドライブ (/dev/sdc) を持っています。以下の手順を使用して、このハードドライブ用のストレージプールをセットアップします。

13.2.1. virt-manager を使用してパーティションベースのストレージプールを作成する

以下の手順では、 ストレージデバイスのパーティションを使用して新規のストレージプールを作成していきます。

手順13.1 virt-manager を使用してパーティションベースのストレージプールを作成する

  1. ストレージプールのセッティングを開く

    1. virt-manager グラフィカルインターフェースで、メインウィンドウからホスト物理マシンを選択します。
      編集 メニューを開いて、 接続の詳細 を選択します。
      接続の詳細

      図13.1 接続の詳細

    2. 接続の詳細 ウィンドウで ストレージ タブをクリックします。
      ストレージタブ

      図13.2 ストレージタブ

  2. 新規ストレージプールを作成する

    1. 新規のプールを追加します (パート1)

      + ボタン (プールの追加ボタン) を押します。 新規ストレージプールの追加 ウィザードが表示されます。
      ストレージプールの 名前 を選択します。 この例では、 guest_images_fs という名前を使用しています。 種類fs: Pre-Formatted Block Device に変更します。
      ストレージプールの名前と種類

      図13.3 ストレージプールの名前と種類

      進む ボタンをクリックして次に進みます。
    2. 新規のプールを追加します (パート2)

      ターゲットパスフォーマットソースパス の各フィールドを変更します。
      ストレージプールのパスとフォーマット

      図13.4 ストレージプールのパスとフォーマット

      ターゲットパス
      ストレージプール用のソースデバイスのマウント先となる場所を ターゲットパス フィールドに入力します。 その場所がまだ存在しない場合は、 virt-manager によりそのディレクトリーが作成されます。
      フォーマット
      フォーマット 一覧からフォーマットを選択します。 デバイスはこの選択したフォーマットでフォーマット化されます。
      この例では、ext4 ファイルシステムを使用しています。これは Red Hat Enterprise Linux のデフォルトのファイルシステムです。
      ソースパス
      ソースパス フィールドにデバイスを入力します。
      この例では、/dev/sdc1 デバイスを使用しています。
      詳細を確認して、完了 ボタンを押すと、ストレージプールが作成されます。
  3. 新規ストレージプールを確認する

    数秒後に、左側のストレージ一覧に新規ストレージプールが出現します。 期待通りのサイズが報告されていることを確認します。 この例では、458.20 GB Free です。 状態 フィールドで新規ストレージが Active と報告されていることを確認します。
    ストレージプールを選択します。 自動起動 フィールドで、 起動時 のチェックボックスをクリックします。これで libvirtd サービスの起動時には常にストレージデバイスも起動されるようになります。
    ストレージ一覧を確認する

    図13.5 ストレージ一覧を確認する

    これでストレージプールが作成されました。 接続の詳細 ウィンドウを閉じます。

13.2.2. virt-manager を使用してストレージプールを削除する

以下のようにしてストレージプールを削除します。
  1. 同じプールを使用する他のゲスト仮想マシンとの問題を避けるには、ストレージプールを停止して使用中のリソースをすべて解放するのが最良の方法です。これを実行するには、停止するストレージプールを選択して、ストレージウィンドウの下部にある赤い X アイコンをクリックします。
    停止アイコン

    図13.6 停止アイコン

  2. ゴミ箱アイコンをクリックしてストレージプールを削除します。このアイコンが使用できるのは、ストレージプールが停止している場合のみです。

13.2.3. virsh を使用したパーティションベースのストレージプールの作成

このセクションでは、virsh コマンドを使用した、パーティションベースストレージプールの作成を説明しています。

警告

ディスク全体をストレージプールとして割り当てる場合は、 この手順を使用しないでください (例、/dev/sdb) 。 ブロックデバイスやディスク全体への書き込みアクセスはゲストに与えないようにしてください。 この手順はパーティション (例、 /dev/sdb1) をストレージプールに割り当てる場合にのみ使用してください。

手順13.2 virsh を使用して事前フォーマット済みのブロックデバイスのストレージプールを作成する

  1. ストレージプールの定義を作成します

    virsh pool-define-as コマンドを使用して、 新規のストレージプールの定義を作成します。 事前フォーマット済みディスクをストレージプールとして定義するには、 入力を必要とするオプションが 3 つあります。
    パーティション名
    name パラメーターでストレージプールの名前を指定します。 この例では、 guest_images_fs という名前を使用しています。
    デバイス
    device パラメーターに path 属性を持たせストレージデバイスのデバイスパスを指定します。 この例では、 /dev/sdc1 パーティションを使用しています。
    マウントポイント
    フォーマット済みのデバイスをマウントするローカルファイルシステム上の mountpoint です。 マウントポイントのディレクトリーが存在しない場合は、virsh コマンドによりそのディレクトリーが作成されます。
    この例では、 /guest_images ディレクトリーを使用しています。
    # virsh pool-define-as guest_images_fs fs - - /dev/sdc1 - "/guest_images"
    Pool guest_images_fs defined
    これで、新規のプールとマウントポイントが作成されました。
  2. 新規のプールを確認する

    現在のストレージプールを一覧表示させます
    # virsh pool-list --all
    Name                 State      Autostart
    -----------------------------------------
    default              active     yes
    guest_images_fs      inactive   no
  3. マウントポイントを作成する

    virsh pool-build コマンドを使用して、 事前フォーマット済みファイルシステムのストレージプール用のマウントポイントを作成します。
    # virsh pool-build guest_images_fs
    Pool guest_images_fs built
    # ls -la /guest_images
    total 8
    drwx------.  2 root root 4096 May 31 19:38 .
    dr-xr-xr-x. 25 root root 4096 May 31 19:38 ..
    # virsh pool-list --all
    Name                 State      Autostart
    -----------------------------------------
    default              active     yes
    guest_images_fs      inactive   no
  4. ストレージプールを起動する

    virsh pool-start コマンドを使用して、 ファイルシステムをマウントポイントにマウントし、 プールを使用可能にします。
    # virsh pool-start guest_images_fs
    Pool guest_images_fs started
    # virsh pool-list --all
    Name                 State      Autostart
    -----------------------------------------
    default              active     yes
    guest_images_fs      active     no
  5. autostart をオンにする

    デフォルトでは、virsh で定義されているストレージプールは、libvirtd が開始する度に自動的に開始するようには設定されていません。virsh pool-autostart コマンドを使用して自動開始をオンにします。そうすると、ストレージプールは libvirtd が開始する度に自動的に開始されます。
    # virsh pool-autostart guest_images_fs
    Pool guest_images_fs marked as autostarted
    
    # virsh pool-list --all
    Name                 State      Autostart
    -----------------------------------------
    default              active     yes
    guest_images_fs      active     yes
  6. ストレージプールを確認する

    ストレージプールが正しく作成されたこと、 期待通りのサイズが報告されていること、 状態が running として報告されていることを確認します。 ファイルシステム上のマウントポイントに "lost+found" ディレクトリーがあるか確認します。 このディレクトリーがあればデバイスはマウントされていることになります。
    # virsh pool-info guest_images_fs
    Name:           guest_images_fs
    UUID:           c7466869-e82a-a66c-2187-dc9d6f0877d0
    State:          running
    Persistent:     yes
    Autostart:      yes
    Capacity:       458.39 GB
    Allocation:     197.91 MB
    Available:      458.20 GB
    # mount | grep /guest_images
    /dev/sdc1 on /guest_images type ext4 (rw)
    # ls -la /guest_images
    total 24
    drwxr-xr-x.  3 root root  4096 May 31 19:47 .
    dr-xr-xr-x. 25 root root  4096 May 31 19:38 ..
    drwx------.  2 root root 16384 May 31 14:18 lost+found

13.2.4. virsh を使用してストレージプールを削除する

  1. 同じプールを使用する他のゲスト仮想マシンとの問題を避けるには、ストレージプールを停止してから使用中のリソースをすべて解放するのが最良の方法です。
    # virsh pool-destroy guest_images_disk
  2. また、 ストレージプールがあるディレクトリーを削除したい場合は、 次のコマンドを使用します。
    # virsh pool-delete guest_images_disk
  3. ストレージプールの定義を削除する
    # virsh pool-undefine guest_images_disk

13.3. ディレクトリーベースのストレージプール

このセクションでは、ホスト物理マシンのディレクトリーにゲスト仮想マシンを格納する方法について説明します。
ディレクトリーベースのストレージプールは、virt-manager または virsh のコマンドラインツールで作成できます。

13.3.1. virt-manager を使用したディレクトリーベースのストレージプール作成

  1. ローカルのディレクトリーを作成します

    1. オプション: ストレージプール用に新規のディレクトリーを作成します

      ホスト物理マシン上にストレージプール用のディレクトリーを作成します。この例では、/guest virtual machine_images という名前のディレクトリーを作成しています。
      # mkdir /guest_images
    2. ディレクトリーの所有権を設定します

      ディレクトリーのユーザーとグループの所有権を変更します。ティレクトリーは root ユーザーが所有する必要があります。
      # chown root:root /guest_images
    3. ディレクトリーのアクセス権を設定します

      ディレクトリーのファイルアクセス権を変更します。
      # chmod 700 /guest_images
    4. 変更を確認します

      アクセス権が修正されていることを確認します。出力は正しく設定された空のディレクトリーを表示しています。
      # ls -la /guest_images
      total 8
      drwx------.  2 root root 4096 May 28 13:57 .
      dr-xr-xr-x. 26 root root 4096 May 28 13:57 ..
  2. SELinux のファイルコンテキストを設定します。

    SELinux の適切なコンテキストを新しいディレクトリーに設定します。プール名とディレクトリー名を一致させる必要はありませんが、ゲスト仮想マシンをシャットダウンする際に libvirt ではコンテキストをデフォルト値に戻さなければなりません。このデフォルト値はディレクトリーのコンテキストによって決定されます。したがって、ディレクトリーに「virt_image_t」のラベルを明示的に付けておくと、ゲスト仮想マシンがシャットダウンした際、そのイメージに「virt_image_t」のラベルが付けられるため、ホスト物理マシンで実行されている他のプロセスと区別できるようになります。
    # semanage fcontext -a -t virt_image_t '/guest_images(/.*)?'
    # restorecon -R /guest_images
  3. ストレージプール設定を開きます

    1. virt-manager グラフィカルインターフェースで、メインウィンドウからホスト物理マシンを選択します。
      編集 メニューを開き、接続の詳細 を選択します。
      接続の詳細ウィンドウ

      図13.7 接続の詳細ウィンドウ

    2. 接続の詳細 ウィンドウの ストレージ タブをクリックします。
      ストレージタブ

      図13.8 ストレージタブ

  4. 新しいストレージプールを作成します

    1. 新規のプールを追加します (パート1)。

      + ボタンを押します (プールの追加ボタン)。新規ストレージプールを追加 のウィザードが表示されます。
      ストレージプールの 名前 を選択します。この例では guest_images という名前を使用しています。種類dir: ファイルシステムディレクトリー にします。
      ストレージプールに名前を付ける

      図13.9 ストレージプールに名前を付ける

      進む ボタンを押して先に進みます。
    2. 新規のプールを追加します (パート2)。

      ターゲットパス フィールドを /guest_images などに変更します。
      詳細を確認して、完了 ボタンを押すと、ストレージプールが作成されます。
  5. 新しいストレージプールを確認します

    数秒後に、左側のストレージ一覧に新しいストレージプールが表示されます。予想通りのサイズが表示されていることを確認します。この例では、36.41 GB Free と表示されています。状態 フィールドに新しいストレージが Active と表示されていることを確認します。
    ストレージプールを選択します。自動起動 のフィールドで 起動時 のチェックボックスにチェックマークが付いていることを確認します。チェックマークが付いていると、libvirtd サービスの起動時は常にストレージプールも起動されます。
    ストレージプールの詳細を確認

    図13.10 ストレージプールの詳細を確認

    これでストレージプールが作成されました。接続の詳細 ウィンドウを閉じます。

13.3.2. virt-manager を使用したストレージプールの削除

この手順では、ストレージプールを削除する方法を説明します。
  1. 同じプールを使用する他のゲスト仮想マシンとの問題を避けるには、ストレージプールを停止して使用中のリソースをすべて解放するのが最良の方法です。これを実行するには、停止するストレージプールを選択して、ストレージウィンドウの下部にある赤い X アイコンをクリックします。
    停止アイコン

    図13.11 停止アイコン

  2. ゴミ箱アイコンをクリックしてストレージプールを削除します。このアイコンが使用できるのは、ストレージプールが停止している場合のみです。

13.3.3. virsh を使用したディレクトリーベースのストレージプールの作成

  1. ストレージプールの定義を作成します

    新規のストレージプールを定義するには、virsh pool-define-as コマンドを使用します。ディレクトリーベースのストレージプールの作成には 2 つのオプションが必要になります。
    • ストレージプールの 名前
      この例では guest_images という名前を使用しています。以下の例のこれ以降の virsh コマンドはすべてこの名前を使用します。
    • ゲストイメージファイル格納用のファイルシステムディレクトリーへの パス (このディレクトリーが存在しない場合は、virsh により作成されます)
      この例では /guest_images ディレクトリーを使用しています。
     # virsh pool-define-as guest_images dir - - - - "/guest_images"
    Pool guest_images defined
  2. ストレージプールが一覧表示されていることを確認します。

    ストレージプールが正しく作成されていること、また状態が inactive で表示されることを確認します。
    # virsh pool-list --all
    Name                 State      Autostart 
    -----------------------------------------
    default              active     yes       
    guest_images     inactive   no
  3. ローカルのディレクトリーを作成します

    以下のように、virsh pool-build コマンドを使用し、guest_images ディレクトリー (例) にディレクトリーベースのストレージプールをビルドします。
    # virsh pool-build guest_images
    Pool guest_images built
    # ls -la /guest_images
    total 8
    drwx------.  2 root root 4096 May 30 02:44 .
    dr-xr-xr-x. 26 root root 4096 May 30 02:44 ..
    # virsh pool-list --all
    Name                 State      Autostart 
    -----------------------------------------
    default              active     yes       
    guest_images     inactive   no
  4. ストレージプールを起動します

    virsh コマンドの pool-start を使ってディレクトリーストレージプールを有効にします。これにより、プールのボリュームがゲストのディスクイメージとして使用されます。
    # virsh pool-start guest_images
    Pool guest_images started
    # virsh pool-list --all
    Name                 State      Autostart 
    -----------------------------------------
    default             active     yes       
    guest_images    active     no
  5. autostart をオンにします

    ストレージプールに対して autostart をオンにします。Autostart は、サービスが開始する際にストレージプールを開始するように libvirtd サービスを設定します。
    # virsh pool-autostart guest_images
    Pool guest_images marked as autostarted
    # virsh pool-list --all
    Name                 State      Autostart 
    -----------------------------------------
    default              active     yes       
    guest_images         active     yes
  6. ストレージプール設定を確認します

    ストレージプールが正しく作成されたこと、サイズが正しく表示されていること、および状態が running と表示されていることなどを確認します。ゲスト仮想マシンが実行されていない場合でもプールにアクセスできるようにしておきたい場合には、Persistentyes が表示されていることを確認します。サービスの起動時にプールを自動的に起動させる場合は、Autostartyes が表示されていることを確認します。
    # virsh pool-info guest_images
    Name:           guest_images
    UUID:           779081bf-7a82-107b-2874-a19a9c51d24c
    State:          running
    Persistent:     yes
    Autostart:      yes
    Capacity:       49.22 GB
    Allocation:     12.80 GB
    Available:      36.41 GB
    
    # ls -la /guest_images
    total 8
    drwx------.  2 root root 4096 May 30 02:44 .
    dr-xr-xr-x. 26 root root 4096 May 30 02:44 ..
    #
これでディレクトリーベースのストレージプールが利用できるようになりました。

13.3.4. virsh を使用したストレージプールの削除

以下は、virsh を使ってストレージプールを削除する方法を説明しています。
  1. 同じプールを使用する他のゲスト仮想マシンとの問題を避けるには、ストレージプールを停止してから使用中のリソースをすべて解放するのが最良の方法です。
    # virsh pool-destroy guest_images_disk
  2. また、ストレージプールがあるディレクトリーを削除したい場合は、次のコマンドを使用します。
    # virsh pool-delete guest_images_disk
  3. ストレージプールの定義を削除します。
    # virsh pool-undefine guest_images_disk

13.4. LVM ベースのストレージプール

この章では、LVM ボリュームグループをストレージプールとして使用する方法について説明します。
LVM ベースのストレージグループでは、LVM の柔軟性を十分に利用することができます。

注記

現在、シンプロビジョニングは LVM ベースのストレージプールでは利用できません。

注記

LVM についての詳細は、『Red Hat Enterprise Linux ストレージ管理ガイド』 を参照してください。

警告

LVM ベースのストレージプールは全面的なディスクパーティションを必要とします。この手順を使用して新しいパーティションおよびデバイスをアクティブ化する場合、パーティションはフォーマットされ、すべてのデータは消去されます。ホストの既存ボリュームグループ (VG) を使用する場合は、いずれのデータも消去されません。以下の手順を開始する前に、ストレージデバイスのバックアップを取っておくことが推奨されます。

13.4.1. virt-manager を使用した LVM ベースのストレージプールの作成

LVM ベースのストレージプールでは既存の LVM ボリュームグループを使用するか、新規の LVM ボリュームグループを空のパーティションに作成して使用することができます。
  1. オプション: LVM ボリューム用に新規のパーティションを作成します

    以下のステップでは、新しいハードディスクドライブ上に新規のパーティション、および LVM ボリュームグループを作成する方法を説明します。

    警告

    以下の手順を実行すると、選択したストレージデバイスからすべてのデータが削除されます。
    1. 新規パーティションを作成します

      fdisk コマンドを使用して、コマンドラインから新しいディスクパーティションを作成します。以下の例では、ストレージデバイス /dev/sdb 上のディスク全体を使用する新しいパーティションを作成しています。
      # fdisk /dev/sdb
      Command (m for help):
      n を入力して、新規のパーティションを作成します。
    2. p を入力してプライマリーパーティションを選択します。
      Command action
         e   extended
         p   primary partition (1-4)
    3. 選択可能なパーティション番号を選択します。この例では、1 が入力され、1 番目のパーティションが選択されています。
      Partition number (1-4): 1
    4. Enter を押して、デフォルトの 1 番目のシリンダーを入力します。
      First cylinder (1-400, default 1):
    5. パーティションのサイズを選択します。この例では、Enter を押すことで、ディスク全域が割り当てられます。
      Last cylinder or +size or +sizeM or +sizeK (2-400, default 400):
    6. t を入力してパーティションのタイプを設定します。
      Command (m for help): t
    7. 前のステップで作成したパーティションを選択します。この例では、パーティション番号は 1 です。
      Partition number (1-4): 1
    8. Linux LVM パーティションの 8e を入力します。
      Hex code (type L to list codes): 8e
    9. 変更をディスクに書き込んで終了します。
      Command (m for help): w 
      Command (m for help): q
    10. 新規の LVM ボリュームガイドを作成します

      vgcreate コマンドで新しい LVMボリュームグループを作成します。この例では、guest_images_lvm という名前のボリュームグループを作成しています。
      # vgcreate guest_images_lvm /dev/sdb1
        Physical volume "/dev/vdb1" successfully created
        Volume group "guest_images_lvm" successfully created
    これで新規の LVM ボリュームグループ guest_images_lvm が LVM ベースのストレージプールに使用できるようになりました。
  2. ストレージプールの設定を開きます

    1. virt-manager グラフィカルインターフェースで、メインウィンドウからホストを選択します。
      編集 メニューを開いて、接続の詳細 を選択します。
      接続の詳細

      図13.12 接続の詳細

    2. ストレージ タブをクリックします。
      ストレージタブ

      図13.13 ストレージタブ

  3. 新しいストレージプールを作成します

    1. ウィザードを開始します

      + ボタン (プールの追加ボタン) を押します。新規ストレージプールの追加 ウィザードが表示されます。
      ストレージプール用に 名前 を選択します。この例では、guest_images_lvm を使用しています。 種類logical: LVM ボリュームグループ に変更します。
      LVM ストレージプールの追加

      図13.14 LVM ストレージプールの追加

      進む ボタンを押して先に進みます。
    2. 新規プールを追加します (パート 2)

      ターゲットパス フィールドを変更します。この例では、/guest_images を使用しています。
      次に、ターゲットパス フィールドと ソースパス フィールドに入力してから、プールを構築 のチェックボックスにチェックマークを付けます。
      • ターゲットパス フィールドを使用して、既存の LVM ボリュームグループか、または新規ボリュームグループの名前の いずれか を選択します。デフォルト形式は、/dev/storage_pool_name になります。
        この例では、/dev/guest_images_lvm という名前の新しいボリュームグループを使用しています。
      • 既存の LVM ボリュームグループが ターゲットパス で使用されている場合は、ソースパス フィールドはオプションになります。
        新規の LVM ボリュームグループの場合には、ストレージデバイスの場所を ソースパス フィールドに入力します。この例では、空のパーティション /dev/sdc を使用しています。
      • プールを構築 のチェックボックスにチェックマークを付けて、virt-manager に新規の LVM ボリュームグループを作成するよう指示します。既存のボリュームグループを使用する場合は、プールを構築 のチェックボックスは選択しないでください。
        この例では、空のパーティションを使用して新規のボリュームグループを作成しているため、プールを構築 のチェックボックスを選択しておく必要があります。
      ターゲットとソースの追加

      図13.15 ターゲットとソースの追加

      詳細を確認して 完了 ボタンを押すと、LVM ボリュームグループがフォーマットされ、ストレージプールが作成されます。
    3. フォーマットするデバイスを確認します

      警告メッセージが表示されます。
      警告メッセージ

      図13.16 警告メッセージ

      はい ボタンを押すと、ストレージデバイス上のすべてのデータが消去され、ストレージプールが作成されます。
  4. 新規のストレージプールを確認します

    数秒後に新しいストレージプールが左側の一覧に表示されます。詳細が予想通りであることを確認します。この例では、465.76 GB Free です。また、状態フィールドで新規ストレージプールが Active と報告されていることを確認します。
    通常は、自動起動 のチェックボックスにチェックマークを付けて有効にし、libvirtd でストレージプールが自動的に起動されるようにしておくと便利です。
    LVM ストレージプールの詳細確認

    図13.17 LVM ストレージプールの詳細確認

    これで作業は完了です。ホストの詳細ダイアログを閉じます。

13.4.2. virt-manager を使用したストレージプールの削除

以下の手順は、ストレージプールを削除する方法を説明しています。
  1. 同じプールを使用する他のゲスト仮想マシンとの問題を避けるには、ストレージプールを停止して使用中のリソースをすべて解放するのが最良の方法です。これを実行するには、停止するストレージプールを選択して、ストレージウィンドウの下部にある赤い X アイコンをクリックします。
    停止アイコン

    図13.18 停止アイコン

  2. ゴミ箱アイコンをクリックして、ストレージプールを削除します。このアイコンが使用できるのは、ストレージプールが停止している場合のみです。

13.4.3. virsh を使用した LVM ベースのストレージプールの作成

このセクションでは、virsh コマンドを使用して LVM ベースのストレージプールを作成する場合に必要な手順について簡単に説明します。ここでは、単一ドライブ (/dev/sdc) からの guest_images_lvm という名前のプールの例を使用しています。これは、説明用の例なので、実際の設定では適切な値に置き換えてください。

手順13.3 virsh を使用した LVM ベースのストレージプールの作成

  1. プール名 guest_images_lvm を定義します。
    # virsh pool-define-as guest_images_lvm logical - - /dev/sdc libvirt_lvm \ /dev/libvirt_lvm
    Pool guest_images_lvm defined
  2. 指定した名前に応じてプールを構築します。既存のボリュームグループをすでに使用している場合は、このステップを飛ばします。
    # virsh pool-build guest_images_lvm
    
    Pool guest_images_lvm built
  3. 新規のプールを初期化します。
    # virsh pool-start guest_images_lvm
    
    Pool guest_images_lvm started
  4. vgs コマンドを使用して、ボリュームグループ情報を表示します。
    # vgs
    VG          #PV #LV #SN Attr   VSize   VFree  
    libvirt_lvm   1   0   0 wz--n- 465.76g 465.76g
  5. プールが自動的に起動するよう設定します。
    # virsh pool-autostart guest_images_lvm
    Pool guest_images_lvm marked as autostarted
  6. virsh コマンドを使用して、利用可能なプールを一覧表示します。
    # virsh pool-list --all
    Name                 State      Autostart 
    -----------------------------------------
    default              active     yes       
    guest_images_lvm     active     yes
  7. 以下の一連のコマンドで、このプール内に 3 つのボリュームが作成されます (volume1volume2volume3)。
    # virsh vol-create-as guest_images_lvm volume1 8G
    Vol volume1 created
    
    # virsh vol-create-as guest_images_lvm volume2 8G
    Vol volume2 created
    
    # virsh vol-create-as guest_images_lvm volume3 8G
    Vol volume3 created
  8. virsh コマンドを使用して、このプール内の利用可能なボリュームを一覧表示します。
    # virsh vol-list guest_images_lvm
    Name                 Path
    -----------------------------------------
    volume1              /dev/libvirt_lvm/volume1
    volume2              /dev/libvirt_lvm/volume2
    volume3              /dev/libvirt_lvm/volume3
  9. 以下の 2 つのコマンド (lvscanlvs) を使用して、新たに作成されたボリュームに関する詳細情報を表示します。
    # lvscan
    ACTIVE            '/dev/libvirt_lvm/volume1' [8.00 GiB] inherit
    ACTIVE            '/dev/libvirt_lvm/volume2' [8.00 GiB] inherit
    ACTIVE            '/dev/libvirt_lvm/volume3' [8.00 GiB] inherit
    
    # lvs
    LV       VG            Attr     LSize   Pool Origin Data%  Move Log Copy%  Convert
    volume1  libvirt_lvm   -wi-a-   8.00g
    volume2  libvirt_lvm   -wi-a-   8.00g
    volume3  libvirt_lvm   -wi-a-   8.00g

13.4.4. virsh を使用したストレージプールの削除

以下では、virsh を使ってストレージプールを削除する方法を説明しています。
  1. 同じプールを使用する他のゲストとの問題を避けるには、ストレージプールを停止してから使用中のリソースをすべて解放するのが最良の方法です。
    # virsh pool-destroy guest_images_disk
  2. また、ストレージプールがあるディレクトリーを削除したい場合は、次のコマンドを使用します。
    # virsh pool-delete guest_images_disk
  3. ストレージプールの定義を削除します。
    # virsh pool-undefine guest_images_disk

13.5. iSCSI ベースのストレージプール

このセクションでは、iSCSI ベースのデバイスを使用してゲスト仮想マシンを格納する方法を説明します。
iSCSI (Internet Small Computer System Interface) とは、ストレージデバイスを共有するためのネットワークプロトコルです。iSCSI では、IP 層全体で SCSI の指示を使用してイニシエーター (ストレージクライアント) をターゲット (ストレージサーバー) に接続します。

13.5.1. ソフトウェア iSCSI ターゲットの設定

ソフトウェア支援の iSCSI ターゲットを作成できるツールは、scsi-target-utils パッケージで提供されます。

手順13.4 iSCSI ターゲットを作成します

  1. 必要なパッケージをインストールします

    scsi-target-utils パッケージおよび依存するすべてのパッケージをインストールします。
    # yum install scsi-target-utils
  2. tgtd サービスを起動します

    tgtd サービスは、ホスト物理マシンの SCSI ターゲットを提供し、ホスト物理マシンのターゲットに対して iSCSI プロトコルを使用します。tgtd サービスを起動してから、chkconfig コマンドで再起動すると、そのサービスを永続化することができます。
    # service tgtd start
    # chkconfig tgtd on
  3. オプション: LVM ボリュームを作成します

    LVM ボリュームは、iSCSI のバッキングイメージに役に立ちます。LVM のスナップショットやサイズ変更は、ゲスト仮想マシンにとって便利な機能です。この例では、iSCSI でゲスト仮想マシンをホストするために RAID5 アレイ上の virtstore という名前の新規ボリュームグループ上に virtimage1 という名前の LVM イメージを作成しています。
    1. RAID アレイを作成する

      ソフトウェア RAID5 アレイの作成については 『Red Hat Enterprise Linux 導入ガイド』 を参照してください。
    2. LVM ボリュームグループを作成する

      vgcreate コマンドを使用して virtstore という名前のボリュームグループを作成します。
      # vgcreate virtstore /dev/md1
    3. LVM 論理ボリュームを作成する

      lvcreate コマンドを使用して、 virtimage1 という名前の論理ボリュームグループを 20GB のサイズで virtstore ボリュームグループ上に作成します。
      # lvcreate --size 20G -n virtimage1 virtstore
      これで、新規論理ボリュームの virtimage1 を iSCSI に使用する準備が整いました。
  4. オプション: ファイルベースのイメージを作成します

    ファイルベースのストレージはテスト用としては十分ですが、実稼働環境や I/O アクティビティーが活発な環境には推奨できません。このオプションの手順では、iSCSI ターゲット用に virtimage2.img という名前のファイルベースイメージを作成します。
    1. イメージ用の新規のディレクトリーを作成する

      イメージを格納するための新規ディレクトリーを作成します。このディレクトリーには適切な SELinux コンテキストを設定する必要があります。
      # mkdir -p /var/lib/tgtd/virtualization
    2. イメージファイルを作成する

      virtimage2.img という名前のイメージを 10GB のサイズで作成します。
      # dd if=/dev/zero of=/var/lib/tgtd/virtualization/virtimage2.img bs=1M seek=10000 count=0
    3. SELinux ファイルコンテキストを設定する

      新規のイメージとディレクトリーに適切な SELinux コンテキストを設定します。
      # restorecon -R /var/lib/tgtd
      これで、新規のファイルベースのイメージ virtimage2.img を iSCSI に使用する準備が整いました。
  5. ターゲットを作成します

    ターゲットは、/etc/tgt/targets.conf ファイルに XML エントリーを追加することで作成できます。target 属性には IQN (iSCSI Qualified Name) が必要になります。IQN は以下の形式になります。
    iqn.yyyy-mm.reversed domain name:optional identifier text
    ここで、
    • yyyy-mm は、デバイスが起動された年と月を示します (例: 2010-05)。
    • reversed domain name は、ホスト物理マシンの逆になったドメイン名 (たとえば、IQN の server1.example.com の場合は com.example.server1) です。
    • optional identifier text は、テキストの文字列になります。空白は入れません。管理者がデバイスやハードウェアの特定を行なう場合に便利です。
    この例では、オプションの手順で server1.example.com 上に作成した 2 種類のイメージ用に iSCSI ターゲットを作成し、オプションの識別子 trial を設定しています。以下の行を /etc/tgt/targets.conf ファイルに追加します。
    <target iqn.2010-05.com.example.server1:iscsirhel6guest>
       backing-store /dev/virtstore/virtimage1  #LUN 1
       backing-store /var/lib/tgtd/virtualization/virtimage2.img  #LUN 2
       write-cache off
    </target>
    ドライバータイプが iSCSI に設定されるよう、/etc/tgt/targets.conf ファイルに default-driver iscsi の行が含まれていることを確認してください。ドライバーはデフォルトで iSCSI を使用します。

    重要

    この例では、アクセス制御を持たないグローバルにアクセス可能なターゲットを作成します。安全なアクセスの実装に関しては、scsi-target-utils を参照してください。
  6. tgtd サービスを再起動します

    tgtd サービスを再起動して、設定の変更を再読み込みします。
    # service tgtd restart
  7. iptables の設定を行います

    iptables を使用して iSCSI アクセス用にポート 3260 を開きます。
    # iptables -I INPUT -p tcp -m tcp --dport 3260 -j ACCEPT
    # service iptables save
    # service iptables restart
  8. 新規のターゲットを確認します

    tgt-admin --show コマンドを使用して、新規ターゲットを表示させ、セットアップが正しく行なわれていることを確認します。
    # tgt-admin --show
    Target 1: iqn.2010-05.com.example.server1:iscsirhel6guest
    System information:
    Driver: iscsi
    State: ready
    I_T nexus information:
    LUN information:
    LUN: 0
        Type: controller
        SCSI ID: IET     00010000
        SCSI SN: beaf10
        Size: 0 MB
        Online: Yes
        Removable media: No
        Backing store type: rdwr
        Backing store path: None
    LUN: 1
        Type: disk
        SCSI ID: IET     00010001
        SCSI SN: beaf11
        Size: 20000 MB
        Online: Yes
        Removable media: No
        Backing store type: rdwr
        Backing store path: /dev/virtstore/virtimage1
    LUN: 2
        Type: disk
        SCSI ID: IET     00010002
        SCSI SN: beaf12
        Size: 10000 MB
        Online: Yes
        Removable media: No
        Backing store type: rdwr
        Backing store path: /var/lib/tgtd/virtualization/virtimage2.img
    Account information:
    ACL information:
    ALL

    警告

    ACL 一覧はすべて (all) にセットされています。これにより、ローカルネットワーク上のすべてのシステムがこのデバイスにアクセス可能になります。実稼働環境には、ホスト物理マシンのアクセス ACL を設定することが推奨されています。
  9. オプション: 検出テスト

    新規の iSCSI デバイスが検出可能かどうかを検証します。
    # iscsiadm --mode discovery --type sendtargets --portal server1.example.com
    127.0.0.1:3260,1 iqn.2010-05.com.example.server1:iscsirhel6guest
  10. オプション: デバイス接続テスト

    新規デバイス (iqn.2010-05.com.example.server1:iscsirhel6guest) を接続して、デバイスの接続が可能かどうかを検証します。
    # iscsiadm -d2 -m node --login
    scsiadm: Max file limits 1024 1024
    
    Logging in to [iface: default, target: iqn.2010-05.com.example.server1:iscsirhel6guest, portal: 10.0.0.1,3260]
    Login to [iface: default, target: iqn.2010-05.com.example.server1:iscsirhel6guest, portal: 10.0.0.1,3260] successful.
    デバイスを切り離します。
    # iscsiadm -d2 -m node --logout
    scsiadm: Max file limits 1024 1024
    
    Logging out of session [sid: 2, target: iqn.2010-05.com.example.server1:iscsirhel6guest, portal: 10.0.0.1,3260
    Logout of [sid: 2, target: iqn.2010-05.com.example.server1:iscsirhel6guest, portal: 10.0.0.1,3260] successful.
これで、iSCSI デバイスを仮想化に使用する準備が整いました。

13.5.2. virt-manager に iSCSI ターゲットを追加する

以下の手順は、virt-manager で iSCSI ターゲットを持つストレージプールを作成する方法を説明しています。

手順13.5 iSCSI デバイスを virt-manager に追加する

  1. ホスト物理マシンのストレージタブを開きます

    接続の詳細 ウィンドウ内の ストレージ タブを開きます。
    1. virt-manager を開きます
    2. メイン virt-manager ウィンドウからホスト物理マシンを選択します。編集 メニューをクリックして、接続の詳細 を選択します。
      接続の詳細

      図13.19 接続の詳細

    3. ストレージ タブをクリックします。
      ストレージメニュー

      図13.20 ストレージメニュー

  2. 新規のプールを追加します (パート 1)

    + ボタン (プールの追加ボタン) を押します。新規ストレージプールの追加 ウィザードが表示されます。
    iscsi ストレージプールの名前と種類を追加

    図13.21 iscsi ストレージプールの名前と種類を追加

    ストレージプールの名前を選択して、種類を iscsi に変更し、進む を押して先に進みます。
  3. 新規のプールを追加します (パート 2)

    このメニューのフィールドに記載する情報として、「iSCSI ベースのストレージプール」 および ステップ 5 で使用した情報が必要になります。
    1. iSCSI ソースおよびターゲットを入力します。フォーマットはゲスト仮想マシンが処理するため、フォーマット オプションは選択できません。さらに、ターゲットパス を編集することは推奨されていません。デフォルトのターゲットパスの値 /dev/disk/by-path/ は、ドライブパスをそのディレクトリーに追加します。ターゲットパスは、移行に関してすべてのホスト物理マシン上で同一である必要があります。
    2. iSCSI ターゲットのホスト名、または IP アドレスを入力します。この例では、host1.example.com を使用します。
    3. ソースパス フィールドには、iSCSI ターゲット IQN を入力します。「iSCSI ベースのストレージプール」ステップ 5 を参照すると、これは /etc/tgt/targets.conf file に追加した情報であることが分かります。この例では、iqn.2010-05.com.example.server1:iscsirhel6guest を使用しています。
    4. IQN チェックボックスにチェックを入れて、イニシエーターの IQN を入力します。この例では、iqn.2010-05.com.example.server1:iscsirhel6guest を使用しています。
    5. 完了 をクリックすると、新規のストレージプールが作成されます。
    iscsi ストレージプールの作成

    図13.22 iscsi ストレージプールの作成

13.5.3. virt-manager を使用したストレージプールの削除

以下の手順は、ストレージプールを削除する方法を説明しています。
  1. 同じプールを使用する他のゲスト仮想マシンとの問題を避けるには、ストレージプールを停止して使用中のリソースをすべて解放するのが最良の方法です。これを実行するには、停止するストレージプールを選択して、ストレージウィンドウの下部にある赤い X アイコンをクリックします。
    停止アイコン

    図13.23 停止アイコン

  2. ゴミ箱アイコンをクリックしてストレージプールを削除します。このアイコンが使用できるのは、ストレージプールが停止している場合のみです。

13.5.4. virsh を使用した iSCSI ベースのストレージプールの作成

  1. pool-define-as を使用してコマンドラインからプールを定義します

    ストレージプールの定義は、virsh コマンドラインツールで作成できます。virsh を使ったストレージプール作成は、複数のストレージプールをスクリプトで作成しているシステム管理者にとって便利です。
    virsh pool-define-as コマンドにはパラメーターがいくつかあり、以下の形式で使用します。
    virsh pool-define-as name type source-host source-path source-dev source-name target
    以下でパラメーターについて説明します。
    type
    iscsi などの、特定のタイプでプールを定義します。
    name
    ストレージプールの名前を指定し、固有の名前にしてください。
    source-host と source-path
    ホスト名と iSCSI IQN です。
    source-dev と source-name
    iSCSI ベースのプールにはこれらのパラメーターは必要ありません、 - 文字を使ってこのフィールドは空白にします。
    target
    ホスト物理マシン上に iSCSI デバイスをマウントする場所を定義します。
    以下の例では、以前のステップと同じ iSCSI ベースのストレージプールを作成しています。
    #   virsh pool-define-as --name scsirhel6guest --type iscsi \
         --source-host server1.example.com \
         --source-dev iqn.2010-05.com.example.server1:iscsirhel6guest
         --target /dev/disk/by-path
    Pool iscsirhel6guest defined
  2. ストレージプールが一覧表示されていることを確認します

    ストレージプールオブジェクトが正しく作成されたことや、状態が inactive として報告されることを確認します。
    # virsh pool-list --all
    Name                 State      Autostart 
    -----------------------------------------
    default              active     yes       
    iscsirhel6guest      inactive   no
  3. ストレージプールを起動します

    これには virsh コマンド pool-start を使用します。pool-start はディレクトリーストレージプールを有効にして、ボリュームとゲスト仮想マシン用に使用できるようにします。
    # virsh pool-start guest_images_disk
    Pool guest_images_disk started
    # virsh pool-list --all
    Name                 State      Autostart 
    -----------------------------------------
    default              active     yes       
    iscsirhel6guest      active     no
  4. autostart をオンにします

    ストレージプールの autostart をオンにします。 Autostart により、libvirtd サービスの起動時にストレージプールも起動するよう設定されます。
    # virsh pool-autostart iscsirhel6guest
    Pool iscsirhel6guest marked as autostarted
    iscsirhel6guest プールに autostart が設定されていることを確認します。
    # virsh pool-list --all
    Name                 State      Autostart 
    -----------------------------------------
    default              active     yes       
    iscsirhel6guest      active     yes
  5. ストレージプールの設定を確認します

    ストレージプールが正しく作成されたことや、サイズが正しく報告されていること、および状態が running として報告されていることを確認します。
    # virsh pool-info iscsirhel6guest
    Name:           iscsirhel6guest
    UUID:           afcc5367-6770-e151-bcb3-847bc36c5e28
    State:          running
    Persistent:     unknown
    Autostart:      yes
    Capacity:       100.31 GB
    Allocation:     0.00
    Available:      100.31 GB
これで iSCSI ベースのストレージプールが使用できるようになりました。

13.5.5. virsh を使用したストレージプールの削除

以下は、virsh を使ってストレージプールを削除する方法を説明しています。
  1. 同じプールを使用する他のゲスト仮想マシンとの問題を避けるには、ストレージプールを停止してから使用中のリソースをすべて解放するのが最良の方法です。
    # virsh pool-destroy guest_images_disk
  2. ストレージプールの定義を削除します。
    # virsh pool-undefine guest_images_disk

13.6. NFS ベースのストレージプール

以下の手順は、virt-manager で NFS マウントポイントを持つストレージプールを作成する方法を説明しています。

13.6.1. virt-manager を使用した NFS ベースストレージプールの作成

  1. ホスト物理マシンのストレージタブを開きます

    接続の詳細 ウィンドウ内の ストレージ タブを開きます。
    1. virt-manager を開きます
    2. メイン virt-manager ウィンドウからホスト物理マシンを選択します。編集 メニューをクリックして、接続の詳細 を選択します。
      接続の詳細

      図13.24 接続の詳細

    3. ストレージタブをクリックします。
      ストレージタブ

      図13.25 ストレージタブ

  2. 新規のプールを作成します (パート 1)

    + ボタン (プールの追加ボタン) を押します。新規ストレージプールの追加 ウィザードが表示されます。
    NFS の名前と種類を追加

    図13.26 NFS の名前と種類を追加

    ストレージプールの名前を選択して、進む を押して先に進みます。
  3. 新規のプールを作成します (パート 2)

    デバイスのターゲットパス、ホスト名、および NFS 共有パスを入力します。フォーマット オプションを NFS または auto (タイプの検出) に設定します。ソースパスは移行に関連するすべてのホスト物理マシン上で同一でなければなりません。
    NFS サーバーのホスト名または IP アドレスを入力します。この例では、server1.example.com を使用しています。
    NFS パスを入力します。この例では、/nfstrial を使用しています。
    NFS ストレージプールの作成

    図13.27 NFS ストレージプールの作成

    完了 を押すと、新規のストレージプールが作成されます。

13.6.2. virt-manager を使用したストレージプールの削除

以下の手順は、ストレージプールを削除する方法を説明しています。
  1. 同じプールを使用する他のゲストとの問題を避けるため、ストレージプールを停止して使用中のリソースをすべて解放するのが最適です。停止するストレージプールを選択して、ストレージウィンドウの下部にある赤い X アイコンをクリックします。
    停止アイコン

    図13.28 停止アイコン

  2. ゴミ箱アイコンをクリックしてストレージプールを削除します。このアイコンが使用できるのは、ストレージプールが停止している場合のみです。

13.7. GlusterFS ストレージプール

このセクションでは、GlusterFS ベースのストレージプールを有効にする方法について記載しています。Red Hat Enterprise Linux 6.5 には、GlusterFS を使った仮想マシン作成のネイティブサポートがあります。GlusterFS は FUSE を使用するユーザー領域のファイルシステムです。これがゲスト仮想マシンで有効にされると、KVM ホスト物理マシンは 1 つ以上の GlusterFS ストレージボリュームからゲスト仮想マシンのイメージを起動し、GlusterFS ストレージボリュームのイメージをゲスト仮想マシンのデータディスクとして使用できます。

注記

詳細は、『Red Hat ストレージ管理ガイド』 を参照してください。

13.7.1. virsh を使用した GlusterFS ストレージプールの作成

このセクションでは、Gluster サーバーとアクティブな Gluster ボリュームを準備する方法について説明します。

手順13.6 Gluster サーバーとアクティブな Gluster ボリュームの準備

  1. 次のコマンドを使って、状態を一覧表示し、Gluster サーバーの IP アドレスを取得します。
    # gluster volume status
    Status of volume: gluster-vol1
    Gluster process						Port	Online	Pid
    ------------------------------------------------------------------------------
    Brick 222.111.222.111:/gluster-vol1 			49155	Y	18634
     
    Task Status of Volume gluster-vol1
    ------------------------------------------------------------------------------
    There are no active volume tasks
  2. まだこれを実行していない場合は、glusterfs-fuse をインストールしてから virt_use_fusefs を有効にします。次に、以下のコマンドを実行して、Gluster サーバーに接続する 1 つのホストを用意します。
    # setsebool virt_use_fusefs on
    # getsebool virt_use_fusefs
    virt_use_fusefs --> on
    
  3. pool typegluster に指定し、Gluster ストレージプール (以下の例では glusterfs-pool.xml) を設定するために新しい XML ファイルを作成し、以下のデータを追加します。
    			
    <pool type='gluster'>
    	<name>glusterfs-pool</name>
    	<source>
    		<host name='111.222.111.222'/>
    		<dir path='/'/>
    		<name>gluster-vol1</name>
    	</source>
    </pool>
    
    

    図13.29 GlusterFS XML ファイルの内容

  4. 次のコマンドを使って、Gluster プールを定義し、これを開始します。
    # virsh pool-define glusterfs-pool.xml 
    Pool gluster-pool defined from glusterfs-pool.xml
    
    # virsh pool-list --all
    Name                 State      Autostart 
    -----------------------------------------       
    gluster-pool         inactive   no              
    
    # virsh pool-start gluster-pool
    Pool gluster-pool started
    
    # virsh pool-list --all
    Name                 State      Autostart 
    -----------------------------------------      
    gluster-pool         active     no  
    
    # virsh vol-list gluster-pool
    Name                 Path                                    
    -----------------------------------------
    qcow2.img            gluster://111.222.111.222/gluster-vol1/qcow2.img
    raw.img              gluster://111.222.111.222/gluster-vol1/raw.img

13.7.2. virsh を使用した GlusterFS ストレージプールの削除

このセクションでは、virsh を使ってストレージプールを削除する方法について詳しく説明します。

手順13.7 GlusterFS ストレージプールの削除

  1. 次のコマンドを使って、ストレージプールの状態を非アクティブに設定します。
    
     # virsh pool-destroy gluster-pool
    Pool gluster-pool destroyed
  2. 次のコマンドを使って、プールが非アクティブの状態であることを確認します。
    # virsh pool-list --all
    Name                 State      Autostart 
    -----------------------------------------     
    gluster-pool         inactive   no
  3. 次のコマンドを使って GlusterFS ストレージプールの定義を解除します。
    # virsh pool-undefine gluster-pool
    Pool gluster-pool has been undefined
  4. 次のコマンドを使ってプールの定義が解除されていることを確認します。
    # virsh pool-list --all
    Name                 State      Autostart 
    -----------------------------------------
    

13.8. SCSI デバイスで NPIV 仮想アダプター (vHBA) を使用する

NPIV (N_Port ID Virtualization) とは、単一の物理的なファイバーチャンネルホストバスアダプター (HBA) の共有を可能にするソフトウェア技術です。
これにより複数のゲストが複数の物理ホストから同一のストレージを見ることが可能になり、ストレージの移行パスが容易になります。このため、適切なストレージパスが指定されていれば、移行でストレージを作成したりコピーしたりする必要がありません。
仮想化では、仮想ホストバスアダプター (vHBA) が仮想マシンの LUN を制御します。各 vHBA は、独自の WWNN (World Wide Node Name) と WWPN (World Wide Port Name) で識別されます。ストレージへのパスは、WWNN と WWPN の値で決定されます。
このセクションでは、仮想マシン上で vHBA を設定する方法について説明します。Red Hat Enterprise Linux 6 では、ホストの再起動後における vHBA 設定維持をサポートしていません。ホストの再起動後は、vHBA 関連の設定を確認してください。

13.8.1. vHBA の作成

手順13.8 vHBA の作成

  1. ホストシステム上で HBA を見つける

    ホストシステム上で HBA を見つけるには、ホストシステム上の SCSI デバイスを調べて、vport 機能のある scsi_host を探します。
    以下のコマンドを実行して scsi_host リストを表示します。
    # virsh nodedev-list --cap scsi_host
    scsi_host0
    scsi_host1
    scsi_host2
    scsi_host3
    scsi_host4
    scsi_host で以下のコマンドを実行し、デバイス XML で <capability type='vport_ops'> の行を調べます。これは、vport 機能のある scsi_host を示します。
    # virsh nodedev-dumpxml scsi_hostN
  2. HBA の詳細を確認する

    virsh nodedev-dumpxml HBA_device コマンドを使って HBA の詳細をチェックします。
    virsh nodedev-dumpxml コマンドからの XML 出力では、<name><wwnn>、および <wwpn> のフィールドが一覧表示されます。これらは vHBA の作成に使用されます。<max_vports> の値は、サポートされる vHBA の最大数を示します。
     # virsh nodedev-dumpxml scsi_host3
    <device>
      <name>scsi_host3</name>
      <path>/sys/devices/pci0000:00/0000:00:04.0/0000:10:00.0/host3</path>
      <parent>pci_0000_10_00_0</parent>
      <capability type='scsi_host'>
        <host>3</host>
        <capability type='fc_host'>
          <wwnn>20000000c9848140</wwnn>
          <wwpn>10000000c9848140</wwpn>
          <fabric_wwn>2002000573de9a81</fabric_wwn>
        </capability>
        <capability type='vport_ops'>
          <max_vports>127</max_vports>
          <vports>0</vports>
        </capability>
      </capability>
    </device>
    この例では、<max_vports> 値は HBA 設定で使用できる 127 の仮想ポートがあることを示しています。<vports> 値は、現在使用中の仮想ポートの数を示します。これらの値は、vHBA 作成後に更新されます。
  3. vHBA ホストデバイスの作成

    vHBA ホスト用に以下のような XML ファイルを作成します (この例では、ファイル名 vhba_host3.xml)。
    # cat vhba_host3.xml
       <device>
         <parent>scsi_host3</parent>
         <capability type='scsi_host'>
           <capability type='fc_host'>
           </capability>
         </capability>
       </device>
    <parent> フィールドでは、この vHBA デバイスに関連付ける HBA デバイスを指定します。<device> タグ内の詳細は、ホスト用の vHBA デバイスを作成するために次のステップで使用します。nodedev XML 形式についての詳細は、http://libvirt.org/formatnode.html を参照してください。
  4. vHBA ホストデバイス上で新規 vHBA を作成する

    vhba_host3 上で vHBA を作成するには、virsh nodedev-create コマンドを使用します。
    # virsh nodedev-create vhba_host3.xml
    Node device scsi_host5 created from vhba_host3.xml
  5. vHBA の確認

    新規 vHBA (scsi_host5) の詳細を virsh nodedev-dumpxml コマンドで確認します。
    # virsh nodedev-dumpxml scsi_host5
    <device>
      <name>scsi_host5</name>
      <path>/sys/devices/pci0000:00/0000:00:04.0/0000:10:00.0/host3/vport-3:0-0/host5</path>
      <parent>scsi_host3</parent>
      <capability type='scsi_host'>
        <host>5</host>
        <capability type='fc_host'>
          <wwnn>5001a4a93526d0a1</wwnn>
          <wwpn>5001a4ace3ee047d</wwpn>
          <fabric_wwn>2002000573de9a81</fabric_wwn>
        </capability>
      </capability>
    </device>

13.8.2. vHBA を使用してストレージプールを作成する

vHBA 設定を保持するには、vHBA に基づく libvirt ストレージプールを定義することが推奨されます。
ストレージプールの使用には、以下の 2 つの利点があります。
  • libvirt コードにより、virsh コマンド出力で LUN のパスを容易に特定できます。
  • 仮想マシンの移行には、ターゲットマシン上に同じ vHBA 名を持つストレージプールを定義し、起動することのみが必要になります。これを実行するには、vHBA LUN、libvirt ストレージプールおよびボリューム名を仮想マシンの XML 設定で指定する必要があります。この例については、「仮想マシンが vHBA LUN を使用するよう設定する」 を参照してください。
  1. SCSI ストレージプールの作成

    vHBA 設定を作成するには、まず以下の形式を使用して vHBA に基づく libvirt 'scsi' ストレージプールの XML ファイルを作成します。

    注記

    ストレージプール設定では、ホスト名に 手順13.8「vHBA の作成」 で作成した vHBA を使用し、vHBA 名 scsi_hostNhostN に修正してください。ここの例では vHBA の名前は scsi_host5 となり、これは Red Hat Enterprise Linux 6 libvirt ストレージプールでは <adapter name='host5'/> と指定されます。
    <path> の値には、ご使用のシステム上の /dev/disk/by-{path|id|uuid|label} のいずれかなど、安定した場所を使用することが推奨されます。 <path><target> 内の要素についての詳細は、http://libvirt.org/formatstorage.html を参照してください。
    以下の例では、'scsi' ストレージプールの名前は vhbapool_host3.xml となっています。
      <pool type='scsi'>
         <name>vhbapool_host3</name> 
         <uuid>e9392370-2917-565e-692b-d057f46512d6</uuid>
         <capacity unit='bytes'>0</capacity>
         <allocation unit='bytes'>0</allocation>
         <available unit='bytes'>0</available>
         <source>
           <adapter name='host5'/> 
         </source>
          <target>
            <path>/dev/disk/by-path</path>
            <permissions>
              <mode>0700</mode>
              <owner>0</owner>
              <group>0</group>
            </permissions>
          </target>
        </pool>
  2. プールの定義

    ストレージプール (この例では vhbapool_host3 という名前) を定義するには、virsh pool-define コマンドを使用します。
             # virsh pool-define vhbapool_host3.xml
             Pool vhbapool_host3 defined from vhbapool_host3.xml
  3. プールの起動

    以下のコマンドでストレージプールを起動します。
    # virsh pool-start vhbapool_host3
    Pool vhbapool_host3 started
  4. autostart の有効化

    最後に、この後のホストの起動で仮想マシンで使用される vHBA が自動的に定義されるようにするために、ストレージプールの autostart 機能を設定します (この例では、プールの名前は vhbapool_host3 です)。
    # virsh pool-autostart vhbapool_host3

13.8.3. 仮想マシンが vHBA LUN を使用するよう設定する

vHBA のストレージプールを作成したら、vHBA LUN を仮想マシンの設定に追加します。
  1. 利用可能な LUN を探す

    まず、virsh vol-list コマンドを使用して、vHBA 上で利用可能な LUN を一覧表示します。
    # virsh vol-list vhbapool_host3
     Name                 Path                                    
    ------------------------------------------------------------------------------
     unit:0:4:0           /dev/disk/by-path/pci-0000:10:00.0-fc-0x5006016844602198-lun-0
     unit:0:5:0           /dev/disk/by-path/pci-0000:10:00.0-fc-0x5006016044602198-lun-0
    表示された LUN 名の一覧は、仮想マシン設定内でディスクボリュームとして使用できます。
  2. vHBA LUN を仮想マシンに追加する

    仮想マシンの XML で以下を指定して、vHBA LUN を仮想マシンに追加します。
    • <disk> パラメーターでデバイスタイプを lun または disk に指定します。
    • さらに、ソースデバイスを <source> パラメーターで指定します。これは、/dev/sdaN とするか、/dev/disk/by-path|by-id|by-uuid|by-label 内の udev が生成したシンボリックリンクとすることができます。virsh vol-list pool コマンドを実行するとこれが見つかります。
    以下に例を示します。
       <disk type='block' device='lun'>
         <driver name='qemu' type='raw'/>
         <source dev='/dev/disk/by-path/pci-0000\:04\:00.1-fc-0x203400a0b85ad1d7-lun-0'/>
         <target dev='sda' bus='scsi'/>
       </disk>
    
    

13.8.4. vHBA ストレージプールの破棄

vHBA ストレージプールは、virsh pool-destroy コマンドで破棄することができます。
# virsh pool-destroy vhbapool_host3
以下のコマンドで vHBA を削除します。
# virsh nodedev-destroy scsi_host5
プールと vHBA が破棄されたことを確認するには、以下のコマンドを実行します。
# virsh nodedev-list --cap scsi_host
scsi_host5 はリストに表示されなくなります。

第14章 ボリューム

14.1. ボリュームの作成

このセクションでは、ブロックベースのストレージプール内にディスクボリュームを作成する方法について説明します。以下の例では、virsh vol-create-as コマンドを使って guest_images_disk ストレージプール内に GB 単位の特定サイズのストレージボリュームを作成します。このコマンドは必要とされるボリュームごとに繰り返し使用する必要があり、ここでは例として 3 つのボリュームを作成します。
# virsh vol-create-as guest_images_disk volume1 8G
Vol volume1 created

# virsh vol-create-as guest_images_disk volume2 8G
Vol volume2 created

# virsh vol-create-as guest_images_disk volume3 8G
Vol volume3 created

# virsh vol-list guest_images_disk
Name                 Path
-----------------------------------------
volume1              /dev/sdb1
volume2              /dev/sdb2
volume3              /dev/sdb3

# parted -s /dev/sdb print
Model: ATA ST3500418AS (scsi)
Disk /dev/sdb: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
2      17.4kB  8590MB  8590MB               primary
3      8590MB  17.2GB  8590MB               primary
1      21.5GB  30.1GB  8590MB               primary

14.2. ボリュームのクローン作成

新しいボリュームは、クローン元となるボリュームと同じストレージプール内のストレージから割り当てられます。virsh vol-clone には、--pool の引数を設定します。この引数でクローン元となるボリュームを含むストレージプール名を指示します。コマンドの残りの部分では、クローン元となるボリューム (volume3) とクローン作成される新しいボリューム (clone1) の名前を指定します。virsh vol-list コマンドを使って、ストレージプール (guest_images_disk) 内に現在あるボリュームの一覧を表示します。
# virsh vol-clone --pool guest_images_disk volume3 clone1
Vol clone1 cloned from volume3

# virsh vol-list guest_images_disk
Name                 Path                                    
-----------------------------------------
volume1              /dev/sdb1                               
volume2              /dev/sdb2                               
volume3              /dev/sdb3
clone1               /dev/sdb4
                               

# parted -s /dev/sdb print
Model: ATA ST3500418AS (scsi)
Disk /dev/sdb: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    File system  Name     Flags
1      4211MB  12.8GB  8595MB  primary
2      12.8GB  21.4GB  8595MB  primary
3      21.4GB  30.0GB  8595MB  primary
4      30.0GB  38.6GB  8595MB  primary

14.3. ゲストにストレージデバイスを追加する

このセクションでは、ゲストにストレージデバイスを追加する方法を説明します。必要なストレージのみを追加することができます。

14.3.1. ゲストにファイルベースのストレージを追加する

ファイルベースのストレージは、ホスト物理マシンのファイルシステム上に格納されるファイルの集合であり、ゲストに対して仮想化されたハードドライブとして動作します。ファイルベースのストレージを追加するには、次の手順を実行します。

手順14.1 ファイルベースのストレージを追加する

  1. ストレージファイルを作成するか、または既存のファイルを使用します (IMG ファイルなど)。以下のコマンドはどちらもゲスト用の追加ストレージとして使用できる 4GB のファイルを作成します。
    • ファイルベースのストレージイメージには、事前割り当てのファイルを使用することを推奨します。以下のように dd コマンドを使って事前割り当てのファイルを作成します。
      # dd if=/dev/zero of=/var/lib/libvirt/images/FileName.img bs=1M count=4096
    • または、事前割り当てファイルの代わりにスパースファイルを作成することもできます。スパースファイルの方が作成にかかる時間が短く、テストなどに適しています。ただし、データの整合性やパフォーマンス関連の問題があるため、実稼働環境には推奨できません。
      # dd if=/dev/zero of=/var/lib/libvirt/images/FileName.img bs=1M seek=4096 count=0
  2. 新しいファイルに <disk> 要素を記述して追加のストレージを作成します。この例では、このファイル名は NewStorage.xml になります。
    <disk> 要素は、ディスクのソースと仮想ブロックデバイスのデバイス名を記述します。デバイス名はゲスト内のすべてのデバイスに対して固有の名前にしてください。このデバイス名によってゲストが仮想ブロックデバイスを検索するバスが特定されます。以下の例では、FileName.img という名前のファイルベースのストレージコンテナーがソースとなる virtio ブロックデバイスを定義しています。
    <disk type='file' device='disk'>
       <driver name='qemu' type='raw' cache='none'/>
       <source file='/var/lib/libvirt/images/FileName.img'/>
       <target dev='vdb'/>
    </disk>
    デバイス名は、IDE や SCSI ディスクを指定する「hd」や「sd」から始まる名前にすることもできます。設定ファイルには <address> サブ要素を含め、バス上の新しいデバイスの位置を指定することもできます。virtio ブロックデバイスの場合に、これは PCI アドレスになるはずです。<address> サブ要素を省略すると、livbirt により次に使用できる PCI スロットの検索および割り当てが行なわれます。
  3. 以下のように CD-ROM を割り当てます。
    <disk type='file' device='cdrom'>
       <driver name='qemu' type='raw' cache='none'/>
       <source file='/var/lib/libvirt/images/FileName.img'/>
       <readonly/>
       <target dev='hdc'/>
    </disk >
  4. NewStorage.xml に定義されているデバイスをゲスト (Guest1) に追加します。
    # virsh attach-device --config Guest1 ~/NewStorage.xml

    注記

    この変更は、ゲストが破棄され、再起動した後にしか反映されません。また、永続デバイスを追加できるのは永続ドメインに対してのみになります。永続ドメインとは、その設定が virsh define コマンドを使って保存されているドメインのことです。
    ゲストが実行中で、そのゲストが破棄されるまでの間に新しいデバイスを一時的に追加したい場合は --config オプションを省略します。
    # virsh attach-device Guest1 ~/NewStorage.xml

    注記

    virsh コマンドでは attach-disk コマンドを使用することができます。このコマンドでは、より簡単な構文で限定された数のパラメーターを設定でき、XML ファイルを作成する必要がありません。以下に示すように、attach-disk コマンドは前述の attach-device コマンドと同じように使用されます。
    # virsh attach-disk Guest1 /var/lib/libvirt/images/FileName.img vdb --cache none
    virsh attach-disk コマンドも --config オプションを受け入れることに注意してください。
  5. ゲストマシンを開始します (まだ稼働していない場合):
    # virsh start Guest1

    注記

    以下のステップは Linux ゲストに固有なステップです。他のオペレーティングシステムでは、異なる方法で新規のストレージデバイスを処理します。他のシステムについては、そのオペレーティングシステムのドキュメントを参照してください。
  6. ディスクドライブのパーティション設定

    ここでゲストには /dev/vdb というハードディスクデバイスが設定されています。必要であれば、このディスクドライブにパーティションを設定し、パーティションをフォーマットします。追加したデバイスが表示されない場合、それはゲストのオペレーティングシステムにディスクのホットプラグに関する問題が発生していることを示します。
    1. 新規デバイスに対して fdisk を開始します。
      # fdisk /dev/vdb
      Command (m for help):
    2. 新規パーティション作成の n を入力します。
    3. 次のように出力されます。
      Command action
      e   extended
      p   primary partition (1-4)
      プライマリパーティションを作成するために p を入力します。
    4. 使用できるパーティション番号を選択します。この例では、1 が入力され、1 番目のパーティションが選択されています。
      Partition number (1-4): 1
    5. Enter を押して、デフォルトとなる 1 番目のシリンダーを選択します。
      First cylinder (1-400, default 1):
    6. パーティションのサイズを選択します。この例では、Enter を押して、ディスク全体が割り当てられています。
      Last cylinder or +size or +sizeM or +sizeK (2-400, default 400):
    7. t を入力して、パーティションタイプを設定します。
      Command (m for help): t
    8. 前のステップで作成したパーティションを選択します。この例では、パーティション番号が 1 のパーティションを選択しています。この例で作成されたパーティションは 1 つのみのため、fdisk によって自動的にパーティション 1 が選択されています。
      Partition number (1-4): 1
    9. Linux パーティションの 83 を入力します。
      Hex code (type L to list codes): 83
    10. w を入力して、変更を書き込み、終了します。
      Command (m for help): w
    11. ext3 ファイルシステムで新しいパーティションをフォーマットします。
      # mke2fs -j /dev/vdb1
  7. マウントディレクトリーを作成して、ゲスト上にディスクをマウントします。この例では、ディレクトリーは myfiles にあります。
    # mkdir /myfiles
    # mount /dev/vdb1 /myfiles
    これで、ゲストは仮想化されたファイルベースの追加ストレージデバイスを持つことになります。ただし、このストレージはゲストの /etc/fstab ファイルで定義されない限り、再起動後にも永続化するようにマウントされない点に注意してください。
    /dev/vdb1    /myfiles    ext3     defaults    0 0

14.3.2. ゲストにハードドライブと他のブロックデバイスを追加する

システム管理者は、ゲスト用にストレージ領域を拡張したり、システムデータをユーザーデータから分離したりするために追加のハードドライブを使用します。

手順14.2 ゲストに物理ブロックデバイスを追加する

  1. この手順は、ホスト物理マシン上のハードドライブをゲストに追加する方法を説明しています。これは、CD-ROM、DVD、およびフロッピーデバイスを含むすべてての物理ブロックデバイスに適用されます。
    ホスト物理マシンにハードディスクデバイスを物理的に接続します。ドライブにデフォルトでアクセスできない場合、ホスト物理マシンを設定します。
  2. 次のいずれかを行ないます。
    1. 新しいファイル内に disk 要素を記述して追加のストレージを作成します。この例では、このファイル名は NewStorage.xml です。次の例は、ホスト物理マシンのパーティション /dev/sr0: 用のデバイスベースの追加ストレージコンテナーが含まれる設定ファイルのセクションになります。
      <disk type='block' device='disk'>
            <driver name='qemu' type='raw' cache='none'/>
            <source dev='/dev/sr0'/>
            <target dev='vdc' bus='virtio'/>
      </disk>
    2. 直前のセクションの指示に従って、デバイスをゲスト仮想マシンにアタッチします。または、以下のように virsh attach-disk コマンドを使用することもできます。
      # virsh attach-disk Guest1 /dev/sr0 vdc
      次のオプションが利用できます。
      • 以下のように、virsh attach-disk コマンドも --config--type、および --mode オプションを受け入れます。
        virsh attach-disk Guest1 /dev/sr0 vdc --config --type cdrom --mode readonly
      • また、デバイスがハードドライブの場合には、 --type--type disk も受け入れます。
  3. これで、ゲスト仮想マシンは、Linux では /dev/vdc など (ゲスト仮想マシンの OS の選択によって異なる)、Windows では D: ドライブ という名前の新しいハードディスクデバイスを持つことになり、ゲスト仮想マシンのオペレーティングシステムに適した標準的な手順に従ってゲスト仮想マシンからディスクを初期化できるようになります。例については、手順14.1「ファイルベースのストレージを追加する」 および ステップ 6 を参照してください。

    警告

    ホスト物理マシンでは、ファイルシステムを特定するために、fstab ファイルや、initrd ファイルままたはカーネルコマンドラインなどでファイルシステムのラベルを使用しないようにしてください。ゲスト仮想マシンなど特権を持たないユーザーがパーティションや LVM ボリューム全体への書き込みアクセス権を持つ場合、ファイルシステムのラベルを使用するとセキュリティー上のリスクが発生します。ゲスト仮想マシンが、ホスト物理マシンに属するファイルシステムのラベルを、自らのブロックデバイスストレージに書き込む可能性があるためです。これにより、ホスト物理マシンの再起動時に、ホスト物理マシンがこのゲスト仮想マシンのディスクをシステムディスクとして誤って使用してしまう可能性があり、ホスト物理マシンシステムが危険にさらされる可能性があります。
    fstab ファイルや、initrd ファイルまたはカーネルコマンドラインなどでデバイスを特定するにはその UUID を使用した方がよいでしょう。ただし、特定のファイルシステムでは UUID の使用が完全に安全である訳ではありませんが、UUID を使用した場合には同様のセキュリティー上のリスクは確実に低くなります。

    重要

    ゲスト仮想マシンはディスク全域、またはブロックデバイス全域 (例: /dev/sdb) に書き込みアクセスを持つべきではありません。ブロックデバイス全域にアクセスを持つゲスト仮想マシンはボリュームラベルを修正できる場合があり、これがホスト物理マシンシステムの攻撃に使用される可能性があります。パーティション (例: /dev/sdb1) または LVM ボリュームを使用して、この問題を回避してください。

missing step

dynamic adding paragraph

14.4. ボリュームの消去と削除

このセクションでは、virsh vol-delete コマンドを使って、ブロックベースのストレージプールからディスクボリュームを削除する方法を説明します。この例では、ボリュームは volume 1 で、ストレージプールは guest_images です。
# virsh vol-delete --pool guest_images volume1
Vol volume1 deleted

第15章 virsh を使用したゲスト仮想マシンの管理

virsh は、ゲスト仮想マシンとハイパーバイザーの管理に使用するコマンドラインインターフェースです。virsh コマンドラインツールは、libvirt 管理 API をベースにして構築されており、qemu-kvm コマンドやグラフィカルな virt-manager アプリケーションの代替として機能します。virsh コマンドは、通常のユーザーには読み取り専用モードで使用されますが、root アクセス権を持つユーザーは完全な管理機能を使用できます。virsh コマンドは、仮想化管理のスクリプトを作成する際に最適です。

15.1. 一般的なコマンド

このセクションに記載するコマンドは、いずれかのドメインに固有のものではないため、一般的なコマンドになります。

15.1.1. help

$ virsh help [command|group] help コマンドはオプションと共に、またはオプションなしで使用できます。オプションなしで使用すると、すべてのコマンドが各行に 1 つずつ一覧表示されます。オプションと共に使用される場合は、一覧はカテゴリーにグループ化され、各グループのキーワードが表示されます。
特定のオプションに該当するコマンドのみを表示するには、そのグループのキーワードをオプションとして指定する必要があります。以下のようになります。
$ virsh help pool
 Storage Pool (help keyword 'pool'):
    find-storage-pool-sources-as   find potential storage pool sources
    find-storage-pool-sources      discover potential storage pool sources
    pool-autostart                 autostart a pool
    pool-build                     build a pool
    pool-create-as                 create a pool from a set of args
    pool-create                    create a pool from an XML file
    pool-define-as                 define a pool from a set of args
    pool-define                    define (but don't start) a pool from an XML file
    pool-delete                    delete a pool
    pool-destroy                   destroy (stop) a pool
    pool-dumpxml                   pool information in XML
    pool-edit                      edit XML configuration for a storage pool
    pool-info                      storage pool information
    pool-list                      list pools
    pool-name                      convert a pool UUID to pool name
    pool-refresh                   refresh a pool
    pool-start                     start a (previously defined) inactive pool
    pool-undefine                  undefine an inactive pool
    pool-uuid                      convert a pool name to pool UUID
この同じコマンドをコマンドオプションと共に使用すると、その特定のコマンドオプションについての help 情報が表示されます。以下のようになります。
$virsh help vol-path
  NAME
    vol-path - returns the volume path for a given volume name or key

  SYNOPSIS
    vol-path <vol> [--pool <string>]

  OPTIONS
    [--vol] <string>  volume name or key
    --pool <string>  pool name or uuid

15.1.2. quit と exit

quit コマンドと exit コマンドはターミナルを閉じます。以下のようになります。
$virsh exit
$virsh quit

15.1.3. version

version コマンドは現在の libvirt バージョンを表示し、ビルドについての情報を表示します。以下のようになります。
$ virsh version
Compiled against library: libvirt 1.1.1
Using library: libvirt 1.1.1
Using API: QEMU 1.1.1
Running hypervisor: QEMU 1.5.3

15.1.4. 引数の表示

virsh echo [--shell][--xml][arg] は、指定した引数を表示します。表示される各引数はスペースで区切られます。--shell オプションを使用すると、出力は必要に応じて単一引用符で囲まれるため、シェルコマンドで再利用するのに適しています。--xml オプションを使用すると、出力は XML ファイルでの使用に適したものになります。たとえば、virsh echo --shell "hello world" コマンドの出力は、'hello world' となります。

15.1.5. connect

ハイパーバイザーセッションに接続します。シェルが最初に起動する際、このコマンドは URI パラメーターが -c コマンドによって要求されると自動的に実行されます。URI は、ハイパーバイザーに接続する方法を指定します。最もよく使用される URI は以下になります。
  • xen:/// - ローカルの Xen ハイパーバイザーに接続します。
  • qemu:///system - QEMU および KVM ドメインを監視するデーモンに root としてローカルに接続します。
  • xen:///session - ユーザーの QEMU および KVM ドメインのセットにユーザーとしてローカル接続します。
  • lxc:/// - ローカルの Linux コンテナーに接続します。
他の値については libvert の web サイト (http://libvirt.org/uri.html) を参照してください。
コマンドは以下のように実行できます。
$virsh connect {name|URI}
ここでの {name} は、マシン名 (ホスト名) またはハイパーバイザーの URL (virsh uri コマンドの出力) です。読み取り専用の接続を開始するには、上記のコマンドに --readonly を追加します。URI についての詳細は、リモート URI を参照してください。URI が不明な場合は、virsh uri コマンドを実行すると、表示されます。
$ virsh uri
qemu:///session

15.1.6. 基本的な情報の表示

以下のコマンドは、基本情報を表示するために使用できます。
  • $ hostname - ハイパーバイザーのホスト名を表示します。
  • $ sysinfo - ハイパーバイザーのシステム情報の XML 表現 (ある場合) を表示します。

15.1.7. NMI の挿入

$ virsh inject-nmi [domain] は NMI (マスクが不可能な割り込み) メッセージをゲスト仮想マシンに挿入します。これは、修復不能なハードウェアエラーなどの迅速な応答時間が重要となる場合に使用されます。このコマンドを実行するには、以下のようにします。
$ virsh inject-nmi guest-1

15.2. virsh を使ったデバイスの割り当てと更新

ストレージデバイスの割り当てについての詳細は、「ゲストにファイルベースのストレージを追加する」を参照してください。

手順15.1 ゲスト仮想マシンが使用する USB デバイスのホットプラグ

以下の手順は、USB デバイスをゲスト仮想マシンにアタッチする方法について説明しています。これは、ゲスト仮想マシンの実行中にホットプラグ手順として実行することも、ゲストの停止中に実行することもできます。エミュレートするデバイスは、ホスト物理マシンに割り当てられている必要があります。
  1. 以下のコマンドを使って、割り当てる USB デバイスを特定します。
    # lsusb -v
    
    idVendor           0x17ef Lenovo
    idProduct          0x480f Integrated Webcam [R5U877]
    
  2. XML ファイルを作成し、そのファイルに論理名 (例: usb_device.xml) を指定します。ベンダーと製品 ID は、検索時に表示されたものと全く同じものをコピーするようにしてください。
    
       <hostdev mode='subsystem' type='usb' managed='yes'>
          <source>
            <vendor id='0x17ef'/>
            <product id='0x480f'/>
          </source>
        </hostdev>
      ...

    図15.1 USB デバイス XML スニペット

  3. 以下のコマンドを使って、デバイスを割り当てます。
    # virsh attach-device rhel6 --file usb_device.xml> --config
    この例では、[rhel6] はゲスト仮想マシンの名前で、[usb_device.xml] は直前のステップで作成したファイルです。次回の起動時に変更を有効にする場合は、--config オプションを使用します。変更を永続化させる場合は、--persistent オプションを使用します。変更を現在のドメインで有効にする場合は、--current オプションを使用します。詳細情報は、Virsh の man ページを参照してください。
  4. デバイスを切り離す場合 (ホットアンプラグ) は、以下のコマンドを実行します。
    # virsh detach-device rhel6 --file usb_device.xml>
    この例の [rhel6] はゲスト仮想マシンの名前で、[usb_device.xml] は直前のステップで割り当てたファイルです。

15.3. インターフェースデバイスの割り当て

virsh attach-interfacedomain type source コマンドは以下のオプションを取ります。
  • --live - 実行中のドメインから値を取得します
  • --config - 次回起動時に使用される値を取得します
  • --current - ドメインの現在の状態に基づいて値を取得します
  • --persistent - オフラインのドメインについては --config のように動作し、実行中のドメインについては --live のように動作します。
  • --target - ゲスト仮想マシン内のターゲットデバイスを指定します。
  • --mac - ネットワークインターフェースの MAC アドレスを指定するには、これを使用します。
  • --script - デフォルトのスクリプトファイルの代わりにブリッジを処理するスクリプトファイルへのパスを指定するには、これを使用します。
  • --model - モデルのタイプを指定するには、これを使用します。
  • --inbound - インターフェースの受信帯域幅を制御します。使用できる値は、averagepeak、および burst です。
  • --outbound - インターフェースの送信帯域幅を制御します。使用できる値は、averagepeak、および burst です。
type は、物理ネットワークデバイスを指定する場合は network か、デバイスへのブリッジを指定する場合は bridge のいずれかにすることができます。source はデバイスのソースです。割り当てられたデバイスを除去するには、virsh detach-device を使用します。

15.4. CDROM メディアの変更

CDROM のメディアを別のソースまたはフォーマットに変更します。
# change-media domain path source --eject --insert --update --current --live --config --force
  • --path - ディスクデバイスの完全修飾パスまたはターゲットを含む文字列です
  • --source - メディアのソースを含む文字列です
  • --eject - メディアを取り出します
  • --insert - メディアを挿入します
  • --update - メディアを更新します
  • --current - ハイパーバイザードライバーの実装によって、--live--config のいずれかまたはその両方にすることができます。
  • --live - 実行中のドメインの動作中の設定を変更します
  • --config - 永続的な設定を変更します。次回起動時に反映されます
  • --force - メディアの変更を強制します

15.5. ドメインコマンド

これらのコマンドのほとんどは指定されたドメインを直接操作するため、ドメイン名が必要になります。ドメインは、短整数 (short integer)(0,1,2...)、名前、または完全な UUID で指定される場合があります。

15.5.1. 起動時に自動的に起動するようにドメインを設定

$ virsh autostart [--disable] domain は、起動時に指定されたドメインを自動的に起動します。--disable オプションを使用すると、autostart が無効になります。
# virsh autostart rhel6
上記の例では、rhel6 ゲスト仮想マシンは、ホスト物理マシンの起動時に自動的に起動します。
# virsh autostart rhel6--disable
上記の例では、autostart 機能は無効にされているため、ゲスト仮想マシンは、ホスト物理マシンの起動時にも自動的に起動しません。

15.5.2. ゲスト仮想マシンのシリアルコンソールの接続

$ virsh console <domain> [--devname <string>] [--force] [--safe] コマンドは、ゲスト仮想マシンの仮想シリアルコンソールを接続します。オプションの --devname <string> パラメーターは、ゲスト仮想マシンに設定された代替コンソールのデバイスエイリアス、シリアルまたはパラレルデバイスを参照します。このパラメーターが省略されると、プライマリーコンソールが開かれます。--force オプションは、コンソールの接続を強制するか、または disconnect と一緒に使用される場合は、接続を切断します。--safe オプションを使用すると、安全なコンソール処理がサポートされている場合のみゲストの接続を許可します。
$ virsh console virtual_machine --safe

15.5.3. XML ファイルによるドメインの定義

define <FILE> コマンドは XML ファイルのドメインを定義します。この場合、ドメイン定義は登録されますが、起動しません。ドメインがすでに実行されている場合は、変更は次回の起動時に有効になります。

15.5.4. ドメインの説明またはタイトルの編集および表示

virsh desc [domain-name] [[--live] [--config] | [--current]] [--title] [--edit] [--new-desc New description or title message] コマンドは、ドメインの説明およびタイトルを表示するか、変更するために使用されますが、ドメインの設定をするものではありません。これらの値は、ドメインの識別を容易にする任意のテキストデータを保存するためのユーザーフィールドです。libvirt は強制しませんが、タイトルは短くすることが望まれます。
--live または --config のオプションは、このコマンドがドメインの稼働中の定義または永続的な定義で機能するかどうかを選択します。--live--config の両方が指定されると、--config オプションが最初に実行され、その場合、コマンドに入力されたものが新規設定となり、現行設定および永続的設定の両方にこれが適用されます。--current オプションは、現行設定を変更するか取得しますが、永続化はされません。 --live--config、または --current のいずれも指定されていない場合は、--current オプションが使用されます。--edit オプションは、現在の説明またはタイトルのコンテンツのあるエディターが開かれた後に、コンテンツが保存されることを指定します。--title オプションを使用すると、ドメインのタイトルフィールドのみを表示または修正し、説明は含まれません。さらに、--edit または --new-desc のいずれも指定されない場合は、説明が表示されますが、これを変更することはできません。
たとえば、コマンド $ virsh desc testvm --current --title TestVM-4F --new-desc Guest VM on fourth floor は、ゲスト仮想マシンのタイトルを testvm から TestVM-4F に変更し、説明も Guest VM on fourth floor に変更します。

15.5.5. デバイスブロック統計の表示

このコマンドは、実行中のドメインのブロック統計を表示します。ドメイン名とデバイス名の両方が必要になります (virsh domblklist を使用してデバイスを一覧表示)。この場合、ブロックデバイスは一意のターゲット名 (<target dev='name'/>) またはソースファイル (< source file ='name'/>) です。すべてのフィールドを表示できないハイパーバイザーもあることに注意してください。出力が最も読みやすい形式で表示されるようにするには、以下に示すように --human オプションを使用します。
# virsh domblklist rhel6
Target     Source
------------------------------------------------
vda        /VirtualMachines/rhel6.img
hdc        -

# virsh domblkstat --human rhel6 vda
Device: vda
 number of read operations:      174670
 number of bytes read:           3219440128
 number of write operations:     23897
 number of bytes written:        164849664
 number of flush operations:     11577
 total duration of reads (ns):   1005410244506
 total duration of writes (ns):  1085306686457
 total duration of flushes (ns): 340645193294

15.5.6. ネットワーク統計の取得

domnetstat [domain][interface-device] コマンドは、所定ドメインで実行中の指定されたデバイスについてのネットワークインターフェース統計を表示します。
# domifstat rhel6 eth0

15.5.9. ネットワークインターフェース帯域幅パラメーターの設定

domiftune は、ゲスト仮想マシンのネットワークインターフェース帯域幅パラメーターを設定します。以下の形式を使用してください。
#virsh domiftune domain interface-device [[--config] [--live] | [--current]] [--inbound average,peak,burst] [--outbound average,peak,burst]
必要なパラメーターはゲスト仮想マシンのドメイン名およびインターフェースデバイスのみであり、--config--live、および --current は、「スケジュールパラメーターの設定」の場合と同様に機能します。制限が設定されない場合、現在のネットワークインターフェースの設定を照会します。それ以外の場合は、以下のフラグで制限を変更してください。
  • <interface-device> これは必須であり、ドメインのネットワークインターフェースの帯域幅パラメーターを設定するか、または照会します。interface-device は、インターフェースのターゲット名 (<target dev=’name’/>)、または MAC アドレスにすることができます。
  • --inbound または --outbound のいずれも指定されていない場合、このコマンドは帯域幅の設定を照会するか、または表示します。それ以外の場合は、受信または送信帯域幅を設定します。average、peak、burst は attach-interface コマンドの場合と同様になります。「インターフェースデバイスの割り当て」を参照してください。

15.5.10. 実行中ドメインのメモリー統計の取得

このコマンドは、使用しているハイパーバイザーによって異なる結果を返す場合があります。
dommemstat [domain] [--period (sec)][[--config][--live]|[--current]] は、実行中のドメインのメモリー統計を表示します。--period オプションを使用する場合は、秒単位の時間を指定する必要があります。このオプションを 0 より大きな値に設定すると、バルーンドライバーから後続の domemstat コマンドで表示される追加の統計を返すことができるようになります。--period オプションを 0 に設定すると、バルーンドライバーの収集は停止されますが、バルーンドライバーの統計は消去されません。さらにバルーンドライバーの収集期間を設定するために--live--config、または --current オプションを使用する場合、必ず --period オプションを設定する必要があります。--live オプションが指定されている場合、実行中のゲストの収集期間のみが影響を受けます。--config オプションが使用されている場合は、永続的なゲストの次回の起動に影響を与えます。--current オプションが使用されている場合、現行ゲストの状態が影響を受けます。
--live および --config の両方のオプションを使用できますが、--current は排他的になります。フラグが指定されていない場合、ゲストの状態によって動作は異なります。
#virsh domemstat rhel6--current

15.5.11. ブロックデバイスのエラーの表示

このコマンドは、I/O エラーのためにドメインが一時停止になっていることを報告する domstate の後に使用することが最も適しています。domblkerror domain コマンドは所定ドメインのエラー状態にあるすべてのブロックデバイスを表示し、デバイスが報告しているエラーメッセージを表示します。
# virsh domblkerror rhel6

15.5.12. ブロックデバイス容量の表示

以下の場合、ブロックデバイスは固有なターゲット名 (<target dev='name'/>) またはソースファイル (< source file ='name'/>) になります。一覧を取得するには、domblklist を実行できます。この domblkinfo には domain 名が必要です。
# virsh domblkinfo rhel6

15.5.13. ドメインに関連付けられたブロックデバイスの表示

domblklist domain --inactive--details は、指定されたドメインに関連付けられたすべてのブロックデバイスの表を表示します。
--inactive が指定されている場合、結果には、次回起動時に使用されるデバイスが表示され、実行中ドメインによって使用されている現在実行中のデバイスは表示されません。--details が指定されている場合、ディスクタイプおよびデバイス値は表に組み込まれます。この表に表示される情報は、domblkinfo および snapshot-create と共に使用することができます。
#domblklist rhel6 --details

15.5.14. ドメインに関連付けられた仮想インターフェースの表示

domiflist コマンドを実行すると、指定されたドメインに関連付けられているすべての仮想インターフェースの情報を表示する表が作成されます。domiflist には、domain 名が必要で、--inactive オプションを取ることができます。
--inactive が指定される場合は、結果には、次回起動時に使用されるデバイスが表示され、実行中ドメインによって使用されている現在実行中のデバイスは表示されません。
仮想インターフェースの MAC アドレス (detach-interface または domif-setlink など) が必要なコマンドは、このコマンドで表示される出力を受け入れます。

15.5.15. blockcommit を使用したバッキングチェーンの短縮化

このセクションでは、virsh blockcommit を使用してバッキングチェーンを短縮する方法について説明します。バッキングチェーンの背景情報については、「ライブブロックコピーによるディスクイメージの管理」を参照してください。
blockcommit は、チェーンの一部にあるデータをバッキングファイルにコピーし、コミットされた部分をバイパスするためにチェーンの残りの部分をピボットします。たとえば、以下が現在の状態であるとします。
      base ← snap1 ← snap2 ← active.
blockcommit を使用して、snap2 のコンテンツを snap1 に移行します。これにより、チェーンから snap2 を削除でき、より迅速にバックアップを作成することができます。

手順15.2 virsh blockcommit

  • 次のコマンドを実行します。
    # virsh blockcommit $dom $disk -base snap1 -top snap2 -wait -verbose
    snap2 のコンテンツが snap1 に移行します。以下のようになります。
    base ← snap1 ← active。Snap2 は無効になり、削除することができません。

    警告

    blockcommit は、-base オプションに依存するすべてのファイル を破損させます (-top オプションに依存するファイルを除く。これらは base を指しているため)。これを防ぐには、複数のゲストが共有するファイルへの変更をコミットしないでください。-verbose オプションを使用すると、進捗状況が画面に出力されます。

15.5.16. blockpull を使用したバッキングチェーンの短縮化

blockpull は、以下のように応用して使用することができます。
  • イメージにそのバッキングイメージチェーンのデータを設定することにより、イメージをフラット化します。これにより、イメージファイルはバッキングイメージやこれに類するものに依存しなくてすむような自己完結型のファイルになります。
    • 使用前: base.img ← Active
    • 使用後: ゲストによる base.img の使用がなくなり、Active にすべてのデータが含まれます。
  • バッキングイメージチェーンの一部をフラット化します。この部分はスナップショットをトップレベルのイメージにフラット化するために使用でき、以下のようになります。
    • 使用前: base ← sn1 ←sn2 ← active
    • 使用後: base.img ← active。active には sn1 および sn2 からの全データが含まれ、ゲストは sn1 も sn2 も使用しません。
  • ディスクのイメージをホスト上の新規ファイルシステムに移動します。これにより、ゲストの実行中にイメージファイルを移動できます。以下のようになります。
    • 使用前 (元のイメージファイル): /fs1/base.vm.img
    • 使用後: /fs2/active.vm.qcow2 が新規ファイルシステムで、/fs1/base.vm.img は使用されません。
  • ポストコピー型ストレージ移行のライブマイグレーションで役立ちます。ディスクイメージは、ライブマイグレーションの完了後にソースホストから移行先ホストにコピーされます。
    つまり、以下のようになります。過去:/source-host/base.vm.img 今後:/destination-host/active.vm.qcow2/source-host/base.vm.img は使用されなくなります。

手順15.3 blockpull を使用したバッキングチェーンの短縮化

  1. blockpull を実行する前に以下のコマンドを実行すると便利です。
    # virsh snapshot-create-as $dom $name - disk-only
  2. チェーンが base ← snap1 ← snap2 ← active となっている場合、以下を実行します。
    # virsh blockpull $dom $disk snap1
    このコマンドは、データを snap2 から active にプルしてから base ← snap1 ← active の状態にすることにより、'snap1' を active のバッキングファイルにします。
  3. blockpull が完了すると、チェーン内の追加イメージを作成したスナップショットの libvirt 追跡は役に立たなくなります。以下のコマンドを使って、古くなったスナップショットの追跡を削除します。
    # virsh snapshot-delete $dom $name - metadata
blockpull のその他の応用は、以下のように実行できます。
  • 単一イメージをフラット化し、これにそのバッキングイメージチェーンのデータを設定する: # virsh blockpull example-domain vda - wait
  • バッキングイメージチェーンの一部をフラット化する: # virsh blockpull example-domain vda - base /path/to/base.img - wait
  • ディスクイメージをホスト上の新規ファイルシステムに移動する: # virsh snapshot-create example-domain - xmlfile /path/to/new.xml - disk-only、およびその後の # virsh blockpull example-domain vda - wait
  • ポストコピー型ストレージ移行のライブマイグレーションを使用する方法:
    • 移行先で以下を実行:
       # qemu-img create -f qcow2 -o backing_file=/source-host/vm.img /destination-host/vm.qcow2
    • ソースで以下を実行:
      # virsh migrate example-domain
    • 移行先で以下を実行:
      # virsh blockpull example-domain vda - wait

15.5.17. blockresize を使用したドメインパスのサイズ変更

blockresize を使用して、ドメインの実行中にドメインのブロックデバイスのサイズを変更することができます。この際、固有のターゲット名 (<target dev="name"/>) またはソースファイル (<source file="name"/>) にも対応するブロックデバイスの絶対パスを使用します。これは、ドメインに割り当てられているディスクデバイスのいずれかに適用できます (コマンド domblklist を使用して、所定ドメインに関連付けられたすべてのブロックデバイスの簡単な情報を表示する表を出力できます)。

注記

ライブのイメージサイズの変更により、イメージのサイズは常に変更されますが、この変更はゲストによって即時に反映されない場合があります。最新のカーネルでは、virtio-blk デバイスのサイズは自動的に更新されます (旧式のカーネルではゲストの再起動が必要です)。SCSI では、コマンド echo > /sys/class/scsi_device/0:0:0:0/device/rescan を使って、ゲスト内の再スキャンを手動でトリガーすることが求められます。さらに IDE の場合、ゲストが新たなサイズを反映する前にゲストを再起動しておく必要があります。
  • 以下のコマンドを実行します: blockresize [domain] [path size] ここで、
    • ドメインは、サイズを変更するドメインのファイルの固有のターゲット名またはソースファイルです。
    • サフィックスがない場合、パスサイズはデフォルトで KiB (1024 バイトブロック単位) になる単位付き整数です。バイトについては、「B」のサフィックスを使用する必要があります。

15.5.18. ライブブロックコピーによるディスクイメージの管理

注記

ライブブロックコピーは、Red Hat Enterprise Linux で提供される KVM のバージョンでサポートされる機能です。ライブブロックコピーは、Red Hat Virtualization で提供される KVM のバージョンで利用できます。この機能がサポートされるには、KVM のこのバージョンが物理ホストマシン上で実行されている必要がります。詳細は、Red Hat の担当者にお問い合わせください。
ライブブロックコピーにより、ゲストの実行中に、使用中のゲストディスクイメージを移行先イメージにコピーでき、ゲストディスクイメージを移行先ゲストイメージに切り替えることができます。ライブマイグレーションではメモリーおよびレジストリー状態のホストを移動する間、ゲストは共有ストレージに保持されます。ライブブロックコピーでは、ゲストの実行中に、ゲストのコンテンツ全体を別のホストにオンザフライで移動できます。また、ライブブロックコピーは、永続的な共有ストレージを必要とすることなく、ライブマイグレーションに使用することもできます。この方法では、ディスクイメージは移行後に移行先ホストにコピーされますが、ゲストの実行中にこれが行なわれます。
ライブブロックコピーは、以下のように適用する場合にとくに便利です。
  • ローカルストレージから集中管理できる場所にゲストイメージを移動する
  • メンテナンスが必要な場合に、パフォーマンスを低下させることなく、ゲストを別の場所に転送する
  • イメージをスピードと効率を維持した状態でゲストイメージを管理する
  • ゲストをシャットダウンせずにイメージのフォーマット変換を実行する

例15.1 ライブブロックコピーの使用例

以下の例は、ライブブロックコピーの実行時にどのようになるかを示しています。この例では、ソースと移行先の間で共有されるバッキングファイルがあります。さらに、ソースにのみ 2 つのオーバーレイ (sn1 および sn2) があり、これらはコピーする必要があります。
  1. 開始時のバッキングファイルチェーンは以下のようになります。
    base ← sn1 ← sn2
    コンポーネントは以下のようになります。
    • base - 元のディスクイメージ
    • sn1 - base ディスクイメージから取られた最初のスナップショット
    • sn2 - 最新のスナップショット
    • active - ディスクのコピー
  2. イメージのコピーが sn2 の上に新規イメージとして作成されると、結果は以下のようになります。
    base ← sn1 ← sn2 ← active
  3. この時点で、読み取りアクセス権はすべて正しい順序にあり、自動的に設定されます。書き込みアクセス権が適切に設定されていることを確認するために、ミラーメカニズムがすべての書き込みを sn2 と active の両方にリダイレクトし、sn2 と active がいつでも同じ内容を読み込めるようにします (また、このミラーメカニズムが、ライブブロックコピーとイメージストリーミングの間の本質的な違いになります)。
  4. すべてのディスククラスターにループするバックグラウンドタスクが実行されます。それぞれのクラスターについては、以下のケースおよびアクションが考えられます。
    • クラスターは active ですでに割り当てられており、とくに実行すべきことはない。
    • bdrv_is_allocated() を使用し、バッキングファイルチェーンをフォローする。クラスターが (共有される) base から読み込まれる場合、とくに実行すべきことはない。
    • bdrv_is_allocated() のバリアントが実行可能でない場合、イメージをリベースし、コピーが必要かどうかを決定するために、読み込みデータをベースの書き込みデータと比較する。
    • 上記以外のすべてのケースでは、クラスターを active にコピーする
  5. コピーが完了したら、active のバッキングファイルが base に切り替わります (リベースと同様)。
一連のスナップショット後にバッキングチェーンの長さを短縮するには、以下のコマンドが役立ちます: blockcommit および blockpull。詳細は、「blockcommit を使用したバッキングチェーンの短縮化」を参照してください。

15.5.19. グラフィカル表示への接続用の URI の表示

virsh domdisplay コマンドを実行すると、URI が出力されます。これを使用して、VNC、SPICE、または RDP 経由でドメインのグラフィカル表示に接続します。--include-password オプションを使用すると、SPICE チャンネルのパスワードが URI に組み込まれます。

15.5.20. ドメイン検索コマンド

以下のコマンドは、所定ドメインについての異なる情報を表示します。
  • virsh domhostname domain は、指定されるドメインのホスト名を表示します (ハイパーバイザーがこれを公開できる場合)。
  • virsh dominfo domain は、指定されるドメインについての情報を表示します。
  • virsh domuid domain|ID は、所定のドメイン名または ID を UUID に変換します。
  • virsh domid domain|ID は、所定のドメイン名または UUID を ID に変換します。
  • virsh domjobabort domain は、指定されるドメイン上で現在実行されているジョブを中止します。
  • virsh domjobinfo domain は、移行の統計情報を含め、指定されるドメイン上で実行されているジョブについての情報を表示します。
  • virsh domname ドメイン ID|UUID は、所定のドメイン ID または UUID をドメイン名に変換します。
  • virsh domstate domain は、所定ドメインの状態を表示します。--reason オプションを使用すると、表示された状態についての理由も表示されます。
  • virsh domcontrol domain は、ドメインを制御するために使用された VMM へのインターフェースの状態を表示します。「OK」ではない、または「Error」の状態の場合、制御インターフェースが表示される状態に入ってから経過した秒数も出力されます。

例15.2 統計的フィードバックの例

ドメインについての情報を取得するために、以下のコマンドを実行します。
# virsh domjobinfo rhel6
Job type:         Unbounded   
Time elapsed:     1603         ms
Data processed:   47.004 MiB
Data remaining:   658.633 MiB
Data total:       1.125 GiB
Memory processed: 47.004 MiB
Memory remaining: 658.633 MiB
Memory total:     1.125 GiB
Constant pages:   114382      
Normal pages:     12005       
Normal data:      46.895 MiB
Expected downtime: 0            ms
Compression cache: 64.000 MiB
Compressed data:  0.000 B
Compressed pages: 0            
Compression cache misses: 12005        
Compression overflows: 0

15.5.21. QEMU 引数のドメイン XML への変換

virsh domxml-from-native は、libvirt のドメイン XML を使用して QEMU 引数の既存のセットをゲストの記述に変換する方法を提供します。libvirt のドメイン XML はその後 libvirt で使用できます。ただし、このコマンドは、既存の QEMU ゲストがコマンドラインから以前に起動されている場合に、これらのゲストを libvirt で管理できるように変換する目的でのみ使用されることになっている点に注意してください。ここに説明されている方法は、新しいゲストをゼロから作成するために使用しないでください。新しいゲストは virsh または virt-manager のいずれかを使って作成する必要があります。追加情報については、こちらをご覧ください。
以下の引数ファイルを持つ QEMU ゲストがあるとします。
 $ cat demo.args 
LC_ALL=C 
PATH=/bin 
HOME=/home/test 
USER=test 
LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor pty -no-acpi -boot c -hda /dev/HostVG/QEMUGuest1 -net none -serial none -parallel none -usb
これをドメイン XML に変換してゲストが libvirt で管理できるようにするには、以下を実行します。
$ virsh domxml-from-native qemu-argv demo.args
このコマンドは、上記の引数ファイルを以下のドメイン XML ファイルに変換します。

<domain type='qemu'>
  <uuid>00000000-0000-0000-0000-000000000000</uuid>
  <memory>219136</memory>
  <currentMemory>219136</currentMemory>
  <vcpu>1</vcpu>
  <os>
    <type arch='i686' machine='pc'>hvm</type>
    <boot dev='hd'/>
  </os>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/bin/qemu</emulator>
    <disk type='block' device='disk'>
      <source dev='/dev/HostVG/QEMUGuest1'/>
      <target dev='hda' bus='ide'/>
    </disk>
  </devices>
</domain>

15.5.22. ドメインのコアのダンプファイルの作成

ドメインのコアを含むダンプファイルを解析するために、そのダンプファイルを作成することが必要になる場合があります (とくにトラブルシューティングの場合)。この場合、virsh dump domain corefilepath --bypass-cache --live |--crash |--reset --verbose --memory-only により、corefilepath で指定されるファイルにドメインコアがダンプされます。ハイパーバイザーによっては、このアクションを制限している場合があり、この場合ユーザーは corefilepath パラメーターで指定されるファイルとパスに対して適切なアクセス権があることを手動で確認することが必要になる場合があります。このコマンドは、他のパススルーデバイスと共に SR-IOV デバイスでサポートされます。以下オプションがサポートされており、かつ次のような効果があります。
  • --bypass-cache: 保存されるファイルには、ファイルシステムのキャッシュが含まれません。このオプションを選択すると、ダンプ操作の速度が遅くなる可能性があることに注意してください。
  • --live: ドメインが実行を継続する際にファイルを保存し、ドメインが一時停止/停止することはありません。
  • --crash: ダンプファイルが保存される間に、ドメインを一時停止の状態のままにするのではなく、クラッシュした状態に置きます。
  • --reset: ダンプファイルが正常に保存されると、ドメインがリセットされます。
  • --verbose: ダンププロセスの進捗が表示されます。
  • --memory-only: ダンプファイルに保存される情報はドメインのメモリーと CPU 共通レジスターファイルのみになります。
プロセス全体は domjobinfo コマンドを使用して監視でき、domjobabort コマンドを使用してキャンセルできることに注意してください。

15.5.23. 仮想マシンの XML ダンプの作成 (設定ファイル)

virsh を使用してゲスト仮想マシンの XML 設定ファイルを出力します。
# virsh dumpxml {guest-id, guestname or uuid}
このコマンドはゲスト仮想マシンの XML 設定ファイルを標準出力 (stdout) に対して出力します。この出力をファイルにパイプすることで、データを保存することができます。この出力を guest.xml というファイルにパイプする例を以下に示します。
# virsh dumpxml GuestID > guest.xml
このファイル guest.xml はゲスト仮想マシンを再作成することができます (「ゲスト仮想マシンの設定ファイルの編集」を参照)。この XML 設定ファイルを編集することで、追加のデバイスを設定したり、追加のゲスト仮想マシンを配備したりすることができます。
virsh dumpxml 出力の一例
# virsh dumpxml guest1-rhel6-64
<domain type='kvm'>
  <name>guest1-rhel6-64</name>
  <uuid>b8d7388a-bbf2-db3a-e962-b97ca6e514bd</uuid>
  <memory>2097152</memory>
  <currentMemory>2097152</currentMemory>
  <vcpu>2</vcpu>
  <os>
    <type arch='x86_64' machine='rhel6.2.0'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='threads'/>
      <source file='/home/guest-images/guest1-rhel6-64.img'/>
      <target dev='vda' bus='virtio'/>
      <shareable/<
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>
    <interface type='bridge'>
      <mac address='52:54:00:b9:35:a9'/>
      <source bridge='br0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <input type='tablet' bus='usb'/>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='yes'/>
    <sound model='ich6'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </sound>
    <video>
      <model type='cirrus' vram='9216' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </memballoon>
  </devices>
</domain>
<shareable/> のフラグが設定されている点に注意してください。ドメイン間でのデバイスの共有が予想されていることを示しています (ハイパーバイザーおよび OS がこれに対応していると仮定)。つまり、このデバイスに対してはキャッシュ機能は非アクティブ化されます。

15.5.24. 設定ファイルでのゲスト仮想マシンの作成

ゲスト仮想マシンは XML 設定ファイルから作成することができます。以前に作成されたゲスト仮想マシンから既存の XML をコピーするか、または dumpxml オプションを使用することができます (「仮想マシンの XML ダンプの作成 (設定ファイル)」を参照)。ゲスト仮想マシンを virsh を使って XML ファイルから作成するには、以下を実行します。
# virsh create configuration_file.xml

15.6. ゲスト仮想マシンの設定ファイルの編集

dumpxml オプション (「仮想マシンの XML ダンプの作成 (設定ファイル)」を参照) を使用する代わりに、ゲスト仮想マシンは実行中またはオフライン中のいずれかに編集することができます。virsh edit コマンドはこの機能を提供します。たとえば rhel6 という名前のゲスト仮想マシンを編集するには、以下を実行します。
# virsh edit rhel6
このコマンドを実行するとテキストエディターが開きます。デフォルトのテキストエディターは $EDITOR シェルパラメーターになります (デフォルトで vi に設定)。

15.6.1. 多機能 PCI デバイスを KVM ゲスト仮想マシンに追加する

このセクションでは多機能 PCI デバイスを KVM ゲスト仮想マシンに追加する方法について説明します。
  1. virsh edit [guestname] コマンドを実行して、ゲスト仮想マシンの XML 設定ファイルを編集します。
  2. address type タグ内の function='0x0'multifunction='on' のエントリーを追加します。
    これでゲスト仮想マシンが多機能 PCI デバイスを使用できるようになります。
    <disk type='file' device='disk'>
    <driver name='qemu' type='raw' cache='none'/>
    <source file='/var/lib/libvirt/images/rhel62-1.img'/>
    <target dev='vda' bus='virtio'/>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/
    </disk>
    2 種類の機能を備えた PCI デバイスの場合、XML 設定ファイルを修正して、2 番目のデバイスに 1 番目のデバイスと同じスロット番号と、function='0x0' などの異なる機能番号を持たせます。
    例:
    <disk type='file' device='disk'>
    <driver name='qemu' type='raw' cache='none'/>
    <source file='/var/lib/libvirt/images/rhel62-1.img'/>
    <target dev='vda' bus='virtio'/>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/>
    </disk>
    <disk type='file' device='disk'>
    <driver name='qemu' type='raw' cache='none'/>
    <source file='/var/lib/libvirt/images/rhel62-2.img'/>
    <target dev='vdb' bus='virtio'/>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/>
    </disk>
  3. KVM ゲスト仮想マシンで lspci を実行すると次のような出力になります。
    $ lspci
    
    00:05.0 SCSI storage controller: Red Hat, Inc Virtio block device
    00:05.1 SCSI storage controller: Red Hat, Inc Virtio block device

15.6.2. 後に再起動するために実行中のドメインを停止する

virsh managedsave domain --bypass-cache --running | --paused | --verbose は、後に同じ状態から再起動できるように実行中のドメインを保存し、破棄 (停止) します。virsh start コマンドを併用すると、ドメインはこの保存したポイントから自動的に起動します。--bypass-cache オプションを併用すると、保存により、ファイルシステムのキャッシュは回避されます。このオプションは保存プロセスのスピードを低下させることに注意してください。
--verbose: ダンププロセスの進捗が表示されます。
通常の状態では、管理保護は、保存の実行時にドメインが置かれている状態に応じて実行中 (running) の状態または一時停止 (paused) の状態のいずれかを決定します。ただし、実行中の状態のままにすべきであると指定する場合は --running オプションを使用するか、または一時停止の状態のままにすべきであると指定する場合は --paused オプションを使用することで、これを上書きすることができます。
管理保存の状態を削除するには、virsh managedsave-remove コマンドを使用します。このコマンドは、ドメインの次回の起動時に完全なブートを実行するように強制します。
管理保存プロセス全体は domjobinfo コマンドを使用して監視することも、domjobabort コマンドを使用してキャンセルすることもできることに注意してください。

15.6.3. 指定されたドメインについての CPU 統計の表示

virsh cpu-stats domain --total start count コマンドは指定されたドメインについての CPU 統計情報を提供します。デフォルトで、このコマンドは合計と共に、すべての CPU についての統計を表示します。--total オプションは、合計の統計情報のみを表示します。

15.6.4. スクリーンショットの保存

virsh screenshot コマンドは、現在のドメインコンソールのスクリーンショットを取り、これをファイルに保存します。ただし、ハイパーバイザーが 1 つのドメインについて複数のディスプレイをサポートしている場合、--screen を使用し、さらにスクリーン ID を指定してキャプチャーするスクリーンを指定します。複数のグラフィックカードがある場合で、ヘッドがそれらのデバイスの前に列挙される場合、スクリーン ID 5 は 2 番目のカードの 2 番目のヘッドに対応します。

15.6.5. キーストロークの組み合わせの指定されたドメインへの送信

virsh send-key domain --codeset --holdtime キーコード コマンドを使い、指定されたドメインに対してシーケンスを キーコード として送信できます。
それぞれのキーコードは、対応するコードセットからの数値またはシンボリック名のいずれかにすることができます。複数のキーコードが指定される場合、それらすべてはゲスト仮想マシンに同時に送信されるため、順不同に受信される可能性があります。一意のキーコードを必要とする場合には、send-key コマンドを複数回送信する必要があります。
# virsh send-key rhel6 --holdtime 1000 0xf
--holdtime が指定されると、それぞれのキーストロークは指定された時間 (ミリ秒単位) 保持されます。--codeset を使用してコードセットを指定できます。デフォルトは Linux ですが、以下のオプションが許可されています。
  • linux - このオプションを選択すると、シンボリック名が対応する Linux キーの定数マクロ名に一致し、数値は Linux の汎用入力イベントサブシステムによって提供されるものになります。
  • xt- これは、XT キーボードコントローラーによって定義される値です。シンボリック名は一切指定されません。
  • atset1 - 数値は AT キーボードコントローラー、set1 (XT と互換性のあるセット) で定義されるものです。atset1 からの拡張キーコードは XT コードセットの拡張キーコードと異なる場合があります。シンボリック名は一切指定されません。
  • atset2 - 数値は AT キーコントローラー、set 2 によって定義されるものです。シンボリック名は一切指定されません。
  • atset3 - 数値は AT キーコントローラー、set 3 (PS/2 と互換性あり) で定義されるものです。シンボリック名は一切指定されません。
  • os_x - 数値は OS-X キーボード入力サブシステムで定義されるものです。シンボリック名は対応する OS-X キー定数マクロ名に一致します。
  • xt_kbd - 数値は Linux KBD デバイスで定義されるものです。それらは元の XT コードセットの種類ですが、拡張キーコードの異なるエンコードを持つ場合が多くあります。シンボリック名は一切指定されません。
  • win32 - 数値は Win32 キーボード入力サブシステムで定義されるものです。シンボリック名は対応する Win32 キー定数マクロ名に一致します。
  • usb - 数値は、キーボード入力の USB HID 仕様によって定義されるものです。シンボリック名は一切指定されません。
  • rfb - 数値は、raw キーコードを送信するために RFB 拡張によって定義されるものです。それらは XT コードセットの種類ですが、拡張キーコードには、高ビットの第 1 バイトではなく、低ビットの第 2 バイトセットがあります。シンボリック名は一切指定されません。

15.6.6. プロセスのシグナル名を仮想プロセスに送信

virsh send-process-signal domain-ID PID signame コマンドを使用すると、指定されたシグナル (名前で識別) が、そのドメイン ID で実行中のドメイン内にある指定された仮想プロセス (プロセス ID または PID で識別) に送信されます。この方法では、整数のシグナル定数またはシンボリックシグナル名を送信することができます。
# virsh send-process-signal rhel6 187 kill
利用可能なシグナルおよびその使い方に関する全一覧は、virsh(1) および signal(7) の man ページを参照してください。

15.6.7. VNC ディスプレイの IP アドレスとポート番号の表示

virsh vncdisplay は、指定されたドメインについての VNC ディスプレイの IP アドレスとポート番号を出力します。情報を使用できない場合、終了コード 1 が表示されます。
# virsh vncdisplay rhel6
127.0.0.1:0

15.7. NUMA ノードの管理

このセクションでは、NUMA コードの管理に必要なコマンドを扱います。

15.7.1. ノード情報の表示

nodeinfo コマンドは、モデル番号、CPU の数量、CPU のタイプ、および物理メモリーのサイズを含むノードについての基本情報を表示します。この出力は、virNodeInfo の構造に相当します。とくに「CPU socket(s)」フィールドは NUMA セルごとの CPU ソケット数を示しています。
$ virsh nodeinfo
CPU model:           x86_64
CPU(s):              4
CPU frequency:       1199 MHz
CPU socket(s):       1
Core(s) per socket:  2
Thread(s) per core:  2
NUMA cell(s):        1
Memory size:         3715908 KiB

15.7.2. NUMA パラメーターの設定

virsh numatune は、指定されたドメインの NUMA パラメーターの設定または取得のいずれかを実行できます。ドメイン XML ファイル内で、これらのパラメーターは <numatune> 要素内にネスト化されます。フラグを使用することなく、現在の設定のみが表示されます。numatune domain コマンドには指定されたドメインが必要であり、以下のオプション引数を取ります。
  • --mode - モードは strictinterleave、または preferred のいずれかに設定できます。ドメインが strict モードで起動されたのではない限り、実行中のドメインが稼働中の場合、それらのモードを変更することはできません。
  • --nodeset - ドメインを実行するためにホスト物理マシンによって使用される NUMA ノードの一覧が含まれます。この一覧にはノードが含まれますが、それぞれはコンマで区切られ、ノード範囲にはダッシュ - が、ノードの除外にはキャレット ^ が使用されます。
  • 各インスタンスごとに使用できるのは以下の 3 つのフラグのいずれか 1 つのみです。
    • --config は、永続的なゲスト仮想マシンの次回の起動で実施されます。
    • --live は、実行中のゲスト仮想マシンのスケジューラー情報を設定します。
    • --current は、ゲスト仮想マシンの現在の状態に作用します。

15.7.3. NUMA セルの空きメモリー容量の表示

virsh freecell は、指定された NUMA セル内のマシンで利用可能なメモリー容量を表示します。このコマンドは、指定されるオプションに応じて、マシンで利用可能なメモリーについての 3 つの異なる表示のいずれかを提供します。オプションが使用されない場合、マシンの空きメモリーの合計容量が表示されます。--all オプションを使用すると、各セル内の空きメモリー量とマシンの空きメモリーの合計容量が表示されます。数値の引数またはセル番号と共に --cellno オプションを使用すると、指定されたセルの空きメモリーが表示されます。

15.7.4. CPU 一覧の表示

nodecpumap コマンドは、オンラインであるかどうかにかかわらず、ノードが使用できる CPU の数を表示します。さらに、現在オンラインの CPU の数を一覧表示します。
$ virsh nodecpumap
   CPUs present: 4
   CPUs online: 1
   CPU map: y

15.7.5. CPU 統計の表示

nodecpustats コマンドは、CPU が指定されている場合に、指定される CPU についての統計情報を表示します。CPU が指定されていない場合、ノードの CPU 状態を表示します。パーセントが指定されている場合、1 秒間隔で記録されたそれぞれの種類の CPU 統計のパーセンテージが表示されます。
以下の例では CPU が指定されていません。
$ virsh nodecpustats
user:               1056442260000000
system:              401675280000000
idle:               7549613380000000
iowait:               94593570000000
以下の例は、CPU 番号 2 の統計的パーセンテージを示しています。
$ virsh nodecpustats 2 --percent
usage:            2.0%
user:             1.0%
system:           1.0%
idle:            98.0%
iowait:           0.0%
再起動中のゲスト仮想マシンの動作は、ゲスト仮想マシンの設定ファイルの on_reboot 要素を変更することにより、制御することができます。

15.7.6. ホスト物理マシンの一時停止

nodesuspend コマンドは、ホスト物理マシンを S3 (suspend-to-RAM)、S4 (suspend-to-disk)、または Hybrid-Suspend と同様のシステム全体のスリープ状態に置き、リアルタイムクロックをセットアップして設定期間の経過後にノードを起動します。--target オプションは、memdisk、または hybrid のいずれかに設定できます。これらのオプションは、一時停止するメモリー、ディスク、またはこの 2 つの組み合わせを指定します。--duration を設定すると、設定された期間の経過後にホスト物理マシンが起動するよう指示します。時間の単位は秒単位になります。60 秒以上に設定することが推奨されます。
$ virsh nodesuspend disk 60

15.7.7. ノードメモリーパラメーターの設定

node-memory-tune [shm-pages-to-scan] [shm-sleep-milisecs] [shm-merge-across-nodes] コマンドは、ノードメモリーパラメーターを表示し、これを設定することを可能にします。このコマンドで設定できる 3 つのパラメーターがあります。
  • shm-pages-to-scan - 共有メモリーサービスが休止する前にスキャンするページの数を設定します。
  • shm-sleep-milisecs - 共有メモリーサービスが次回のスキャンの前に休止するミリ秒数を設定します。
  • shm-merge-across-nodes - 異なる NUMA ノードからページをマージできるかどうかを指定します。許可される値は 01 です。0 に設定される場合、マージできるページは同じ NUMA ノードのメモリー領域に物理的に存在するページのみです。1 に設定されると、すべての NUMA ノードからのページをマージできます。デフォルト設定は 1 です。

15.7.8. ホストノード上のデバイスの作成

virsh nodedev-create file コマンドを使用すると、ホストノード上にデバイスを作成し、それをゲスト仮想マシンに割り当てることができます。libvirt は通常、使用できるホストノードを自動的に検出しますが、このコマンドは libvirt が検出しなかったホストハードウェアの登録を可能にします。この file には、ノードデバイスのトップレベルについての <device> 記述の XML が含まれる必要があります。
このデバイスを停止するには、nodedev-destroy device コマンドを使用します。

15.7.9. ノードデバイスの切り離し

virsh nodedev-detach は nodedev をホストから切り離し、これが <hostdev> パススルー経由でゲストによって安全に使用できるようにします。このアクションは nodedev-reattach コマンドを使ってリバースできますが、管理サービスについては自動的にリバースが実行されます。さらに、このコマンドは nodedev-dettach を受け入れます。
異なるドライバーは、デバイスが別のダミーデバイスにバインドされることを想定することに注意してください。--driver オプションを使用すると、希望するバックエンドドライバーを指定することができます。

15.7.10. デバイスを設定の検索

virsh nodedev-dumpxml [device] コマンドは、所定のノード <device> の XML 設定ファイルをダンプします。この XML 設定には、デバイス名やどのバスがデバイスを所有しているか、ベンダー、および製品 ID などの情報が含まれています。引数 device はデバイス名か、WWNN | WWPN 形式 (HBA のみ) の WWN ペアのいずれかにすることができます。

15.7.11. ノード上デバイスの一覧表示

virsh nodedev-list cap --tree コマンドは、libvirt が認識するノード上の利用可能なすべてのデバイスを一覧表示します。cap は一覧を機能タイプでフィルターするためそれぞれをコンマで区切って使用しますが、--tree と一緒に使用することはできません。--tree オプションを使用すると、出力は以下に示すようなツリー構造になります。
   #  virsh nodedev-list --tree
   computer
  |
  +- net_lo_00_00_00_00_00_00
  +- net_macvtap0_52_54_00_12_fe_50
  +- net_tun0
  +- net_virbr0_nic_52_54_00_03_7d_cb
  +- pci_0000_00_00_0
  +- pci_0000_00_02_0
  +- pci_0000_00_16_0
  +- pci_0000_00_19_0
  |   |
  |   +- net_eth0_f0_de_f1_3a_35_4f

(これは部分的なスクリーンです)

15.7.12. ノードのリセットのトリガー

nodedev-reset nodedev コマンドは、指定された nodedev のデバイスのリセットをトリガーします。このコマンドは、ゲスト仮想マシンのパススルーとホスト物理マシン間でノードデバイスを転送する前に実行すると便利です。libvirt は必要に応じてこのアクションを暗黙的に実行しますが、このコマンドは必要な場合に明示的なリセットを許可します。

15.8. ゲスト仮想マシンの起動、一時停止、再開、保存および復元

15.8.1. 定義されたドメインの起動

virsh start domain --console --paused --autodestroy --bypass-cache --force-boot --pass-fds コマンドは、定義済みであるものの、最後に管理保存の状態になってから、または新規に起動されてから停止している停止状態のドメインを起動します。コマンドは以下のオプションを取ります。
  • --console - コンソールに割り当てられているドメインを起動します。
  • --paused - ドライバーによってサポートされている場合、ドメインを起動してから一時停止の状態に置きます。
  • --autodestroy - ゲスト仮想マシンは、virsh セッションが閉じるか、または libvirt の接続が閉じる場合に自動的に破棄されます。そうでない場合は、終了します。
  • --bypass-cache - ドメインが管理保存の状態の場合に使用されます。これが使用される場合、ゲスト仮想マシンが復元され、システムのキャッシュが回避されます。これにより、復元プロセスのスピードが低下することに注意してください。
  • --force-boot - 管理保存のオプションを破棄し、新規の起動を生じさせます。
  • --pass-fds - 追加オプションの引数のコンマ区切りの一覧で、ゲスト仮想マシンに渡されます。

15.8.2. ゲスト仮想マシンの一時停止

virsh を使ってゲスト仮想マシンを一時停止します。
# virsh suspend {domain-id, domain-name or domain-uuid}
ゲスト仮想マシンがサスペンドの状態にある場合、システム RAM を消費しますが、プロセッサーのリソースは消費しません。ディスクとネットワークの I/O は、ゲスト仮想マシンのサスペンド中には発生しません。この操作は即時に行なわれるもので、ゲスト仮想マシンは resume (「ゲスト仮想マシンの再開」) オプションで再起動できます。

15.8.3. 実行中のドメインの一時停止

virsh dompmsuspend domain --duration --target コマンドは、実行中のドメインを取り、そのドメインが 3 つの状態 (S3、S4、またはこれら 2 つのハイブリッド) のいずれかに置かれるように一時停止します。
# virsh dompmsuspend rhel6 --duration 100 --target mem
このコマンドは、以下のオプションを取ります。
  • --duration - 状態変更の期間 (秒単位) を設定します。
  • --target - mem (suspend to RAM (S3))disk (suspend to disk (S4))、または hybrid (hybrid suspend) のいずれかにできます。

15.8.4. pmsuspend 状態のドメインを起動

このコマンドは、設定した期間の有効期限が過ぎるのを待機するのではなく、pmsuspend 状態のゲストに対してウェイクアップアラートを挿入します。この操作は、ドメインが実行されている場合は失敗しません。
# dompmwakeup rhel6
このコマンドには、 rhel6 のようなドメイン名を必要とします。

15.8.5. ドメインの定義解除

このコマンドは、ドメインの定義を解除します。これは実行中のドメインで機能しますが、ドメインを停止することなく実行中のドメインを一時的なドメインに変換します。ドメインが停止中の場合、ドメイン設定は削除されます。
virsh undefinedomain--managed-save--snapshots-metadata --storage --remove-all-storage --wipe-storage コマンドは以下のオプションを取ることができます。
  • --managed-save - このオプションは、管理保護状態のドメインの定義が解除されると、その関連付けられた管理保護状態のイメージも削除されることを保証します。このオプションを使用せずに、管理保護状態のドメインの定義解除を試みると失敗します。
  • --snapshots-metadata - このオプションは、停止中ドメインの定義解除を実行する際に、スナップショット (snapshot-list で表示) も定義削除されることを保証します。スナップショットのメタデータが含まれている、停止中のドメインの定義解除を試みると、失敗することに注意してください。ドメインがアクティブな場合にこのオプションが使用されと、無視されます。
  • --storage - このオプションでは、定義解除されるドメインと共に削除されるボリュームターゲット名またはストレージボリュームのソースパスのコンマ区切りの一覧が必要になります。このアクションにより、ストレージボリュームは削除される前に定義解除されます。これは停止中のドメインでのみ実行できることに注意してください。また、これは libvirt が管理するストレージボリュームでのみ機能することにも注意してください。
  • --remove-all-storage - ドメインの定義解除に加え、すべての関連付けられたストレージボリュームが削除されます。
  • --wipe-storage - ストレージボリュームの削除に加え、コンテンツが完全消去されます。

15.8.6. ゲスト仮想マシンの再開

virshresume オプションと併用して、サスペンド中のゲスト仮想マシンを復元します。
# virsh resume {domain-id, domain-name or domain-uuid}
この操作は即時に行なわれるもので、ゲスト仮想マシンのパラメーターは suspend および resume 操作のために保管されます。

15.8.7. ゲスト仮想マシンの保存

virsh コマンドを使用して、ゲスト仮想マシンの現在の状態をファイルに保存します。
# virsh save {domain-name|domain-id|domain-uuid} state-file --bypass-cache --xml --running --paused --verbose
これにより、指定したゲスト仮想マシンが停止し、データがファイルに保存されます。これにはゲスト仮想マシンで使用しているメモリーの容量に応じて少々の時間がかかります。ゲスト仮想マシンの状態を復元するには、restore オプションを使用します (「ゲスト仮想マシンの復元」)。保存は一時停止に似ていますが、ゲスト仮想マシンを一時停止にするだけでなく、ゲスト仮想マシンの現在の状態を保存します。
virsh save コマンドは、以下のオプションを取ります。
  • --bypass-cache - 復元により、ファイルシステムのキャッシュが回避されますが、このフラグを使用すると、復元操作が遅くなることに注意してください。
  • --xml - このオプションは、XML ファイル名と共に使用する必要があります。このオプションは通常省略されますが、復元されるゲスト仮想マシンに代替 XML ファイルを指定するために使用できます。この際、変更はドメイン XML のホスト固有の部分にのみ加えられます。たとえば、これはゲストの保存後に取られるディスクのスナップショットによって生じる、基礎となるストレージのファイル名の違いを説明するために使用できます。
  • --running - ドメインを実行状態で起動するために保存イメージに記録された状態をオーバーライドします。
  • --paused- ドメインを一時停止の状態で起動するために、保存イメージに記録された状態をオーバーライドします。
  • --verbose - 保存の進捗を表示します。
ゲスト仮想マシンを XML ファイルから直接復元する必要がある場合、virsh restore コマンドがこれを行います。domjobinfo でプロセスを監視したり、domjobabort でプロセスをキャンセルしたりすることができます。

15.8.8. ゲストの復元に使用されるドメイン XML ファイルの更新

virsh save-image-define file xml --running|--paused コマンドは、後で virsh restore コマンドの実行時に指定ファイルが使用される際のドメイン XML ファイルを更新します。xml 引数は、代替 XML を含む XML ファイル名である必要があります。この場合、ホスト物理マシンのドメイン XML に固有の部分にのみ変更が加えられます。たとえば、これはゲストの保存後に作成されるディスクのスナップショットによって生じる、基礎となるストレージのファイル名の違いを説明するために使用できます。保存イメージは、ドメインが実行中または一時停止の状態に復元されるかどうかを記録します。--running または --paused のオプションを使用すると、使用される状態が決定されます。

15.8.9. ドメイン XML ファイルの抽出

save-image-dumpxml file --security-info コマンドは、保存状態のファイル (virsh save コマンドで使用される) が参照された際に有効であったドメイン XML ファイルを抽出します。--security-info オプションを使用すると、セキュリティーの機密情報がファイルに含まれるようになります。

15.8.10. ドメイン XML 設定ファイルの編集

save-image-edit file --running --paused コマンドは、virsh save コマンドによって作成された保存済みの file と関連付けられた XML 設定ファイルを編集します。
保存イメージはドメインが --running または --paused 状態に復元されるかどうかを記録します。これらのオプションを使用しないと、状態はファイル自体で決定されます。--running または --paused を選択することにより、virsh restore が使用するはずの状態を上書きすることができます。

15.8.11. ゲスト仮想マシンの復元

virsh を使用して、virsh save コマンドを使用して以前に保存したゲスト仮想マシン (「ゲスト仮想マシンの保存」) を復元します。
# virsh restore state-file
これにより、保存していたゲスト仮想マシンが再起動します。これには少々時間がかかる可能性があります。ゲスト仮想マシンの名前と UUID は保管されていますが、新規の ID が割り当てられます。
virsh restore state-file コマンドは以下のオプションを取ることができます。
  • --bypass-cache - 復元により、ファイルシステムのキャッシュが回避されますが、このフラグを使用すると、復元操作が遅くなることに注意してください。
  • --xml - このオプションは、XML ファイル名と共に使用する必要があります。このオプションは通常省略されますが、復元されるゲスト仮想マシンに代替 XML ファイルを指定するために使用できます。この際、変更はドメイン XML のホスト固有の部分にのみ加えられます。たとえば、これはゲストの保存後に取られるディスクのスナップショットによって生じる、基礎となるストレージのファイル名の違いを説明するために使用できます。
  • --running - ドメインを実行状態で起動するために保存イメージに記録された状態をオーバーライドします。
  • --paused- ドメインを一時停止の状態で起動するために、保存イメージに記録された状態をオーバーライドします。

15.9. ゲスト仮想マシンのシャットダウン、再起動および強制終了

15.9.1. ゲスト仮想マシンのシャットダウン

virsh shutdown コマンドを使用してゲスト仮想マシンをシャットダウンします。
# virsh shutdown {domain-id, domain-name or domain-uuid} [--mode method]
ゲスト仮想マシンの設定ファイルにある on_shutdown パラメーターを変更して、再起動中のゲスト仮想マシンの動作を制御することができます。

15.9.2. Red Hat Enterprise Linux 7 ホスト上の Red Hat Enterprise Linux 6 ゲストのシャットダウン

最小限のインストール (Minimal installation) オプションを指定して Red Hat Enterprise Linux 6 ゲスト仮想マシンをインストールしても、acpid パッケージはインストールされません。このパッケージは systemd に引き継がれたので Red Hat Enterprise Linux 7 では不要です。ただし、Red Hat Enterprise Linux 7 ホスト上で実行される Red Hat Enterprise Linux 6 ゲスト仮想マシンにはこれが依然として必要になります。
acpid パッケージがないと、virsh shutdown コマンドを実行しても Red Hat Enterprise Linux 6 ゲスト仮想マシンがシャットダウンしません。virsh shutdown コマンドはゲスト仮想マシンを正しくシャットダウンするように設計されています。
virsh shutdown を使用する方がシステム管理上、安全かつ簡単な方法となります。virsh shutdown コマンドで正しくシャットダウンできないと、システム管理者は手動でゲスト仮想マシンにログインするか、または Ctrl-Alt-Del のキー組み合わせを各ゲスト仮想マシンに送信しなければならなくなります。

注記

他の仮想化オペレーティングシステムもこの問題の影響を受ける場合があります。virsh shutdown コマンドが正しく動作するには、ゲスト仮想マシンのオペレーティングシステムが ACPI シャットダウン要求を処理できるよう設定されている必要があります。ACPI シャットダウン要求を受け取らせるには、多くのオペレーティングシステムにゲスト仮想マシンのオペレーティングシステムでの追加設定が必要になります。

手順15.4 Red Hat Enterprise Linux 6 ゲストの回避策

  1. acpid パッケージをインストールします

    acpid サービスによって ACPI 要求のリッスンと処理が行われます。
    ゲスト仮想マシンにログインし、ゲスト仮想マシンに acpid パッケージをインストールします。
    # yum install acpid
  2. acpid サービスを有効にします

    acpid サービスがゲスト仮想マシンのブートシーケンスで起動され、サービスを開始するよう設定します。
    # systemctl enable acpid
    # service acpid start
  3. ゲストドメイン xml を準備します。

    以下の要素を組み込むようにドメイン XML ファイルを編集します。virtio シリアルポートを org.qemu.guest_agent.0 に置き換え、$guestname の代わりにゲストの名前を使用します。
    
    <channel type='unix'>
       <source mode='bind' path='/var/lib/libvirt/qemu/{$guestname}.agent'/>
       <target type='virtio' name='org.qemu.guest_agent.0'/>
    </channel>
    

    図15.2 ゲスト XML の置き換え

  4. QEMU ゲストエージェントをインストールします。

    QEMU ゲストエージェント (QEMU-GA) をインストールし、11章QEMU-img および QEMU ゲストエージェントで指示されるようにサービスを起動します。Windows ゲストを実行している場合、この章ではこれに関する方法も記載されています。
  5. ゲストをシャットダウンします。

    1. 以下のコマンドを実行します。
      # virsh list --all  - this command lists all of the known domains 
         Id Name              State
      ----------------------------------
         rhel6                running
    2. ゲスト仮想マシンをシャットダウンします。
      # virsh shutdown rhel6
      
      Domain rhel6 is being shutdown
    3. ゲスト仮想マシンがシャットダウンするまで数秒間待機します。
      # virsh list --all
       Id Name                 State
      ----------------------------------
        . rhel6                shut off
    4. 編集した XML ファイルを使用して、rhel6 という名前のドメインを起動します。
      # virsh start rhel6
    5. rhel6 ゲスト仮想マシンで acpi をシャットダウンします。
      # virsh shutdown --mode acpi rhel6 
    6. すべてのドメインを再度一覧表示します。rhel6 が一覧にまだ表示されますが、電源が切れていることが示されるはずです。
      # virsh list --all
         Id Name                 State
      ----------------------------------
         rhel6                shut off
    7. 編集した XML ファイルを使用して、rhel6 という名前のドメインを起動します。
      # virsh start rhel6
    8. rhel6 ゲスト仮想マシンのゲストエージェントをシャットダウンします。
      # virsh shutdown --mode agent rhel6
    9. ドメインを一覧表示します。rhel6 がまだリストにあり、shut off 状態になっています。
      # virsh list --all
         Id Name                 State
      ----------------------------------
         rhel6                shut off
ゲスト仮想マシンは、連続するシャットダウンにおいて、上記の回避策を使用せずに virsh shutdown コマンドを使ってシャットダウンします。
上記の方法以外にも、libvirt-guest サービスを停止してゲストを自動的にシャットダウンできます。この方法についての詳細は、「libvirt-guests 設定の設定内容の操作」を参照してください。

15.9.3. libvirt-guests 設定の設定内容の操作

libvirt-guests サービスには、ゲストが適切にシャットダウンされていることを保証するために設定できるパラメーター設定が含まれます。これは libvirt インストールの一部をなすパッケージであり、デフォルトでインストールされます。このサービスは、ホストがシャットダウンされる際にゲストをディスクに自動的に保存し、ホストの再起動時にシャットダウン前の状態にゲストを復元します。デフォルトでは、この設定はゲストを一時停止するように設定されます。ゲストの電源を切る必要がある場合、libvirt-guests 設定ファイルのパラメーターのいずれかを変更する必要があります。

手順15.5 ゲストを正しくシャットダウンできるよう libvirt-guests サービスパラメーターを変更する

ここで説明される手順により、ホスト物理マシンが停止しているか、電源がオフになっているか、または再起動が必要な場合に、ゲスト仮想マシンを正しくシャットダウンすることができます。
  1. 設定ファイルを開きます。

    設定ファイルは /etc/sysconfig/libvirt-guests にあります。ファイルを編集し、コメントマーク (#) を削除し、ON_SHUTDOWN=suspendON_SHUTDOWN=shutdown に変更します。変更は必ず保存してください。
    $ vi /etc/sysconfig/libvirt-guests
    
    # URIs to check for running guests
    # example: URIS='default xen:/// vbox+tcp://host/system lxc:///'
    #URIS=default 
    
    # action taken on host boot
    # - start   all guests which were running on shutdown are started on boot
    #           regardless on their autostart settings                                 1
    # - ignore  libvirt-guests init script won't start any guest on boot, however,     2
    #           guests marked as autostart will still be automatically started by      3
    #           libvirtd                                                               4
    #ON_BOOT=start                                                                     5
    6
    # Number of seconds to wait between each guest start. Set to 0 to allow            7
    # parallel startup.
    #START_DELAY=0
    
    # action taken on host shutdown
    # - suspend   all running guests are suspended using virsh managedsave
    # - shutdown  all running guests are asked to shutdown. Please be careful with
    #             this settings since there is no way to distinguish between a
    #             guest which is stuck or ignores shutdown requests and a guest
    #             which just needs a long time to shutdown. When setting
    #             ON_SHUTDOWN=shutdown, you must also set SHUTDOWN_TIMEOUT to a
    #             value suitable for your guests.
    ON_SHUTDOWN=shutdown
    
    # If set to non-zero, shutdown will suspend guests concurrently. Number of
    # guests on shutdown at any time will not exceed number set in this variable.
    #PARALLEL_SHUTDOWN=0
    
    # Number of seconds we're willing to wait for a guest to shut down. If parallel
    # shutdown is enabled, this timeout applies as a timeout for shutting down all
    # guests on a single URI defined in the variable URIS. If this is 0, then there
    # is no time out (use with caution, as guests might not respond to a shutdown
    # request). The default value is 300 seconds (5 minutes).
    #SHUTDOWN_TIMEOUT=300
    
    # If non-zero, try to bypass the file system cache when saving and
    # restoring guests, even though this may give slower operation for
    # some file systems.
    #BYPASS_CACHE=0

    1

    URIS - 実行中のゲストの指定された接続をチェックします。Default 設定は、明示的な URI が設定されていない場合に virsh と同じように機能します。さらに、URI は /etc/libvirt/libvirt.conf から明示的に設定できます。libvirt 設定ファイルのデフォルト設定を使用する場合、プロービングは使用されないことに注意してください。

    2

    ON_BOOT - ホストの起動時にゲストに対して実行される、またはゲスト上で実行されるアクションを指定します。 start オプションは、autostart の設定にかかわらず、シャットダウンの前に実行されているすべてのゲストを起動します。ignore オプションは、起動時に正式に実行されているゲストを起動しませんが、autostart というマークが付けられたゲストは libvirtd によって自動的に起動されます。

    3

    START_DELAY - ゲストが起動する間の遅延期間を設定します。この期間は秒単位で設定されます。遅延がないようにし、かつすべてのゲストを同時に起動させるには時間設定の 0 を使用します。

    4

    ON_SHUTDOWN - ホストがシャットダウンする際に取られるアクションを指定します。設定できるオプションには、以下が含まれます。virsh managedsave を使用して実行中のすべてのゲストを一時停止する suspend と、実行中のすべてのゲストをシャットダウンする shutdown です。shutdown オプションの場合、注意して使用するのは最良の策です。それは、停止した状態のゲストか、またはシャットダウン要求を無視するゲストと、シャットダウンにより長い時間がかかっているだけのゲストとを区別する方法がないためです。ON_SHUTDOWN=shutdown を設定する際には、SHUTDOWN_TIMEOUT をゲストに適した値に設定する必要もあります。

    5

    PARALLEL_SHUTDOWN 任意に行なわれるシャットダウン時のゲストの数がこの変数で設定される数を超えず、ゲストが同時に中断されることを定めます。0 に設定される場合、ゲストは同時にシャットダウンしません。

    6

    ゲストがシャットダウンするのを待機する秒数です。SHUTDOWN_TIMEOUT が有効な場合、このタイムアウトが、変数 URIS で定義される単一 URI 上のすべてのゲストをシャットダウンするタイムアウトとして適用されます。SHUTDOWN_TIMEOUT0 に設定される場合、タイムアウトはありません (ゲストがシャットダウン要求に応答しない可能性があるため注意して使用してください)。デフォルトの値は 300 秒 (5 分) です。

    7

    BYPASS_CACHE には、無効にするためには 0、有効にするには 1 と 2 つの値を使用することができます。有効にされている場合、ゲストが復元するとファイルシステムのキャッシュをバイパスします。この設定はパフォーマンスに影響を与え、一部のファイルシステムの操作の速度を低下させる可能性があることに注意してください。
  2. libvirt-guests サービスを開始します。

    サービスをまだ開始していない場合は、libvirt-guests サービスを開始します。サービスの再起動により、実行中のすべてのドメインがシャットダウンする可能性があるので実行しないでください。

15.9.4. ゲスト仮想マシンの再起動

ゲスト仮想マシンを再起動するには、virsh reboot コマンドを使用します。再起動が実行されると、プロンプトが返されます。ゲスト仮想マシンが戻るまで、時間のずれがある場合があります。
#virsh reboot {domain-id, domain-name or domain-uuid} [--mode method]
ゲスト仮想マシンの再起動の動作は、同マシンの設定ファイルの <on_reboot> 要素を変更することで制御することができます。詳細情報は、「イベント設定」 を参照してください。
デフォルトでは、ハイパーバイザーが適切なシャットダウン方法を選択します。別の方法を指定する場合、--mode オプションで、initctlacpiagent、および signal を含むコンマ区切りの一覧を指定できます。ドライバーが各モードを試行する順序は、このコマンドで指定された順序とは無関係になります。順序付けを厳密に制御するには、1 度に 1 つのモードを使用してコマンドを繰り返します。

15.9.5. ゲスト仮想マシンの強制終了

ゲスト仮想マシンを virsh destroy コマンドで停止するには、以下のようにします。
# virsh destroy {domain-id, domain-name or domain-uuid} [--graceful]
このコマンドでは、正常なシャットダウンで行なわれる終了プロセスを経ずに、指定されるゲスト仮想マシンをただちにシャットダウンして停止させます。virsh destroy を使用すると、ゲスト仮想マシンのファイルシステムが破損する可能性があります。destroy オプションは、ゲスト仮想マシンが反応しない場合のみに使用してください。正しいシャットダウンを開始する必要がある場合は、virsh destroy --graceful コマンドを使用します。

15.9.6. 仮想マシンのリセット

virsh reset domain は、ゲストをシャットダウンすることなく、ただちにドメインをリセットします。リセットは、マシンの電源リセットボタンをエミュレートします。ここですべてのゲストハードウェアは RST 行を認識し、内部の状態を再初期化します。ゲスト仮想マシンの OS をシャットダウンしない場合、データが失われるリスクが発生します。

15.10. ゲスト仮想マシン情報の取り込み

15.10.1. ゲスト仮想マシンのドメイン ID の取得

ゲスト仮想マシンのドメイン ID を取得するには、以下のようにします。
# virsh domid {domain-name or domain-uuid}

15.10.2. ゲスト仮想マシンのドメイン名の取得

ゲスト仮想マシンのドメイン名を取得するには、以下のようにします。
# virsh domname {domain-id or domain-uuid}

15.10.3. ゲスト仮想マシンの UUID の取得

ゲスト仮想マシンの UUID (Universally Unique Identifier) を取得するには、以下のようにします。
# virsh domuuid {domain-id or domain-name}
virsh domuuid 出力の一例:
# virsh domuuid r5b2-mySQL01
4a4c59a7-ee3f-c781-96e4-288f2862f011

15.10.4. ゲスト仮想マシン情報の表示

ゲスト仮想マシンのドメイン ID、ドメイン名、または UUID との併用で virsh を使用すると、指定したゲスト仮想マシンの情報を表示することができます。
# virsh dominfo {domain-id, domain-name or domain-uuid}
以下に virsh dominfo 出力の一例を示します。
# virsh dominfo vr-rhel6u1-x86_64-kvm
Id:             9
Name:           vr-rhel6u1-x86_64-kvm
UUID:           a03093a1-5da6-a2a2-3baf-a845db2f10b9
OS Type:        hvm
State:          running
CPU(s):         1
CPU time:       21.6s
Max memory:     2097152 kB
Used memory:    1025000 kB
Persistent:     yes
Autostart:      disable
Security model: selinux
Security DOI:   0
Security label: system_u:system_r:svirt_t:s0:c612,c921 (permissive)

15.11. ストレージプールコマンド

以下のコマンドはストレージプールを操作します。libvirt を使用して、ストレージボリュームを仮想マシン内のデバイスとして表示するために使用されるファイル、raw パーティション、およびドメイン固有の形式を含む、さまざまなストレージソリューションを管理できます。この機能についての詳細は、libvirt.org を参照してください。ストレージプールのコマンドの多くは、ドメインに使用されるコマンドに似ています。

15.11.1. ストレージプール XML の検索

find-storage-pool-sources type srcSpec コマンドは、確認できる所定の type のすべてのストレージプールを記述した XML を表示します。srcSpec が指定される場合、プールのクエリーをさらに制限する XML を含むファイルになります。
find-storage-pool-sources-as type host port initiator は、確認できる所定の type のすべてのストレージプールを記述した XML を表示します。hostport、または initiatorが指定される場合、それらはクエリーが実行される場所を制御します。
pool-info pool-or-uuid コマンドは、指定されたストレージプールオブジェクトについての基本的な情報を一覧表示します。このコマンドには、ストレージプールの名前または UUID が必要になります。この情報を取得するには、pool-list を使用します。
pool-list --inactive --all --persistent --transient --autostart --no-autostart --details<type> コマンドは、libvirt が認識するすべてのストレージプールオブジェクトを一覧表示します。デフォルトでは、アクティブなプールのみが一覧表示されますが、--inactive オプションを使用すると、アクティブではないプールのみが一覧表示され、--all オプションを使用すると、すべてのストレージプールが一覧表示されます。
上記のオプションのほかにも、一覧表示の内容をフィルターする複数のフィルターフラグのセットがあります。--persistent は、一覧を永続プールに限定し、--transient は一覧を一時的なプールに限定します。また、--autostart は一覧を自動起動のプールに限定し、最後に --no-autostart は一覧を自動起動が無効にされたストレージプールに限定します。
type を必要とするすべてのストレージプールコマンドの場合、プールのタイプはコンマで区切る必要があります。有効なプールのタイプには、dirfsnetfslogicaldiskiscsiscsimpathrbd、および sheepdog が含まれます。
--details オプションは、virsh に対し、プールの永続性や容量に関連した情報を追加で表示します (ある場合)。

注記

このコマンドが古いサーバーについて使用される場合、競合を継承する一連の API 呼び出しの使用が強制されます。これにより、一覧が収集されている間に複数の呼び出し間の状態が変更される場合、プールは一覧表示されなくなるか、または複数回表示される可能性があります。ただし、新しいサーバーの場合は、この問題は発生しません。
pool-refresh pool-or-uuid は、プールに含まれるボリュームの一覧表示を最新の状態にします。

15.11.2. ストレージプールの作成、定義、および開始

15.11.2.1. ストレージプールの構築

pool-build pool-or-uuid --overwrite --no-overwrite コマンドは、指定された プール名または UUID のプールを構築します。--overwrite および --no-overwrite のオプションは、タイプがファイルシステムの場合にのみ使用できます。いずれのオプションも指定されない場合、プールはファイルシステムタイプのプールになり、結果としてビルドによりディレクトリーのみが作成されます。
--no-overwrite が指定されない場合、コマンドはファイルシステムがすでにターゲットデバイスに存在するかどうかを判別するためにプローブし、存在する場合にはエラーを返します。存在しない場合にはターゲットデバイスをフォーマットするために mkfs を使用します。--overwrite が指定される場合、mkfs コマンドが実行され、ターゲットデバイス上のすべての既存データが上書きされます。

15.11.2.2. XML ファイルからのストレージプールの作成および定義

pool-create file は、関連付けられた XML ファイルからストレージプールを作成し、これを起動します。
pool-define file は、XML ファイルからストレージプールオブジェクトを作成しますが、これを起動することはありません。

15.11.2.3. raw パラメーターからのストレージプールの作成および開始

pool-create-as name --print-xml type source-host source-path source-dev source-name <target> --source-format <format> コマンドは、指定される raw パラメーターからプールオブジェクトの名前を作成し、これを開始します。
--print-xml が指定される場合、プールを作成せずに、ストレージプールオブジェクトの XML が出力されます。指定されない場合、プールには、プールの構築のためにタイプが必要になります。type を必要とするすべてのストレージプールコマンドでは、プールのタイプはコンマで区切る必要があります。有効なプールのタイプには、dirfsnetfslogicaldiskiscsiscsimpathrbd、および sheepdog が含まれます。
pool-define-as name --print-xml type source-host source-path source-dev source-name <target> --source-format <format> コマンドは、指定される raw パラメーターからプールオブジェクト名を作成しますが、これを開始しません。
--print-xml が指定される場合、プールを定義せずに、プールオブジェクトの XML が出力されます。指定されない場合、プールには指定されたタイプが必要になります。type を必要とするすべてのストレージプールコマンドでは、プールのタイプはコンマで区切る必要があります。有効なプールのタイプには、dirfsnetfslogicaldiskiscsiscsimpathrbd、および sheepdog が含まれます。
pool-start pool-or-uuid は、以前に定義されているものの、アクティブでない指定されたストレージプールを開始します。

15.11.2.4. ストレージの自動起動

pool-autostart pool-or-uuid --disable コマンドは、起動時のストレージの自動起動を有効または無効にします。このコマンドには、プール名または UUID が必要です。pool-autostart コマンドを無効にするには、--disable オプションを使用します。

15.11.3. ストレージプールの停止および削除

pool-destroy pool-or-uuid はストレージプールを停止します。いったん停止すると、libvirt はプールを管理しなくなりますが、プールに含まれる raw データは変更されず、後で pool-create コマンドを使って復旧されます。
pool-delete pool-or-uuid は、指定されたストレージプールで使用されたリソースを破棄します。この操作は修復不能で、元に戻せないことを留意するのは重要です。ただし、プール構成はこのコマンドの実行後も存在し、新規ストレージボリュームの作成を受け入れることができます。
pool-undefine pool-or-uuid コマンドは、アクティブでないプールの設定を定義解除します。

15.11.4. プール用の XML ダンプファイルの作成

pool-dumpxml --inactive pool-or-uuid コマンドは、指定されたストレージプールオブジェクトについての XML 情報を返します。--inactive を使用すると、現在のプール設定とは対照的に、プールの次回の開始時に使用される設定がダンプされます。

15.11.5. ストレージプールの設定ファイルの編集

pool-edit pool-or-uuid は、編集用に指定されたストレージプールの XML 設定ファイルを開きます。
この方法は、適用前にエラーのチェックを行うため、XML 設定ファイルの編集用に使用できる唯一の方法になります。

15.11.6. ストレージプールの変換

pool-name uuid コマンドは、指定された UUID をプール名に変換します。
pool-uuid pool コマンドは、指定されたプールの UUID を返します。

15.12. ストレージボリュームコマンド

このセクションでは、ストレージボリュームを作成し、削除し、管理するためのすべてのコマンドについて説明します。いったんストレージプールを作成すると、ストレージプール名または UUID が必要になるため、この時点でこれを実行するのが最善と言えるでしょう。ストレージプールについての詳細は、13章ストレージプール を参照してください。ストレージボリュームについての詳細は、14章ボリューム を参照してください。

15.12.1. ストレージボリュームの作成

vol-create-from pool-or-uuid file --inputpool pool-or-uuid vol-name-or-key-or-path は、別のストレージボリュームをコンテンツのテンプレートとして使用してストレージボリュームを作成します。このコマンドには、ボリュームの作成先となるストレージプールの名前または UUID である pool-or-uuid が必要となります。
file オプションは、ボリューム定義が含まれる XML ファイルとパスを指定します。--inputpool pool-or-uuid オプションは、ソースボリュームが入るストレージプールの名前または UUID を指定します。vol-name-or-key-or-path 引数は、ソースボリュームの名前またはキー、あるいはパスを指定します。いくつかの例については、「ボリュームの作成」 を参照してください。
vol-create-as コマンドは、一連の引数からボリュームを作成します。pool-or-uuid 引数には、ボリュームの作成に使用するストレージプールの名前または UUID が含まれます。
vol-create-as pool-or-uuid name capacity --allocation <size> --format <string> --backing-vol <vol-name-or-key-or-path> --backing-vol-format <string>
name は新規ボリュームの名前です。capacity は作成されるボリュームのサイズであり、サフィックスがない場合はデフォルトでバイトになる単位付き整数で指定されます。--allocation <size> は、ボリュームに割り当てられる初期サイズであり、これもデフォルトでバイトになる単位付き整数で指定されます。--format <string> は、コンマ区切りの許容される形式の文字列からなるボリュームファイル形式を指定するためにファイルベースのストレージプールで使用されます。許容される形式には、rawbochsqcowqcow2vmdk が含まれ、--backing-vol vol-name-or-key-or-path は、既存ボリュームのスナップショットを取る場合に使用されるソースのバッキングボリュームです。--backing-vol-format string は、コンマで区切られる形式の文字列であるスナップショットのバッキングボリュームの形式です。許可される値には、rawbochsqcowqcow2vmdk、および host_device が含まれます。ただし、これらはファイルベースのストレージプールの場合のみ使用されることが意図されています。

15.12.1.1. XML ファイルからのストレージボリュームの作成

vol-create pool-or-uuid file は、保存済みXML ファイルからストレージボリュームを作成します。このコマンドにも、ボリュームの作成先になるストレージプールの名前または UUID である pool-or-uuid が必要になります。file 引数には、ボリューム定義の XML ファイルと共にパスが含まれます。XML ファイルを作成する簡単な方法は、vol-dumpxml コマンドを使用して事前に存在するボリュームの定義を取得し、それを修正した後、vol-create を実行して保存します。
virsh vol-dumpxml --pool storagepool1 appvolume1 > newvolume.xml
virsh edit newvolume.xml 
virsh vol-create differentstoragepool newvolume.xml
以下のようなオプションも使用できます。
  • --inactive オプションは、アクティブではないゲスト仮想マシン (つまり、定義済みであるものの、現在アクティブではないゲスト仮想マシン) を一覧表示します。
  • --all オプションは、すべてのゲスト仮想マシンを一覧表示します。

15.12.1.2. ストレージボリュームのクローン作成

vol-clone --pool pool-or-uuid vol-name-or-key-or-path name コマンドは、既存のストレージボリュームをクローン作成します。vol-create-from を使用することもできますが、ストレージボリュームのクローン作成には推奨されません。--pool pool-or-uuid オプションは、ボリュームの作成に使用されるストレージプールの名前または UUID です。vol-name-or-key-or-path 引数は、ソースボリュームの名前またはキー、あるいはパスです。name 引数は、新規ボリューム名前を参照します。

15.12.2. ストレージボリュームの削除

vol-delete --pool pool-or-uuid vol-name-or-key-or-path コマンドは、指定したボリュームを削除します。このコマンドには、ボリュームに使用するストレージプールの名前または UUID である特定の --pool pool-or-uuid が必要です。vol-name-or-key-or-path オプションでは、削除するボリュームの名前またはキー、あるいはパスを指定します。
vol-wipe --pool pool-or-uuid --algorithm algorithm vol-name-or-key-or-path コマンドはボリュームを消去し、ボリューム上にあったデータをそれ以降の読み取りアクセスができないようにします。このコマンドには、ボリュームに使用するストレージプールの名前または UUID である --pool pool-or-uuid が必要です。vol-name-or-key-or-path には、完全に消去するボリュームの名前またはキー、あるいはパスを含めます。(ストレージボリュームの各セクターに「0」の値が書き込まれる) デフォルトの代わりに、異なる消去アルゴリズムを選択することも可能であることに注意してください。消去アルゴリズムを指定するには、--algorithm オプションにサポートされている以下のいずれかの アルゴリズム タイプを使用します。
  • zero - 1-pass all zeroes
  • nnsa - 4-pass NNSA Policy Letter NAP-14.1-C (XVI-8) for sanitizing removable and non-removable hard disks: random x2, 0x00, verify.
  • dod - 4-pass DoD 5220.22-M section 8-306 procedure for sanitizing removable and non-removable rigid disks: random, 0x00, 0xff, verify.
  • bsi - 9-pass method recommended by the German Center of Security in Information Technologies (http://www.bsi.bund.de): 0xff, 0xfe, 0xfd, 0xfb, 0xf7, 0xef, 0xdf, 0xbf, 0x7f.
  • gutmann - The canonical 35-pass sequence described in Gutmann’s paper.
  • schneier - 7-pass method described by Bruce Schneier in "Applied Cryptography" (1996): 0x00, 0xff, random x5.
  • pfitzner7 - Roy Pfitzner’s 7-random-pass method: random x7
  • pfitzner33 - Roy Pfitzner’s 33-random-pass method: random x33.
  • random - 1-pass pattern: random.

注記

ホストにインストールされるscrub バイナリーのバージョンは利用可能なアルゴリズムを制限します。

15.12.3. ストレージボリューム情報の XML ファイルへのダンプ

vol-dumpxml --pool pool-or-uuid vol-name-or-key-or-path コマンドは、ボリューム情報を、指定されたファイルへの XML ダンプとして取得します。
このコマンドには、ボリュームに使用される名前または UUID である --pool pool-or-uuid が必要です。vol-name-or-key-or-path は、結果として作成される XML ファイルを置くボリュームの名前、キーまたはパスです。

15.12.4. ボリューム情報の一覧表示

vol-info --pool pool-or-uuid vol-name-or-key-or-path コマンドは、所定のストレージボリューム --pool についての基本情報を一覧表示します。ここで、pool-or-uuid はボリュームに使用するストレージプールの名前または UUID です。vol-name-or-key-or-path は、返す情報の対象となるボリュームの名前またはキー、あるいはボリュームになります。
vol-list--pool pool-or-uuid --details は、指定されたストレージプールにすべてのボリュームを一覧表示します。このコマンドには、ストレージボリュームの名前または UUID である --pool pool-or-uuid が必要になります。--details オプションは、virsh に対し、ボリュームタイプおよび容量に関する情報を追加で表示するよう指示します (ある場合)。

15.12.5. ストレージボリューム情報の取得

vol-pool --uuid vol-key-or-path コマンドは、所定のボリュームのプール名または UUID を返します。デフォルトでは、プール名は返されます。--uuid オプションが指定される場合、プールの UUID が代わりに返されます。このコマンドには、要求される情報を返す際に使用されるボリュームのキーまたはパスである vol-key-or-path が必要になります。
vol-path --pool pool-or-uuid vol-name-or-key コマンドは、所定のボリュームのパスを返します。このコマンドには、ボリュームに使用されるストレージプールの名前または UUID である --pool pool-or-uuid が必要です。さらに、パスが要求される際に使用されるボリュームの名前またはキーである vol-name-or-key が必要です。
vol-name vol-key-or-path コマンドは、所定のボリュームの名前を返します。ここで、vol-key-or-path は名前を返すのに使用されるボリュームのキーまたはパスです。
vol-key --pool pool-or-uuid vol-name-or-path コマンドは、所定のボリュームのボリュームキーを返します。ここで、 --pool pool-or-uuid はボリュームに使用されるストレージプールの名前または UUID であり、vol-name-or-path はボリュームキーを返すのに使用されるボリュームの名前またはパスです。

15.12.6. ストレージボリュームのアップロードおよびダウンロード

このセクションでは、ストレージボリュームに情報をアップロードする方法およびストレージボリュームから情報をダウンロードする方法について説明します。

15.12.6.1. コンテンツのストレージボリュームへのアップロード

vol-upload --pool pool-or-uuid --offset bytes --length bytes vol-name-or-key-or-path local-file コマンドは、指定された local-file のコンテンツをストレージボリュームにアップロードします。このコマンドには、ボリュームに使用される名前または UUID である --pool pool-or-uuid が必要です。さらに、完全消去するボリュームの名前またはキー、あるいはパスである vol-name-or-key-or-path も必要です。--offset オプションは、データの書き込みを開始するストレージボリューム内の位置を指します。--length length は、アップロードされるデータ量の上限を決定します。local-file が指定された --length の値よりも大きい場合はエラーが発生します。

15.12.6.2. ストレージボリュームからのコンテンツのダウンロード

vol-download --pool pool-or-uuid --offset bytes -length bytes vol-name-or-key-or-path local-file コマンドは、ストレージボリュームから local-file のコンテンツをダウンロードします。
このコマンドには、ボリュームに使用されるストレージプールの名前または UUID である --pool pool-or-uuid が必要です。さらに、完全消去するボリュームの名前またはパスである vol-name-or-key-or-path が必要です。--offset オプションを使用すると、データの読み込みを開始するストレージボリューム内の位置が決定されます。--length length は、ダウンロードされるデータの量の上限を決定します。

15.12.7. ストレージボリュームのサイズ変更

vol-resize --pool pool-or-uuid vol-name-or-path pool-or-uuid capacity --allocate --delta --shrink コマンドは、所定のボリュームの容量 (バイト単位) のサイズ変更を行います。このコマンドには、ボリュームに使用されるストレージプールの名前または UUID である --pool pool-or-uuid が必要です。さらに、このコマンドには、サイズ変更するボリュームの名前またはキー、あるいはパスである vol-name-or-key-or-path が必要です。
--allocate オプションが指定されていないと、新たな容量はスパースファイルを作成します。通常、容量は新規のサイズになりますが、--delta がある場合、既存のサイズに追加されます。--shrink オプションがないと、ボリュームを縮小する試みは失敗します。
--shrink オプションが指定されていなければ、容量は負の値にならず、負の符号は不要であることに注意してください。capacity は、接尾辞がない場合、デフォルトがバイトになる単位付き整数です。またこのコマンドは、アクティブなゲストが使用していないストレージボリュームの場合にのみ安全であることにも注意してください。ライブのサイズ変更については、「blockresize を使用したドメインパスのサイズ変更」 を参照してください。

15.13. ゲスト仮想マシン別の情報の表示

15.13.1. ゲスト仮想マシンの表示

virsh を使ってゲスト仮想マシンの一覧と、それらの現在の状態を表示するには、以下を実行します。
# virsh list
以下のようなオプションも使用できます。
  • --inactive オプション: アクティブではないゲスト仮想マシン (つまり、定義されているものの、現在アクティブではないゲスト仮想マシン) を一覧表示します。
  • --all オプション: すべてのゲスト仮想マシンを一覧表示します。たとえば、以下のようになります。
    # virsh list --all
     Id Name                 State
    ----------------------------------
      0 Domain-0             running
      1 Domain202            paused
      2 Domain010            inactive
      3 Domain9600           crashed
    このコマンドで確認できる状態は 7 種類あります。
    • Running - running 状態は、CPU 上で現在稼働中のゲスト仮想マシンを示します。
    • Idle - idle 状態は、 ドメインが休止中のため、稼働していないか、または稼働できないことを示します。ドメインが IO を待機しているため (従来の待機状態)、または作業がないためにスリープに入ったことが原因となります。
    • Paused - paused 状態は、一時停止中のドメインを一覧表示します。これは、管理者が virt-manager、または virsh suspendpause ボタンを使用した場合に発生します。これは、ゲスト仮想マシンが一時停止になっている場合にはメモリーと他のリソースを消費しますが、スケジュールとハイパーバイザーからの CPU リソースの場合は無効になります。
    • Shutdown - shutdown 状態は、シャットダウンプロセスにあるゲスト仮想マシンの状態です。ゲスト仮想マシンには、シャットダウン信号が送られて、その稼働を正常に停止するプロセスに入ります。これはすべてのゲスト仮想マシンのオペレーティングシステムでは機能しないかもしれません。一部のオペレーティングシステムはこれらの信号に反応しません。
    • Shut off - shut off 状態は、ドメインが稼働していないことを示します。これは、ドメインが完全にシャットダウンするか、または開始していないことが原因です。
    • Crashed - crashed 状態は、ドメインがクラッシュしており、さらにゲスト仮想マシンがクラッシュ時に再起動しないように設定をされている場合にのみ発生します。
    • Dying - dying 状態は、停止のプロセスに入っています。ドメインが完全にシャットダウンしていないか、またはクラッシュした状態です。
  • --managed-save このフラグだけではドメインをフィルターしませんが、管理保存の状態が有効になったドメインを一覧表示します。ドメインを別個に一覧表示するには、--inactive フラグも使用する必要があります。
  • --name は、指定されたドメイン名で、一覧に出力されます。--uuid が指定される場合、ドメインの UUID が代わりに出力されます。フラグの --table を使用すると、テーブルスタイルの出力が使用されるよう指定されます。これらの 3 つのコマンドは相互に排他的です。
  • --title このコマンドは --table 出力と共に使用する必要があります。--title により、追加の列が短いドメインの説明 (タイトル) と共にテーブルに作成されます。
  • --persistent は、永続的なドメインを一覧に含めます。--transient オプションを使用します。
  • --with-managed-save は、管理保存と共に設定されたドメインを一覧表示します。管理保存なしでコマンドを一覧表示するには、コマンド --without-managed-save を使用します。
  • --state-running は、実行中のドメインに対してフィルターをかけます。一時停止のドメインについては --state-paused、オフにされているドメインについては --state-shutoff が使用されます。--state-other は、すべての状態を fallback として一覧表示します。
  • --autostart: このオプションは、自動起動のドメインを一覧表示します。この機能を無効にしてドメインを一覧表示するには、--no-autostart オプションを使用します。
  • --with-snapshot は、スナップショットイメージを一覧表示できるドメインを一覧表示します。スナップショットなしでドメインをフィルター処理するには、--without-snapshot オプションを使用します。
$ virsh list --title --name

    Id       Name                                          State     Title
    0        Domain-0                                      running   Mailserver1
    2        rhelvm                                        paused
virsh vcpuinfo の出力例については、「仮想 CPU 情報を表示する」を参照してください。

15.13.2. 仮想 CPU 情報を表示する

virsh を使ってゲスト仮想マシンから仮想 CPU 情報を表示するには、以下を実行します。
# virsh vcpuinfo {domain-id, domain-name or domain-uuid}
virsh vcpuinfo 出力の一例:
# virsh vcpuinfo rhel6
VCPU:           0
CPU:            2
State:          running
CPU time:       7152.4s
CPU Affinity:   yyyy

VCPU:           1
CPU:            2
State:          running
CPU time:       10889.1s
CPU Affinity:   yyyy

15.13.3. 仮想 CPU の親和性を設定する

仮想 CPU の物理 CPU との親和性を設定するには、例15.3「vCPU をホスト物理マシンの CPU にピン設定する」を参照してください。

例15.3 vCPU をホスト物理マシンの CPU にピン設定する

virsh vcpupin は、仮想 CPU を物理 CPU に割り当てます。
# virsh vcpupin rhel6
VCPU: CPU Affinity
----------------------------------
   0: 0-3
   1: 0-3
vcpupin コマンドは、以下のオプションを取ります。
  • --vcpu には vcpu 番号が必要です。
  • [--cpulist] >string< は、設定するホスト物理マシンの CPU 番号を一覧表示するか、またはオプションのクエリーを省略します。
  • --config は次回の起動に影響を与えます。
  • --live は稼働中のドメインに影響を与えます。
  • --current は現在のドメインに影響を与えます。

15.13.4. ドメインの仮想 CPU 数についての情報の表示

virsh vcpucount には、domain名またはドメイン ID が必要です。例を示します。
# virsh vcpucount rhel6
maximum      config         2
maximum      live           2
current      config         2
current      live           2
vcpucount コマンドは、以下のオプションを取ります。
  • --maximum は、利用可能な vCPU の最大数を表示します。
  • --active は、現在アクティブな vCPU の数を表示します。
  • --live は、稼働中のドメインからの値を表示します。
  • --config は、ゲスト仮想マシンの次回の起動で設定される値を表示します。
  • --current は、現在のドメイン状態に準じた値を表示します。
  • --guest は、ゲスト側から見たカウントを表示します。

15.13.5. 仮想 CPU の親和性を設定する

物理 CPU と仮想 CPU の親和性を設定するには、以下のようにします。
# virsh vcpupin domain-id vcpu cpulist
domain-id パラメーターは、ゲスト仮想マシンの ID 番号または名前です。
vcpu パラメーターはゲスト仮想マシンに割り当てられた仮想化 CPU の数を示します。vcpu パラメーターを指定する必要があります。
cpulist パラメーターは物理 CPU の識別子番号をコンマで区切った一覧です。cpulist パラメーターで VCPU を実行する物理 CPU を指定します。
--config などの追加のパラメーターは次回の起動に影響を与えますが、--live は稼働中のドメインに、 --current は現在のドメインに影響を与えます。

15.13.6. 仮想 CPU 数を設定する

デフォルトで、仮想 CPU (vCPU) 数はアクティブなゲストドメイン上でのみ変更できます。アクティブでないゲストドメインの設定を変更するには、--config フラグを使用します。virsh コマンドを使って、ゲスト仮想マシンに割り当てられる CPU の数を変更します。
# virsh setvcpus {domain-name, domain-id or domain-uuid} count [[--config] [--live] | [--current] [--guest] 
以下のパラメーターを virsh setvcpus コマンドに設定することができます。
  • {domain-name, domain-id or domain-uuid} - 仮想マシンを指定します。
  • --count - 設定する仮想 CPU の数を指定します。

    重要

    --count 値は、ゲスト仮想マシンの作成時にゲスト仮想マシンに割り当てられた CPU の数を超えることはできません。
  • --maximum - 次回の起動時に仮想 CPU の上限値を設定します。
  • --config - 設定変更は次回の起動時に有効になります。
  • --live - 設定変更は、稼働中のゲスト仮想マシンで有効になります。
  • --current - 設定変更は、現在のゲスト仮想マシンで有効になります。
  • --guest - 設定変更は、ゲスト仮想マシンの CPU の状態を変更します。--guest で行なわれた設定は、ゲストの再起動時にリセットされます。

注記

multi-queue, を使用して vCPU のパフォーマンスを強化する方法についての詳細は、『Red Hat Enterprise Linux 仮想化のチューニングと最適化ガイド』を参照してください。

例15.4 vCPU のホットプラグとホットアンプラグ

vCPU をホットプラグするには、以下のコマンドを実行します。
virsh setvcpus guestVM1 2 --live
上記の例では、--live フラグが示すように guestVM1 の実行中に guestVM1 の vCPU 数は 2 つ増加します。
同様に、同じ稼働中のゲストから 1 つの vCPU をホットアンプラグするには、以下を実行します。
virsh setvcpus guestVM1 1 --live
値は、ホスト、ハイパーバイザー、またはゲストドメインの元の記述による制限によって制限される可能性があります。Xen の場合、ドメインが準仮想化されている場合は稼働中のドメインの仮想 CPU のみを調整できます。
--config フラグが指定されている場合、変更はゲスト仮想マシンの保存された XML 設定に対して行なわれ、ゲストドメインの次回起動時にのみ有効になります。
--live が指定されている場合、ゲスト仮想マシンのドメインはアクティブであるはずであり、変更はただちに有効になります。このフラグにより、vCPU のホットプラグが可能になります。--config フラグと --live フラグの両方は、ハイパーバイザーにサポートされている場合、一緒に指定することができます。
--current が指定されている場合、フラグは、現在のアクティブなゲスト仮想マシンの状態に影響を与えます。フラグが指定されていない場合、--live フラグがデフォルトで使用されます。アクティブなゲスト仮想マシンがない場合にフラグなしでこのコマンドを実行すると、失敗します。場合によっては、ハイパーバイザーは --config の使用も想定します。さらにハイパーバイザーは、変更を永続的にするために XML 設定を調整するかどうかを決定します。
--maximum フラグは、ドメインの次回起動時にホットプラグできる仮想 CPU の最大数を制御できます。そのため、このフラグは --config フラグとのみ使用する必要があり、--live フラグと一緒に使用することはできません。

15.13.7. メモリー割り当てを設定する

virsh を使ってゲスト仮想マシンのメモリー割り当てを変更するには、以下を実行します。
# virsh setmem {domain-id or domain-name} count
# virsh setmem vr-rhel6u1-x86_64-kvm --kilobytes 1025000
count はキロバイトで指定する必要があります。新規のカウント値はゲスト仮想マシンの作成時に指定した数を超過することはできません。64 MB 未満の値は、ほとんどのゲスト仮想マシンのオペレーティングシステムでは機能しない可能性があります。それ以上の値が最大メモリー数値である場合は、アクティブなゲスト仮想マシンに影響しません。新規の値が利用可能なメモリーを下回る場合、縮小されてゲスト仮想マシンがクラッシュする原因になるかもしれません。
このコマンドには、以下のフラグが使用されます。
  • [--domain] <string> ドメイン名、id または uuid
  • [--size] <number> 新たに設定するメモリーサイズ、単位付き整数で指定 (デフォルトは KiB)
    有効なメモリーの単位には以下が含まれます。
    • バイト、b または bytes
    • キロバイト、KB (103 または 1,000 バイトのブロック)
    • キビバイト、k または KiB (210 または 1024 バイトのブロック)
    • メガバイト、MB (106 または 1,000,000 バイトのブロック)
    • メビバイト、M または MiB (220 または 1,048,576 バイトのブロック)
    • ギガバイト、GB (109 または 1,000,000,000 バイトのブロック)
    • ギビバイト、G または GiB (230 または 1,073,741,824 バイトのブロック)
    • テラバイト、TB (1012 または 1,000,000,000,000 バイトのブロック)
    • テビバイト、T または TiB (240 または 1,099,511,627,776 バイトのブロック)
    libvirt によって値はすべて直近のキビバイトに切り上げられ、ハイパーバイザーで対応できる単位までさらに切り上げられる場合があることに注意してください。また、ハイパーバイザーの中には、4000KiB (または 4000 x 210 または 4,096,000 バイト) などの最小値を強制するものがあります。この値の単位は memory unit というオプションの属性で確定されます。この属性では、測定単位のキビバイト (KiB) にデフォルト設定されます (210 または 1024 バイトブロック単位)。
  • --config 次回起動時に有効になります。
  • --live 実行中のドメインのメモリーを制御します。
  • --current 現在のドメイン上のメモリーを制御します。

15.13.8. ドメインのメモリー割り当ての変更

virsh setmaxmem domain サイズ --config --live --current は、以下のようにゲスト仮想マシンの最大メモリー割り当ての設定を許可します。
virsh setmaxmem rhel6 1024 --current
最大メモリーに指定できるサイズは、サポートされる接尾辞が指定されない限り、キビバイト単位でデフォルト設定される単位付き整数になります。以下のオプションがこのコマンドと共に使用できます。
  • --config - 次回起動時に有効になります。
  • --live - すべてのハイパーバイザーがメモリーの上限のライブ変更を許可する訳ではないため、ハイパーバイザーがこのアクションをサポートする場合に、実行中のドメインのメモリーを制御します。
  • --current - 現在のドメイン上のメモリーを制御します。

15.13.9. ゲスト仮想マシンのブロックデバイス情報の表示

virsh domblkstat を使用して、実行中のゲスト仮想マシンについてブロックデバイスの統計を表示できます。
# virsh domblkstat GuestName block-device

15.13.10. ゲスト仮想マシンのネットワークデバイス情報の表示

virsh domifstat を使用して、実行中のゲスト仮想マシンについてネットワークインターフェースの統計を表示できます。
# virsh domifstat GuestName interface-device 

15.14. 仮想ネットワークを管理する

このセクションでは、virsh コマンドで仮想ネットワークを管理する方法について説明します。仮想ネットワークの一覧を表示するには、 以下のようにします。
# virsh net-list
このコマンドを実行すると以下のような出力を生成します。
# virsh net-list
Name                 State      Autostart
-----------------------------------------
default              active     yes      
vnet1	             active     yes      
vnet2	             active     yes
特定の仮想ネットワークのネットワーク情報を表示するには、以下のようにします。
# virsh net-dumpxml NetworkName
指定した仮想ネットワークに関する情報が XML 形式で表示されます。
# virsh net-dumpxml vnet1
<network>
  <name>vnet1</name>
  <uuid>98361b46-1581-acb7-1643-85a412626e70</uuid>
  <forward dev='eth0'/>
  <bridge name='vnet0' stp='on' forwardDelay='0' />
  <ip address='192.168.100.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.100.128' end='192.168.100.254' />
    </dhcp>
  </ip>
</network>
仮想ネットワークの管理に使用される他の virsh コマンドを以下に示します。
  • virsh net-autostart network-name network-name で指定されたネットワークを自動的に開始します。
  • virsh net-create XMLfile — 既存の XML ファイルを使って新規ネットワークを生成し、 開始します。
  • virsh net-define XMLfile — 既存の XML ファイルから新規のネットワークデバイスを開始せずに生成します。
  • virsh net-destroy network-name network-name で指定されたネットワークを破棄します。
  • virsh net-name networkUUID — 指定した networkUUID をネットワーク名に変換します。
  • virsh net-uuid network-name — 指定した network-name をネットワーク UUID に変換します。
  • virsh net-start nameOfInactiveNetwork — 停止中のネットワークを開始します。
  • virsh net-undefine nameOfInactiveNetwork — 停止中のネットワークの定義を削除します。

15.15. virsh を使用したゲスト仮想マシンの移行

virsh を使用した移行についての詳細は、「virsh を使用した KVM のライブマイグレーション」のセクションをご覧ください (「virsh を使用した KVM のライブマイグレーション」)。

15.15.1. インターフェースコマンド

以下のコマンドはホストインターフェースを操作するので、ゲスト仮想マシンから実行することはできません。これらのコマンドは、ホスト物理マシンのターミナルから実行する必要があります。

警告

マシンの NetworkManager サービスが無効にされており、network サービスが代わりに使用されている場合は、このセクションに記載のコマンドのみがサポートされます。
これらのホストインターフェースは、ドメインの <interface> 要素内の名前 (system-created bridge interface など) で使用されることがよくありますが、ホストインターフェースを特定のゲスト設定 XML に関連付けるという要件はありません。ホストインターフェースのコマンドの多くはドメインに使用されるものに類似しており、インターフェースの命名は、その名前を使用するか、またはその MAC アドレスを使用するかのいずれかになります。ただし、iface オプションでの MAC アドレスの使用は、アドレスが固有な場合にのみ機能します (インターフェースとブリッジが同じ MAC アドレスを共有することはよくありますが、この場合、MAC アドレスを使用すると、曖昧さが原因でエラーが生じるため、代わりに名前を使用する必要があります)。

15.15.1.1. XML ファイルによるホスト物理マシンインターフェースの定義と開始

virsh iface-define file コマンドは、XML ファイルからホストインターフェースを定義します。このコマンドはインターフェースのみを定義し、これを開始することはありません。
virsh iface-define iface.xml
すでに定義されたインターフェースを開始するには、iface-start interface を実行します。ここで、interface はインターフェース名です。

15.15.1.2. ホストインターフェース用 XML 設定ファイルの編集

コマンド iface-edit interface は、ホストインターフェースの XML 設定ファイルを編集します。これは、XML 設定ファイルを編集するための 唯一 推奨される方法です (これらのファイルについては、21章ドメイン XML の操作 を参照してください)。

15.15.1.3. アクティブなホストインターフェースの一覧表示

iface-list --inactive --all は、アクティブなホストインターフェースの一覧を表示します。--all が指定されている場合、この一覧には、定義されているものの、アクティブではないインターフェースが含まれます。--inactive が指定される場合、アクティブではないインターフェースのみが一覧表示されます。

15.15.1.4. MAC アドレスのインターフェース名への変換

iface-name interface コマンドは、MAC アドレスがホストのインターフェース間で固有な場合に、ホストインターフェースの MAC をインターフェース名に変換します。このコマンドには、インターフェースの MAC アドレスである interface が必要になります。
iface-mac interface コマンドは、この場合 interface がインターフェース名になりますが、ホストのインターフェース名を MAC アドレスに変換します。

15.15.1.5. 特定ホスト物理マシンのインターフェースの停止

virsh iface-destroy interface コマンドは、ホストの実行中の if-down と同じ、所定のホストインターフェースを破棄 (停止) します。このコマンドは、インターフェースがアクティブに使用されることを停止し、ただちに有効になります。
インターフェースの定義解除を行うには、インターフェース名を使用して iface-undefine interface コマンドを使用します。

15.15.1.6. ホスト設定ファイルの表示

virsh iface-dumpxml interface --inactive は、標準出力 (stdout) への XML ダンプとしてホストのインターフェースを表示します。--inactive オプションを指定すると、出力には次回の起動時に使用されるインターフェースの永続状態が反映されます。

15.15.1.7. ブリッジデバイスの作成

iface-bridge は、ブリッジデバイスが指定するブリッジを作成し、既存のネットワークデバイスインターフェースを新規のブリッジに割り当てます。新規のブリッジは、STP が有効な状態、かつ遅延 0 の状態でただちに機能を開始します。
# virsh iface-bridge interface bridge --no-stp delay --no-start
これらの設定は、--no-stp、--no-start、および遅延の秒数を表す整数を使って変更できることに注意してください。インターフェースのすべての IP アドレス設定は、新規のブリッジデバイスに移行します。ブリッジを破棄する方法についての詳細は、「ブリッジデバイスの破棄」を参照してください。

15.15.1.8. ブリッジデバイスの破棄

iface-unbridge bridge --no-start コマンドは、bridge という名前の指定されたブリッジデバイスを破棄し、その基礎となるインターフェースを通常に使用状態に戻し、ブリッジデバイスから基礎となるデバイスにすべての IP アドレス設定を移行します。--no-start オプションを使用しなければ、この基礎となるインターフェースは再起動しますが、再起動することが通常推奨されていることに注意してください。ブリッジ作成のコマンドについては、「ブリッジデバイスの作成」を参照してください。

15.15.1.9. インターフェーススナップショットの操作

iface-begin コマンドは、現在のホストインターフェースの設定のスナップショットを作成し、それは後にコミット (iface-commit を使用) されるか、または復元 (iface-rollback を使用) されます。スナップショットがすでに存在する場合、このコマンドは直前のスナップショットがコミットされるか、または復元されない限り失敗します。外部の変更が libvirt API 外のホストインターフェースに対して、スナップショットの作成時からその後のコミットまたはロールバックの間までに行なわれる場合、未定義の動作が生じます。
最後に iface-begin を実行してから行なわれたすべての変更を機能しているものとして宣言するために、iface-commit コマンドを使用し、次にロールバックポイントを削除します。iface-begin でインターフェースのスナップショットが起動されていない場合、このコマンドは失敗します。
iface-rollback を使用して、iface-begin コマンドが実行された最終時を記録した状態に、すべてのホストインターフェース設定を戻します。iface-begin コマンドがそれまでに実行されていなかった場合、iface-rollback は失敗します。ホスト物理マシンの再起動は、暗黙的なロールバックポイントとしても機能する点に注意してください。

15.15.2. スナップショットの管理

以降のセクションでは、ドメインスナップショットを操作するために実行できるアクションについて説明します。スナップショット は、指定された時点のドメインのディスク、メモリー、およびデバイスの状態を取得し、今後の使用に備えて保存します。スナップショットには、OS イメージの「クリーンな」コピーを保存することから、破壊的な操作となりかねない操作を実行する前のドメインの状態を保存することに至るまで数多くの使用方法があります。スナップショットは固有の名前で識別されます。スナップショットのプロパティーを表すために使用される XML 形式のドキュメントについては、libvirt web サイト を参照してください。

15.15.2.1. スナップショットの作成

virsh snapshot create コマンドは、ドメインの XML ファイルで指定されたプロパティーでドメインのスナップショットを作成します (<name> および <description> 要素、ならびに <disks>)。
スナップショットを作成するには、以下を実行します。
# snapshot-create <domain> <xmlfile> [--redefine] [--current] [--no-metadata] [--reuse-external] 
ドメイン名、ID、または UID を、ドメイン要件として使用することができます。XML 要件は、<name>、<description> および <disks> 要素を含んでいる文字列です。

注記

ライブスナップショットは Red Hat Enterprise Linux ではサポートされません。ライブスナップショットに使用するための virsh snapshot create コマンドと使用可能な追加のオプションがあり、これらは libvirt では表示されますが、Red Hat Enterprise Linux 6 ではサポートされていません。
Red Hat Enterprise Linux で利用できるオプションには、以下のものがあります。
  • --redefine は、snapshot-dumpxml で生成されるすべての XML 要素が有効な場合、以下を実行できるように指定します。あるマシンから別のマシンにスナップショットの階層を移行する、途中でなくなり、後に同じ名前および UUID で再作成される一時的なドメイン用に階層を再作成する、またはスナップショットのメタデータに若干の変更を加える (例: スナップショットに組み込まれるドメイン XML のホスト固有の部分など)。このフラグが指定されると、xmlfile 引数は必須となり、ドメインの現在のスナップショットは、--current フラグも指定されない限り変更されることがありません。
  • --no-metadata はスナップショットを作成しますが、すべてのメタデータはただちに破棄されます (つまり、libvirt はスナップショットを現在の状態で処理せず、--redefine が後に使用されて libvirt にメタデータについて再度指示しない限り、スナップショットには戻りません)。
  • --reuse-external を使用する場合は、使用する外部の既存 XML スナップショットの場所を指定します。このスナップショットがまだない場合は、既存ファイルのコンテンツを失くさないように、コマンドはスナップショットの取得に失敗します。

15.15.2.2. 現在のドメインのスナップショットの作成

virsh snapshot-create-as domain コマンドは、ドメインのスナップショットを、ドメイン XML ファイルで指定されたプロパティーを使って作成します ( (<name> 要素と <description> 要素など)。これらの値が XML 文字列に含まれない場合、libvirt が値を選択します。スナップショットを作成するには、以下を実行します。
# virsh snapshot-create-as domain {[--print-xml] | [--no-metadata] [--reuse-external]} [name] [description] [--diskspec] diskspec]
他のオプションは次の通りです。
  • --print-xml は、実際にスナップショットを作成するのではなく、出力として snapshot-create の適切な XML を作成します。
  • --diskspec オプションは、--disk-only および外部チェックポイントが外部ファイルを作成する方法を制御するために使用できます。このオプションは、ドメイン XML の <disk> 要素に基づいて複数回使用される可能性があります。それぞれの <diskspec> は以下の形式で表されます。disk[,snapshot=type][,driver=type][,file=name] リテラルコンマを disk または file=name に組み込むには、2 番目のコンマでそれをエスケープします。リテラルの --diskspec は、<domain>, <name>, and <description> の 3 つすべてが表示されない限り、それぞれのディスク仕様の前に置かれる必要があります。たとえば、diskspec が vda,snapshot=external,file=/path/to,,new の場合、以下の XML が生成されます。
    
    <disk name=’vda’ snapshot=’external’>
       <source file=’/path/to,new’/>
    </disk>
    
  • --reuse-external は、既存のファイルを移行先として再利用し (つまりこのファイルは上書きされます)、外部のスナップショットを作成します。この移行先が存在しない場合は、既存ファイルのコンテンツが失われないようにするために、スナップショットの要求は拒否されます。
  • --no-metadata はスナップショットデータを作成しますが、すべてのメタデータはただちに破棄されます (つまり、libvirt は、snapshot-create が後に使用され、libvirt に対してメタデータについて再び指示がなされない限り、スナップショットを現状の状態で処理せず、スナップショットには戻りません)。このフラグには --print-xml との互換性はありません。

15.15.2.3. 現在のドメインのスナップショットの取得

このコマンドは、現在使用されているスナップショットのクエリーを行うために使用されます。これを使用するには、以下を実行します。
# virsh snapshot-current domain {[--name] | [--security-info] | [snapshotname]}
snapshotname が使用されていない場合、ドメインの現在のスナップショットのスナップショット XML (ある場合) は出力として表示されます。--name が指定されている場合、完全な XML ではなく、現在のスナップショット名のみが出力として送信されます。--security-info が指定される場合、セキュリティー上の機密情報が XML に組み込まれます。snapshotname を使用する場合、libvirt は、ドメインに戻さずに、既存の指定されたスナップショットを現在のスナップショットにする要求を生成します。

15.15.2.4. snapshot-edit-domain

このコマンドは、現在使用されているスナップショットを編集するために使用されます。これを使用するには、以下を実行します。
#virsh snapshot-edit domain [snapshotname] [--current] {[--rename] [--clone]}
snapshotname--current の両方が指定される場合、編集されたスナップショットを現在のスナップショットにするように強制します。snapshotname が省略されている場合、現在のスナップショットを編集するために --current を指定する必要があります。
これは、以下のコマンドシーケンスと同等ですが、エラーチェック機能が一部含まれます。
# virsh snapshot-dumpxml dom name > snapshot.xml
# vi snapshot.xml [note - this can be any editor]
# virsh snapshot-create dom snapshot.xml --redefine [--current]
--rename が指定されている場合、結果として生じる編集済みのファイルは異なるファイル名で保存されます。--clone が指定される場合、スナップショット名の変更により、スナップショットのメタデータのクローンが作成されます。いずれも指定されていない場合、編集によりスナップショット名が変更されることはありません。単一の qcow2 ファイル内の内部スナップショットなど、一部のスナップショットのコンテンツは元のスナップショットのファイル名からアクセス可能であるため、スナップショット名の変更は注意して行う必要があります。

15.15.2.5. snapshot-info-domain

snapshot-info-domain は、スナップショットについての情報を表示します。これを使用するには、以下を実行します。
# snapshot-info domain {snapshot | --current}
指定された snapshot についての基本的な情報を出力するか、--current で現在のスナップショットを出力します。

15.15.2.6. snapshot-list-domain

所定ドメインの利用可能なスナップショットすべてを一覧表示します。デフォルトでは、スナップショット名、作成時およびドメインの状態の列が表示されます。これを使用するには、以下を実行します。
#virsh snapshot-list domain [{--parent | --roots | --tree}] [{[--from] snapshot | --current} [--descendants]] [--metadata] [--no-metadata] [--leaves] [--no-leaves] [--inactive] [--active] [--internal] [--external]
他のオプションは次の通りです。
  • --parent は、各スナップショットの親の名前を指定する出力テーブルに列を追加します。このオプションは、--roots または --tree と共に使用することはできません。
  • --roots は、親のないスナップショットのみを表示するために一覧をフィルターします。このオプションは、--parent または --tree と共に使用することはできません。
  • --tree は、出力をツリー形式で表示し、スナップショット名のみを一覧表示します。これらの 3 つのオプションは相互に排他的です。このオプションは、--roots または --parent と共に使用することはできません。
  • --from は、所定スナップショットの子であるスナップショットの一覧をフィルターします。または、--current が指定される場合、一覧を現在のスナップショットで開始させるようにします。一覧が分離してか、または --parent と共に使用される場合、--descendants も表示されない限り、直接の子に限定されます。--tree と共に使用される場合、--descendants の使用が暗黙的に示されます。このオプションには、--roots との互換性がありません。--tree オプションも存在しない限り、--from の開始点または --current はこの一覧に含まれません。
  • --leaves が指定されると、一覧は子のないスナップショットのみにフィルターされます。同様に、--no-leaves が指定されると、一覧は子を持つスナップショットのみにフィルターされます。(いずれのオプションも省略すると、フィルターは実行されず、両方を指定すると、サーバーがフラグを認識するかどうかによって、同じ一覧が生成されるか、またはエラーが出されます)。フィルターオプションには --tree との互換性がありません。
  • --metadata が指定されると、一覧が libvirt メタデータに関連するスナップショットのみにフィルターされるため、永続的なドメインの定義解除が回避されるか、または一覧が一時的なドメインの破棄によって失われます。同様に、--no-metadata が指定される場合、一覧は libvirt メタデータのなしに存在するスナップショットのみにフィルターされます。
  • --inactive が指定されると、一覧は、ドメインの停止時に取られたスナップショットにフィルターされます。--active が指定される場合、一覧は、ドメインの実行時に取られたスナップショットにフィルターされ、このスナップショットには、実行中の状態に戻るためのメモリー状態が含まれます。--disk-only が指定される場合、一覧はドメインの実行中に取られたスナップショットにフィルターされますが、このスナップショットにはディスク状態のみが含まれます。
  • --internal が指定されると、一覧は、既存のディスクイメージの内部ストレージを使用するスナップショットにフィルターされます。--external が指定される場合、一覧はディスクイメージの外部ファイルまたはメモリー状態を使用するスナップショットにフィルターされます。

15.15.2.7. snapshot-dumpxml domain snapshot

virsh snapshot-dumpxml domain snapshot は、snapshot という名前のドメインのスナップショットのスナップショット XML を出力します。これを使用するには、以下を実行します。
# virsh snapshot-dumpxml domain snapshot [--security-info]
また、--security-info オプションには、セキュリティー上の機密情報も含まれます。現在のスナップショットの XML に簡単にアクセスするには、snapshot-current を使用します。

15.15.2.8. snapshot-parent domain

所定スナップショット、または --current を使って現在のスナップショットの親スナップショット (ある場合) の名前を出力します。これを使用するには、以下を実行します。
#virsh snapshot-parent domain {snapshot | --current}

15.15.2.9. snapshot-revert domain

所定ドメインを、snapshot で指定されるスナップショットか、または --current により現在のスナップショットに戻します。

警告

これは破壊的なアクションであることに注意してください。最後にスナップショットが取られてから加えられたドメインへの変更は失われます。さらに、snapshot-revert の完了後のドメインの状態が元のスナップショットが取られた時点のドメインの状態であることにも注意してください。
スナップショットを元に戻すには、以下を実行します。
# snapshot-revert domain {snapshot | --current} [{--running | --paused}] [--force]
通常、スナップショットに戻すと、ドメインはスナップショットが取られた時点の状態に置かれます。ただし、例外として、ゲスト仮想マシンの状態が設定されていないディスクのスナップショットは、ドメインをアクティブでない状態にします。--running または --paused フラグは、追加の状態変更を実行します (アクティブでないドメインの起動、または実行中のドメインの一時停止など)。一時的なドメインはアクティブではないため、一時的なドメインのディスクスナップショットに戻る場合に、これらのフラグのいずれかを使用する必要があります。
snapshot revert--force の使用が必要になる追加のリスクの伴う場合として 2 つのケースがあります。1 つは、設定を戻すために必要な詳細なドメイン情報がスナップショットにない場合です。この場合、libvirt は現在の設定がスナップショットの作成時に使用された設定に一致することを証明できないため、--force を指定することにより、libvirt に対し、スナップショットには現在の設定との互換性がある (さらに、互換性がない場合はドメインの実行が失敗する可能性がある) ことを保証します。もう 1 つのケースは、実行中のドメインをアクティブな状態に戻す場合で、この場合、既存の VNC または Spice 接続を中断するなどの障害が暗示されるため、既存のハイパーバイザーを再利用するのではなく、新規のハイパーバイザーを作成する必要があります。この状態は、互換性がない可能性のある設定を使用するアクティブなスナップショットや、--start または --pause フラグで組み合わされたアクティブでないスナップショットについて発生します。

15.15.2.10. snapshot-delete domain

snapshot-delete domain は指定されたドメインのスナップショットを削除します。これを実行するには、以下を実行します。
# virsh snapshot-delete domain {snapshot | --current} [--metadata] [{--children | --children-only}]
このコマンドは、snapshot という名前のドメインのスナップショットを削除するか、または --current で現在のスナップショットを削除します。このスナップショットに子のスナップショットがある場合、このスナップショットの変更は子にマージされます。オプションの --children が使用される場合、このスナップショットとこのスナップショットのすべての子が削除されます。--children-only が使用される場合、このスナップショットの子が削除され、このスナップショットは元の状態のままにされます。これらの 2 つのフラグは相互に排他的です。
--metadata が使用されると、libvirt で維持されるスナップショットのメタデータが削除され、一方でスナップショットのコンテンツは外部ツールがアクセスできるように元の状態にされます。そうしないと、スナップショットの削除により、その時点からのデータのコンテンツも削除されてしまいます。

15.16. ゲスト仮想マシンの CPU モデルの設定

15.16.1. はじめに

それぞれのハイパーバイザーには、ゲスト仮想マシンにデフォルトで表示する CPU 情報に関して独自のポリシーがあります。ゲスト仮想マシンで使用できる CPU ホストの物理マシン機能をハイパーバイザー側で決めるものもあれば、QEMU/KVM ではゲスト仮想マシンには qemu32 または qemu64 という汎用モデルを表示します。こうしたハイパーバイザーでは、より高度なフィルター機能を備え、すべての物理 CPU をいくつかのグループに分類して、ゲスト仮想マシンに対して表示するベースライン CPU モデルを各グループに 1 つずつ用意します。これにより、同じグループに分類される物理 CPU が使用される場合、ホスト物理マシン間でのゲスト仮想マシンの安全な移行が可能になります。libvirt では一般的にはポリシー自体の強制はせず、より高い層で適したポリシーを指定するというメカニズムを提供します。CPU のモデル情報を取得し、ゲスト仮想マシンに適した CPU モデルを定義する方法を理解することは、ホスト物理マシン間でゲスト仮想マシンを正常に移行する上で非常に重要となります。ハイパーバイザーは認識できる機能しかエミュレートできないため、そのハイパーバイザーのリリース後に作成された機能についてはエミュレートできません。

15.16.2. ホスト物理マシン CPU モデルに関する認識

virsh capabilities コマンドは、ハイパーバイザーの接続とホスト物理マシンの能力を記述する XML ドキュメントを表示します。表示される XML スキーマは、ホスト物理マシンの CPU モデルの情報を提供するように拡張されています。CPU モデルの記述において大きな挑戦となるものの1 つは、すべてのアーキテクチャーがそれぞれの機能の公開に対して異なるアプローチを取っていることです。x86 では、最新の CPU 機能は、CPUID インストラクションを介して公開されます。基本的に、これはそれぞれのビットが特殊な意味を持つ 32ビットの整数のセットに要約されます。AMD と Intel については、これらのビットに関する共通の意味で一致しています。その他のハイパーバイザーは、CPUID マスクの概念をそれらのゲスト仮想マシンの設定形式に直接公開します。しかし、QEMU/KVM は、単なる x86 アーキテクチャーよりも多くをサポートするため、CPUID は、規準となる設定形式としては適切でないことは明らかです。QEMU は、最終的に CPU モデルの名前文字列と名前付きのフラグのセットを組み合わせるスキームを使用することになりました。x86 では、CPU モデルはベースライン CPUID マスクにマップして、フラグはそのマスク内でビットをオンとオフに切り替えるために使用できます。libvirt では、これに追従することが決定されており、モデル名とフラグの組み合わせを使用します。
既知の CPU モデルすべてを一覧表示するデータベースを取得することは実際的ではありません。そのため、libvirt はベースライン CPU モデル名の小規模な一覧を維持します。この一覧は、実際のホスト物理マシン CPU と共に最大数の CPUID 部分を共有するものを選択して、残りの部分は名前付きの機能として一覧表示します。libvirt は、ベースライン CPU に含まれる機能は表示しないことに注意してください。これは、一見すると欠陥のように見えますが、このセクションで説明されるように、この情報について知る必要はありません。

15.16.3. ホスト物理マシンのプールに適合する互換性のある CPU モデルの決定

1 つのホスト物理マシンが持つ CPU 機能を認識することができるようになったら、次のステップは、そのゲスト仮想マシンに公開するにはどの CPU 機能が最適であるかを決定することです。ゲスト仮想マシンが別のホスト物理マシンに決して移行する必要がないことが判明している場合は、そのホスト物理マシンの CPU モデルは修正なしでストレートに通過できます。一部の仮想化データセンターには、すべてのサーバーが 100% 同一の CPU を保持していることを保証する設定セットが含まれる場合があります。そのような場合も、ホスト物理マシンの CPU モデルは修正なしでストレートに通過できます。しかし、さらに一般的なケースでは、ホスト物理マシン間に CPU のバリエーションが存在するものです。このような混合の CPU 環境では、妥協できる共通の CPU を決定する必要があります。これは単純な手順ではないため、libvirt はこのタスクに適格な API を提供します。libvirt が、それぞれホスト物理マシン用の CPU モデルを記述している XML 文書の一覧を受け取ると、libvirt は内部でこれらを CPUID マスクに変換し、それらの接点を算出して、CPUID マスクの結果を XML CPU 記述に変換し直します。
以下は、virsh capabilities が実行される際に、libvirt が基本ワークステーションの機能として報告する内容についての例です。

<capabilities>
  <host>
    <cpu>
      <arch>i686</arch>
      <model>pentium3</model>
      <topology sockets='1' cores='2' threads='1'/>
      <feature name='lahf_lm'/>
      <feature name='lm'/>
      <feature name='xtpr'/>
      <feature name='cx16'/>
      <feature name='ssse3'/>
      <feature name='tm2'/>
      <feature name='est'/>
      <feature name='vmx'/>
      <feature name='ds_cpl'/>
      <feature name='monitor'/>
      <feature name='pni'/>
      <feature name='pbe'/>
      <feature name='tm'/>
      <feature name='ht'/>
      <feature name='ss'/>
      <feature name='sse2'/>
      <feature name='acpi'/>
      <feature name='ds'/>
      <feature name='clflush'/>
      <feature name='apic'/>
    </cpu>
 </host>
</capabilities>

図15.3 ホスト物理マシンの CPU モデル情報のプル

ここで、同じ virsh capabilities コマンドを使い、これをランダムなサーバーと比較します。

<capabilities>
  <host>
    <cpu>
      <arch>x86_64</arch>
      <model>phenom</model>
      <topology sockets='2' cores='4' threads='1'/>
      <feature name='osvw'/>
      <feature name='3dnowprefetch'/>
      <feature name='misalignsse'/>
      <feature name='sse4a'/>
      <feature name='abm'/>
      <feature name='cr8legacy'/>
      <feature name='extapic'/>
      <feature name='cmp_legacy'/>
      <feature name='lahf_lm'/>
      <feature name='rdtscp'/>
      <feature name='pdpe1gb'/>
      <feature name='popcnt'/>
      <feature name='cx16'/>
      <feature name='ht'/>
      <feature name='vme'/>
    </cpu>
    ...snip...

図15.4 ランダムサーバーから CPU 記述を生成する

この CPU 記述に直前のワークステーションの CPU 記述との互換性があるかを判別するには、virsh cpu-compare コマンドを使用します。
この削減したコンテンツは、virsh-caps-workstation-cpu-only.xml という名前のファイル内に格納されて、このファイルに virsh cpu-compare コマンドを実行することができます。
# virsh cpu-compare virsh-caps-workstation-cpu-only.xml
Host physical machine CPU is a superset of CPU described in virsh-caps-workstation-cpu-only.xml
以上の出力で見えるように、サーバー CPU 内のいくつかの機能がクライアント CPU 内で欠如しているため、libvirt は、CPU が厳密には互換性を持たないことを正しく報告しています。クライアントとサーバー間で移行を可能にするには、XML ファイルを開いていくつかの機能をコメントアウトする必要があります。どの機能を削除するかを決定するには、両方のマシンの CPU 情報が含まれる both-cpus.xmlvirsh cpu-baseline コマンドを実行します。 # virsh cpu-baseline both-cpus.xml を実行すると、次のような結果になります。

<cpu match='exact'>
  <model>pentium3</model>
  <feature policy='require' name='lahf_lm'/>
  <feature policy='require' name='lm'/>
  <feature policy='require' name='cx16'/>
  <feature policy='require' name='monitor'/>
  <feature policy='require' name='pni'/>
  <feature policy='require' name='ht'/>
  <feature policy='require' name='sse2'/>
  <feature policy='require' name='clflush'/>
  <feature policy='require' name='apic'/>
</cpu>

図15.5 複合 CPU ベースライン

この複合ファイルは、共通の要素を示します。共通でない要素はすべてコメントアウトされます。

15.17. ゲスト仮想マシンの CPU モデルの設定

単純なデフォルトではゲスト仮想マシンの CPU 設定は、XML が表示するホスト物理マシンの機能と同じ基本的な XML 表現を受け入れます。つまり cpu-baseline virsh コマンドからの XML は、<domain> 要素の下で、トップレベルにあるゲスト仮想マシンの XML に直接コピーすることができます。以前の XML スニペットには、ゲスト仮想マシンの XML 内での CPU の記述の際に利用できるいくつかの追加の属性があります。これらはほとんど無視できますが、ここでそれらの属性の機能について簡単に説明します。トップレベルの <cpu> 要素には match という属性がありますが、以下の値を持つ可能性があります。
  • match='minimum' - ホスト物理マシン CPU には、少なくともゲスト仮想マシン XML 内に記述されている CPU 機能がなければなりません。ホスト物理マシンにゲスト仮想マシンの設定範囲を超える追加の機能がある場合は、それらはゲスト仮想マシンに対しても表示されます。
  • match='exact' - ホスト物理マシン CPU には、少なくともゲスト仮想マシン XML 内に記述されている CPU 機能がなければなりません。ホスト物理マシンにゲスト仮想マシンの設定範囲を超える追加の機能がある場合は、それらはゲスト仮想マシンには非表示となり隠されます。
  • match='strict' - ホスト物理マシン CPU には、ゲスト仮想マシン XML 内に記述してあるものと全く同じ CPU 機能がなければなりません。
次の強化では、 <feature> の各要素に「policy」属性を追加で持たせ、 以下のような値を設定することができます。
  • policy='force' - ホスト物理マシンが持たない機能の場合でもゲスト仮想マシンに対してその機能を表示します。これは通常、ソフトウェアエミュレーションの場合にのみ役立ちます。
  • policy='require' - ホスト物理マシンが持たない機能の場合でも、ゲスト仮想マシンに対してその機能を表示し、その後に失敗します。これは適切なデフォルトと言えます。
  • policy='optional' - サポートされる機能の場合、その機能をゲスト仮想マシンに表示します。
  • policy='disable' - ホスト物理マシンが持つ機能の場合、その機能はゲスト仮想マシンには非表示となり隠されます。
  • policy='forbid' - ホスト物理マシンが持つ機能の場合、失敗してゲスト仮想マシンの開始が拒否されます。
'forbid' ポリシーは、CPUID マスク内にない機能の場合でも、不正な動作をしているアプリケーションがその機能の使用を試みており、この機能を持つホスト物理マシン上でゲスト仮想マシンを間違って実行することを避けたい状況での特定のシナリオに対応します。'optional' ポリシーは、移行に関して特殊な動作をします。ゲスト仮想マシンが最初に開始される際にそのフラグは 'optional' ですが、ゲスト仮想マシンのライブマイグレーションの実行時には、このポリシーは 'require' に変わります。この理由は移行を通じて機能を消滅させることができないからです。

15.18. ゲスト仮想マシンのリソースの管理

virsh は、ゲスト仮想マシンごとにリソースのグループ化および割り当てを行うことを許可します。これは、libvirt daemon によって管理されます。libvirt daemoncgroups を作成し、ゲスト仮想マシンの代わりにそれらを管理します。システム管理者が行なわなければならない唯一のタスクは、指定された仮想マシンに対して tunable (調整可能パラメーター) を照会するか、または設定するかのいずれかになります。以下の調整可能パラメーターを使用できます。
  • memory - メモリーコントローラーは RAM と swap 使用量の制限を設定することを許可し、グループ内のすべてのプロセスの累積的な使用の照会を許可します。
  • cpuset - CPU セットコントローラーは、グループ内のプロセスを CPU セットにバインドし、CPU 間の移行を制御します。
  • cpuacct - CPU アカウンティングコントローラーは、プロセスのグループの CPU の使用量についての情報を提供します。
  • cpu - CPU スケジューラーコントローラーは、グループ内のプロセスの優先付けを制御します。これは nice レベルの特権を付与することに似ています。
  • devices - デバイスコントローラーは、キャラクターおよびブロックデバイス上のアクセス制御リストを付与します。
  • freezer - フリーザーコントローラーは、グループ内のプロセスの実行を一時停止し、再開します。これは、グループ全体に対する SIGSTOP と同様です。
  • net_cls - ネットワーククラスコントローラーは、プロセスを tc ネットワーククラスに関連付けることにより、ネットワークの利用を管理します。
グループ階層の作成時に、cgroup では、マウントポイントとディレクトリーのセットアップは管理者によって完全に決定され、これはいくつかのマウントポイントを /etc/fstab に追加するだけの場合よりも複雑になります。ディレクトリー階層をセットアップし、その中にプロセスを配置する方法を判別することが必要です。これは、以下の virsh コマンドを使用して実行できます。

15.19. スケジュールパラメーターの設定

schedinfo は、スケジューラーパラメーターをゲスト仮想マシンに渡すことを許可します。以下のコマンド形式を使用する必要があります。
#virsh schedinfo domain --set --weight --cap --current --config --live
それぞれのパラメーターを以下に説明します。
  • domain - これはゲスト仮想マシンのドメインです。
  • --set - ここに置かれる文字列は、呼び出されるコントローラーまたはアクションです。必要な場合は、追加のパラメーターまたは値も追加してください。
  • --current - --set と共に使用される場合、現在のスケジューラー情報として指定された set 文字列を使用します。--set なしに使用される場合、現在のスケジューラー情報が表示されます。
  • --config - - --set と共に使用される場合、次回の起動時に指定された set 文字列が使用されます。--set なしに使用される場合、設定ファイルに保存されるスケジューラー情報が表示されます。
  • --live - --set と共に使用される場合、現在実行中のゲスト仮想マシン上の指定された set 文字列が使用されます。--set なしに使用される場合、実行中の仮想マシンで現在使用されている設定が表示されます。
スケジューラーは、以下のパラメーターにいずれかで設定できます。cpu_sharesvcpu_period および vcpu_quota

例15.5 schedinfo show

以下の例は、シェルのゲスト仮想マシンのスケジュール情報を表示します。
# virsh schedinfo shell
Scheduler      : posix
cpu_shares     : 1024
vcpu_period    : 100000
vcpu_quota     : -1

例15.6 schedinfo set

この例では、cpu_shares は 2046 に変更されています。これは現在の状態に影響を与えますが、設定ファイルには影響がありません。
# virsh schedinfo --set cpu_shares=2046 shell
Scheduler      : posix
cpu_shares     : 2046
vcpu_period    : 100000
vcpu_quota     : -1

15.20. ディスク I/O スロットリング

virsh blkdeviotune は、指定されたゲスト仮想マシンのディスク I/O スロットリングを設定します。これにより、ゲスト仮想マシンが共有リソースを過剰に使用し、他のゲスト仮想マシンのパフォーマンスに影響が及ぶことが避けられます。以下の形式を使用する必要があります。
# virsh blkdeviotune <domain> <device> [[--config] [--live] | [--current]] [[total-bytes-sec] | [read-bytes-sec] [write-bytes-sec]] [[total-iops-sec] [read-iops-sec] [write-iops-sec]]
必要なパラメーターはゲスト仮想マシンのドメイン名のみです。ドメイン名を一覧表示するには、domblklist コマンドを実行します。--config--live、および --current オプションは、「スケジュールパラメーターの設定」の場合と同様に機能します。制限が設定されない場合、現在の I/O 制限の設定を照会します。それ以外の場合は、以下のフラグで制限を変更します。
  • --total-bytes-sec - 秒あたりのバイト単位の合計スループット制限を指定します。
  • --read-bytes-sec - 秒あたりのバイト単位の読み込みスループット制限を指定します。
  • --write-bytes-sec - 秒あたりのバイト単位の書き込みスループット制限を指定します。
  • --total-iops-sec - 秒あたりの合計 I/O 操作回数を指定します。
  • --read-iops-sec - 秒あたりの読み込み I/O 操作回数を指定します。
  • --write-iops-sec - 秒あたりの書き込み I/O 操作回数を指定します。
詳細については、virsh の man ページの blkdeviotune セクションを参照してください。ドメイン XML 例については、図21.23「デバイス - ハードドライブ、フロッピーディスク、CDROM」を参照してください。

15.21. ブロック I/O パラメーターの表示または設定

blkiotune は、指定されたゲスト仮想マシンの I/O パラメーターを設定するか、または表示します。以下の形式を使用する必要があります。
# virsh blkiotune domain [--weight weight] [--device-weights device-weights] [[--config] [--live] | [--current]]
このコマンドについての詳細は、『仮想化のチューニングと最適化ガイド』 を参照してください。

15.22. メモリーのチューニングを設定する

virsh memtune virtual_machine --parameter size は、『仮想化のチューニングと最適化ガイド』 で扱われています。

15.23. 仮想ネットワークコマンド

以下のコマンドは複数の仮想ネットワークを操作します。libvirt には、ドメインによって使用され、実際のネットワークデバイスにリンクされる仮想ネットワークを定義する機能があります。この機能についての詳細は、libvirt の web サイト にあるドキュメントを参照してください。仮想ネットワークについてのコマンドの多くは、ドメインに使用されるコマンドと似ていますが、仮想ネットワークに名前を付ける方法は、その名前または UUID のいずれかを使用する方法になります。

15.23.1. 仮想ネットワークの自動起動

このコマンドは、ゲスト仮想マシンの起動時に自動的に開始される仮想ネットワークを設定します。このコマンドを実行するには、以下を実行します。
# virsh net-autostart network [--disable]
このコマンドは、autostart コマンドを無効にする --disable オプションを受け入れます。

15.23.2. XML ファイルによる仮想ネットワークの作成

このコマンドは、XML ファイルから仮想ネットワークを作成します。libvirt によって使用される XML ネットワーク形式の説明については、libvirt の web サイト を参照してください。このコマンドで、file は XML ファイルのパスになります。XML ファイルから仮想ネットワークを作成するには、以下を実行します。
# virsh net-create file

15.23.3. XML ファイルによる仮想ネットワークの定義

このコマンドは、XML ファイルから仮想ネットワークを定義します。ネットワークが定義されますが、インスタンス化は行なわれません。仮想ネットワークを定義するには、以下を実行します。
# net-define file

15.23.4. 仮想ネットワークの停止

このコマンドは、所定の仮想ネットワークを、その名前または UUID 別に破棄します。これはすぐに有効になります。指定されたネットワークを停止するには、network が必要になります。
# net-destroy network

15.23.5. ダンプファイルの作成

このコマンドは、指定された仮想ネットワークの標準出力に対する XML ダンプとして、仮想ネットワーク情報を出力します。--inactive が指定されている場合、物理機能は、関連付けられた仮想機能に拡張されません。ダンプファイルを作成するには、以下を実行します。
# virsh net-dumpxml network [--inactive]

15.23.6. 仮想ネットワークの XML 設定ファイルの編集

以下のコマンドは、ネットワークの XML 設定ファイルを編集します。これは以下と同等になります。
#virsh net-dumpxml --inactive network > network.xml
vi network.xml (or make changes with your other text editor)
virsh net-define network.xml
一部エラーチェックを実行する点を除きます。使用されるエディターは $VISUAL または $EDITOR 環境変数を使用して指定でき、デフォルトは "vi" になります。ネットワークを編集するには、以下を実行します。
#virsh net-edit network

15.23.7. 仮想ネットワークについての情報の取得

このコマンドは、network オブジェクトについての基本情報を返します。ネットワーク情報を得るには、以下を実行します。
# virsh net-info network

15.23.8. 仮想ネットワークについての情報の一覧表示

アクティブなネットワークの一覧を返します。--all が指定されている場合、これには、定義済みであるもののアクティブではないネットワークも含まれます。--inactive が指定される場合、アクティブではないネットワークのみが一覧表示されます。さらに、返されたネットワークのフィルターは、永続的なネットワークを一覧表示するには --persistent を、一時的なネットワークを一覧表示するには --transient を、自動起動が有効なネットワークを一覧表示するには --autostart を使用し、さらに、自動起動が無効なネットワークを一覧表示するには --no-autostart を使用して実行できます。
注意: 古いサーバーと通信する際、このコマンドには、固有の競合のある一連の API を使用することが強制されます。ここで、プールはリストされないか、または一覧の収集中に呼び出し間の状態が変更される場合は複数回出現する可能性があります。サーバーがこの問題を持つことがないように確認してください。
仮想ネットワークを一覧表示するには、以下を実行します。
# net-list [--inactive | --all] [--persistent] [<--transient>] [--autostart] [<--no-autostart>]

15.23.9. ネットワーク UUID からネットワーク名への変換

このコマンドは、ネットワーク UUID をネットワーク名に変換します。これを実行するには、以下を実行します。
# virsh net-name network-UUID

15.23.10. 停止状態の(定義済み)ネットワークの起動

このコマンドは、(以前に定義された) 非アクティブなネットワークを開始します。これを実行するには、以下を実行します。
# virsh net-start network

15.23.11. 停止状態のネットワークの設定の定義解除

このコマンドは、非アクティブなネットワークの設定を定義解除します。これを実行するには、以下を実行します。
# net-undefine network

15.23.12. ネットワーク名からネットワーク UUID への変換

このコマンドは、ネットワーク名をネットワーク UUID に変換します。これを実行するには、以下を実行します。
# virsh net-uuid network-name

15.23.13. 既存のネットワーク定義ファイルの更新

このコマンドは、既存のネットワーク定義の所定のセクションを更新します。この更新にはネットワークの破棄および再起動を必要とせず、ただちに有効になります。このコマンドは、"add-first"、"add-last"、"add" (add-last と同意)、"delete"、または "modify" のいずれかになります。セクションは、""bridge"、"domain"、"ip"、"ip-dhcp-host"、"ip-dhcp-range"、"forward"、"forward-interface"、"forward-pf"、"portgroup"、"dns-host"、"dns-txt"、または "dns-srv" のいずれかとなり、それぞれのセクション名は変更される要素につながる xml 要素階層の連結によって付けられます。たとえば、"ip-dhcp-host" はネットワークの <ip> 要素内の <dhcp> 要素内に含まれる <host> 要素を変更します。xml は変更されるタイプの詳細な XML 要素のテキスト (例: "<host mac="00:11:22:33:44:55’ ip=’192.0.2.1’/>") または詳細な xml 要素を含むファイルの名前のいずれかになります。不明瞭な部分があれば、指定されるテキストの最初の文字を参照して解消されます。最初の文字が "<" の場合は xml テキストであり、最初の文字が ">" ではない場合、それは使用される xml テキストが含まれるファイルの名前になります。--parent-index オプションは、要求された要素が含まれるいくつかの親要素のいずれかを指定するために使用されます (0 ベース)。たとえば、dhcp <host> 要素は、ネットワーク内の複数の <ip> 要素のいずれかに含まれる可能性があります。parent-index が指定されない場合、「最も適した」<ip> 要素が選択されますが (通常は <dhcp> 要素を含む唯一の要素)、--parent-index が指定される場合、<ip> の特定の例が修正されます。--live が指定される場合、実行中のネットワークが影響を受けます。--config が指定される場合は、永続的なネットワークの次の起動が影響を受けます。-- current が指定される場合、現在のネットワークの状態が影響を受けます。--live--config フラグの両方を指定することができますが、--current は排他的です。フラグを指定しないことは、--current を指定することと同じになります。
設定ファイルを更新するには、以下を実行します。
# virsh net-update network command section xml [--parent-index index] [[--live] [--config] | [--current]]

第16章 仮想マシンマネージャー (virt-manager) を使ってゲストを管理する

このセクションでは、仮想マシンマネージャー (virt-manager) のウィンドウ、ダイアログボックス、GUI コントロールなどについて説明していきます。
virt-manager は、ホストシステムおよびリモートのホストシステム上のハイパーバイザー群やゲスト群をグラフィカルに表示させることができます。virt-manager では次のような仮想化管理に関する作業を行うことができます。
  • ゲストの定義と作成
  • メモリーの割り当て
  • 仮想 CPU の割り当て
  • 動作性能の監視
  • ゲストの保存、復元、一時停止と開始、シャットダウンと起動
  • テキストコンソールとグラフィカルコンソールへのリンク
  • ライブマイグレーションとオフラインマイグレーション

16.1. virt-manager を起動する

virt-manager セッションを開始するには、 アプリケーション メニューを開き システムツール メニュー、 仮想マシンマネージャー (virt-manager) の順で選択します。
virt-manager のメインウィンドウが開きます。
virt-manager を起動する

図16.1 virt-manager を起動する

または、以下のコマンドで示すように ssh を使ってリモートで virt-manager を起動することもできます。
ssh -X host's address
[remotehost]# virt-manager
ssh を使った仮想マシンとホストの管理については、「SSH によるリモート管理」で詳しく説明しています。

16.2. 仮想マシンマネージャーのメインウィンドウ

このメインウィンドウには、実行中のゲストとゲストに使用sれるリソースがすべて表示されます。ゲスト名をダブルクリックしてゲストの選択を行います。
仮想マシンマネージャーのメインウィンドウ

図16.2 仮想マシンマネージャーのメインウィンドウ

16.3. 仮想ハードウェアの詳細ウィンドウ

仮想ハードウェアの詳細ウィンドウには、ゲストに設定されている仮想ハードウェアに関する情報が表示されます。仮想ハードウェアのリソースの追加、削除、編集はこのウィンドウで行うことができます。ツールバー内にあるアイコンをクリックすると、仮想ハードウェアの詳細ウィンドウが表示されます。
仮想ハードウェアの詳細アイコン

図16.3 仮想ハードウェアの詳細アイコン

上記に示すアイコンをクリックすると、仮想ハードウェアの詳細ウィンドウが表示されます。
仮想ハードウェアの詳細ウィンドウ

図16.4 仮想ハードウェアの詳細ウィンドウ

16.3.1. USB デバイスをゲスト仮想マシンに割り当てる

注記

USB デバイスをゲスト仮想マシンに割り当てるためには、まずそれをホスト物理マシンにアタッチし、デバイスが機能することを確認する必要があります。ゲストが実行中の場合、シャットダウンしてからこれを実行する必要があります。

手順16.1 Virt-Manager を使用した USB デバイスの割り当て

  1. ゲスト仮想マシンの「仮想マシンの詳細」スクリーンを開きます。
  2. ハードウェアを追加 をクリックします。
    ハードウェアを追加ボタン

    図16.5 ハードウェアを追加ボタン

  3. 新規の仮想ハードウェアの追加 (Add new virtual hardware) ポップアップから USB ホストデバイス (USB Host Device) を選択し、一覧から割り当てるデバイスを選択して 完了 をクリックします。
    USB デバイスの追加

    図16.6 USB デバイスの追加

  4. ゲスト仮想マシンで USB デバイスを使用するには、まずゲスト仮想マシンを起動します。

16.4. 仮想マシンのグラフィカルコンソール

このウィンドウには、ゲストのグラフィカルコンソールが表示されます。グラフィカルなフレームバッファーのエクスポートには複数の異なるプロトコルを使用することができます。 virt-manager で対応しているのは VNCSPICE になります。認証を求めるよう仮想マシンを設定している場合は、ディスプレイが表示される前に仮想マシンのグラフィカルコンソールによってパスワードの入力が求められます。
グラフィカルのコンソールウィンドウ

図16.7 グラフィカルのコンソールウィンドウ

注記

多くのセキュリティ専門家の間では VNC は安全ではないと考えられていますが、Red Hat Enterprise Linux での仮想化に VNC を使用する際の安全性を確保する変更がいくつか加えられています。ゲストマシンがリッスンするのはローカルホストのループバックアドレスのみになります (127.0.0.1)。 これにより、VNC 経由による仮想マシンおよび virt-manager にアクセスできるのはホスト上でシェルの特権を有するゲストのみになります。 virt-manager が他のパブリックネットワークインターフェースをリッスンするよう設定し、別の方法を設定することもできますが推奨していません。
トラフィックを暗号化する SSH 経由でトンネル化をすることでリモートからの管理が可能になります。SSH でのトンネル化を行なわずに VNC へのリモートアクセスを設定することはできますが、安全上の理由から推奨していません。遠隔からゲストの管理を行なう場合は、6章ゲストのリモート管理 の説明にしたがってください。TLS を使用すると、ゲストとホストのシステム管理にエンタープライズレベルの安全性を得ることができます。
ローカルデスクトップでは、キーの組み合わせがゲストマシンに送信されないようにすることができます (Ctrl+Alt+F1 など)。キーを送信 のメニューオプションを使用するとキーの組み合わせを送信することができます。ゲストマシンのウィンドウから、キーを送信 メニューをクリックして、送信するキーの組み合わせを選択します。また、このメニューではスクリーンの出力をキャプチャすることもできます。
Red Hat Enterprise Linux では VNC の代替として SPICE が使用できます。

16.5. リモート接続を追加する

virt-manager を使ってリモートシステムへの接続を設定する方法を説明します。
  1. 新しい接続を作成するには、ファイル メニューを開き、接続を追加... メニューアイテムを選択します。
  2. 接続を追加 のウィザードが表示されます。ハイパーバイザーを選択します。Red Hat Enterprise Linux 6 システムの場合は QEMU/KVM を選択します。ローカルシステムの場合はローカルを選択するか、いずれかのリモート接続オプションを選択して 接続 をクリックします。 この例では、SSH 経由のリモートトンネルを使用しています。 デフォルトのインストールで正常に動作する設定です。リモート接続の設定方法については、 6章ゲストのリモート管理 を参照してください。
    接続の追加

    図16.8 接続の追加

  3. 選択したホストの root パスワード入力が求めらるので入力を行います。
これでリモートホストが接続され、 virt-manager のメインウィンドウに表示されるようになりました。
virt-manager のメインウィンドウに表示されたリモートホスト

図16.9 virt-manager のメインウィンドウに表示されたリモートホスト

16.6. ゲストの詳細を表示する

仮想マシンモニターを使用すると、システム上の仮想マシンの動作情報を表示させることができます。
仮想システムの詳細を表示するには、以下を実行します。
  1. 仮想マシンマネージャーのメインウィンドウで表示させたい仮想マシンを強調表示します。
    表示する仮想マシンを選択する

    図16.10 表示する仮想マシンを選択する

  2. 仮想マシンマネージャーの 編集 メニューから 仮想マシンの詳細 を選択します。
    仮想マシンの詳細を表示する

    図16.11 仮想マシンの詳細を表示する

    仮想マシンの詳細ウィンドウを開くとコンソールが表示される場合があります。コンソールが表示される場合には、表示 をクリックしてから 詳細 を選択します。 デフォルトでは概要を示すウィンドウが開きます。このウィンドウに戻るには、左側のナビゲーションペインで 概要 (Overview) を選択します。
    概要 (Overview) のビューには、 そのゲストの構成情報の要約が表示されます。
    ゲスト詳細の概要を表示

    図16.12 ゲスト詳細の概要を表示

  3. 左側のナビゲーションペインから パフォーマンス (Performance) を選択します。
    パフォーマンス (Performance) のビューでは、CPU やメモリー使用率などゲストのパフォーマンスに関する要約が表示されます。
    ゲストのパフォーマンスの詳細を表示する

    図16.13 ゲストのパフォーマンスの詳細を表示する

  4. 左側のナビゲーションペインから プロセッサー (Processor) を選択します。プロセッサー (Processor) のビューでは、現在のプロセッサーの割り当てを表示させたり、変更を行ったりすることができます。
    プロセッサーの割り当てパネル

    図16.14 プロセッサーの割り当てパネル

  5. 左側のナビゲーションペインから メモリー (Memory) を選択します。 メモリー (Memory) のビューでは、 現在のメモリーの割り当てを表示させたり、変更を行ったりすることができます。
    メモリーの割り当てを表示する

    図16.15 メモリーの割り当てを表示する

  6. ナビゲーションペインには、その仮想マシンに接続されている各仮想ディスクが表示されます。仮想ディスクの修正や削除を行う場合はその仮想ディスクをクリックします。
    ディスクの構成を表示する

    図16.16 ディスクの構成を表示する

  7. ナビゲーションペインには、その仮想マシンに接続されている各仮想ネットワークインターフェースが表示されます。仮想ネットワークインターフェースの修正や削除を行う場合はその仮想ネットワークインターフェースをクリックします。
    ネットワークの構成を表示する

    図16.17 ネットワークの構成を表示する

16.7. パフォーマンスの監視

パフォーマンスの監視設定は、 virt-manager の設定ウィンドウで修正することができます。
パフォーマンスの監視を設定する
  1. 編集 メニューから 設定 を選択します。
    ゲストの設定を修正する

    図16.18 ゲストの設定を修正する

    設定 ウィンドウが表示されます。
  2. 統計 のタブで、更新の間隔を秒単位で指定するか、または統計監視オプションを有効にします。
    パフォーマンスの監視を設定する

    図16.19 パフォーマンスの監視を設定する

16.8. ゲストの CPU 使用率を表示する

システム上の全ゲストの CPU 使用率を表示するには、以下を実行します。
  1. 表示 メニューから グラフ を選択し、ゲストの CPU 使用率 (Guest CPU Usage) のチェックボックスに印を付けます。
    ゲストの CPU 使用率の統計値グラフ化を有効にする

    図16.20 ゲストの CPU 使用率の統計値グラフ化を有効にする

  2. 仮想マシンマネージャーがシステム上の全仮想マシンの CPU 使用率のグラフを表示するようになります。
    ゲストの CPU 使用率のグラフ

    図16.21 ゲストの CPU 使用率のグラフ

16.9. ホストの CPU 使用率を表示する

システム上の全ホストの CPU 使用率を表示するには、以下を実行します。
  1. 表示 メニューから グラフ を選択し、ホストの CPU 使用率 (host CPU Usage) のチェックボックスに印を付けます。
    ホストの CPU 使用率の統計値グラフ化を有効にする

    図16.22 ホストの CPU 使用率の統計値グラフ化を有効にする

  2. 仮想マシンマネージャーがシステム上のホストの CPU 使用率のグラフを表示するようになります。
    ホストの CPU 使用率のグラフ

    図16.23 ホストの CPU 使用率のグラフ

16.10. ディスク I/O を表示する

システム上の全仮想マシンのディスク I/O を表示するには、以下を実行します。
  1. ディスク I/O の統計値収集の設定が有効になっているか確認します。編集 メニューから 設定 を選択します。統計 タブをクリックします。
  2. ディスク I/O のチェックボックスに印を付けます。
    ディスク I/O を有効にする

    図16.24 ディスク I/O を有効にする

  3. ディスク I/O の表示を有効にするには、 表示 メニューから グラフディスク I/O のチェックボックスの順で選択して印を付けます。
    ディスク I/O を選択する

    図16.25 ディスク I/O を選択する

  4. 仮想マシンマネージャーがシステム上の全仮想マシンのディスク I/O のグラフを表示するようになります。
    ディスク I/O を表示する

    図16.26 ディスク I/O を表示する

16.11. ネットワーク I/O を表示する

システム上の全仮想マシンのネットワーク I/O を表示するには、以下を実行します。
  1. ネットワーク I/O の統計値収集の設定が有効になっているか確認します。編集 メニューから 設定 を選択します。統計 タブをクリックします。
  2. ネットワーク I/O のチェックボックスに印を付けます。
    ネットワーク I/O を有効にする

    図16.27 ネットワーク I/O を有効にする

  3. ネットワーク I/O の統計値を表示するには、表示 メニューから グラフネットワーク I/O のチェックボックスの順で選択して印を付けます。
    ネットワーク I/O を選択する

    図16.28 ネットワーク I/O を選択する

  4. 仮想マシンマネージャーがシステム上の全仮想マシンのネットワーク I/O のグラフを表示するようになります。
    ネットワーク I/O を表示する

    図16.29 ネットワーク I/O を表示する

第17章 オフラインツールでゲスト仮想マシンのディスクにアクセスする

17.1. はじめに

Red Hat Enterprise Linux 6 には、ホスト物理マシンのディスクや他のディスクイメージへのアクセス、編集、作成などを行うことができるツールが複数同梱されています。こうしたツールでは次のような使い方ができます。
  • ホスト物理マシンのディスクにあるファイルを表示したり、これにファイルをダウンロードしたりします。
  • ホスト物理マシンのディスクでファイルを編集したり、アップロードしたりします。
  • ホスト物理マシンの設定を読み込んだり、書き込みを行ったりします。
  • Windows ホスト物理マシンの Windows Registry を読み込んだり、書き込みを行ったりします。
  • ファイル、ディレクトリー、ファイルシステム、パーティション、論理ボリュームその他を含んでいる新規のディスクイメージの準備を行います。
  • 起動に失敗したホスト物理マシン、起動設定に変更を必要とするホスト物理マシンなどのレスキューと修復を行います。
  • ホスト物理マシンのディスク使用量を監視します。
  • その企業のセキュリティー標準に準拠しているかどうかなど、ホスト物理マシンのコンプライアンスを監査します。
  • テンプレートからクローンを作成し、テンプレートの修正を行うことにより、複数のホスト物理マシンの導入を行います。
  • CD、DVD ISO、およびフロッピーディスクのイメージの読み込みを行います。

警告

実行中の仮想マシンに接続しているホスト物理マシンまたはディスクイメージに書き込みを行う場合は、これらのツールを 絶対に使用しないでください。また、こうしたディスクイメージは書き込みモードでは開かないようにしてください。これは、ゲスト仮想マシンのディスクが破損する原因となります。ツールはこれが実行されないようにしますが、万全ではありません。ゲスト仮想マシンが実行中の可能性が少しでもある場合にはツールを使用しないか、または最低でもツールの使用は 常に読み取り専用モード で行うことを強くお勧めします。

17.2. 用語について

ここでは本章で使用されている用語について説明します。
  • libguestfs (GUEST FileSystem LIBrary) は基礎となる C ライブラリーです。ディスクイメージを開く、ファイルの読み込みや書き込みを行う場合などに基本的な機能を提供します。この API に対して C プログラムを直接記述することができますが、かなり低いレベルになります。
  • guestfish (GUEST Filesystem Interactive SHell) はインテラクティブなシェルです。コマンドラインまたはシェルスクリプトで使用することができます。libguestfs API のすべての機能を公開します。
  • libguestfs の上に各種の virt ツールがビルドされています。コマンドラインから単一の作業を行うことができるツールになります。ツールには virt-dfvirt-rescuevirt-resizevirt-edit などがあります。
  • hivexAugeas は、それぞれ Windows Registry と Linux 設定ファイルを編集するためのライブラリーになります。これらは libguestfs とは別のライブラリーですが、libguestfs の値の多くはこれらのツールの組み合わせで構成されます。
  • guestmount は、libguestfs と FUSE をつなぐインターフェースになります。主にホスト物理マシン上のディスクイメージからファイルシステムをマウントするために使用されます。この機能は必須ではありませんが、便利な機能になります。

17.3. インストール

libguestfs、guestfish、libguestfs ツール、guestmount、および Windows ゲスト仮想マシン向けサポートをインストールするには、RHEL V2WIN チャンネルをサブスクライブします。Red Hat Web サイトに行き、次のコマンドを実行します。
# yum install libguestfs guestfish libguestfs-tools libguestfs-mount libguestfs-winsupport
言語バインディングなどの libguestfs 関連のパッケージをすべてインストールする場合は、次のコマンドを実行します。
# yum install '*guestf*'

17.4. guestfish のシェル

guestfish はインテラクティブなシェルで、コマンドラインまたはシェルスクリプトからゲスト仮想マシンのファイルシステムにアクセスするために使用することができます。libguestfs API の機能はすべてシェルで利用することができます。
仮想マシンのディスクイメージを表示または編集する場合は、まず次のコマンドを実行します。以下のパスは必要なディスクイメージのパスに置き換えてください。
guestfish --ro -a /path/to/disk/image
--ro は、ディスクイメージを読み取り専用で開くという意味です。このモードは書き込みのアクセスを許可しないため、常に安全なモードになります。ゲスト仮想マシンが実行中ではないことが 確実にわかっている 場合か、またはライブゲスト仮想マシンにディスクイメージが接続されていない場合以外は、このオプションは省略しないでください。ライブゲスト仮想マシンの編集には libguest virtual machinefs は使用できません。無理に編集を行おうとするとディスクが確実に破損し、元に戻せなくなります。
/path/to/disk/image は、そのディスクへのパスになります。ファイル、ホスト物理マシンの論理ボリューム (/dev/VG/LV など)、ホスト物理マシンのデバイス (/dev/cdrom)、または SAN LUN (/dev/sdf3) のいずれかになります。

注記

libguestfs と guestfish には root の権限は必要ありません。アクセスしているディスクイメージの読み込みや書き込みに root を必要とする場合にのみ root での実行が必要になります。
guestfish をインタラクティブに起動すると、次のようなプロンプトが表示されます。
 guestfish --ro -a /path/to/disk/image

Welcome to guestfish, the libguestfs filesystem interactive shell for editing virtual machine filesystems.
 
 Type: 'help' for help on commands
       'man' to read the manual
       'quit' to quit the shell
 
><fs>
プロンプトに応じて run と入力してライブラリーを開始し、ディスクイメージを接続します。これを初めて行う場合には 30 秒ほど時間がかかる場合がありますが、それ以降からの起動は大幅に速くなります。

注記

libguestfs は KVM (使用可能な場合) などハードウェアの仮想化加速機能を使ってこのプロセスを高速化します。
run コマンドを入力すると、次のセクションで説明されているような他のコマンドを使用できるようになります。

17.4.1. guestfish でファイルシステムを表示する

17.4.1.1. 手作業で一覧表示する

list-filesystems コマンドを使って libguestfs によって検出されるファイルシステムを一覧表示します。以下の出力では Red Hat Enterprise Linux 4 のディスクイメージを表示しています。
><fs> run
><fs> list-filesystems
/dev/vda1: ext3
/dev/VolGroup00/LogVol00: ext3
/dev/VolGroup00/LogVol01: swap
以下の出力では Windows のディスクイメージを表示しています。
><fs> run
><fs> list-filesystems
/dev/vda1: ntfs
/dev/vda2: ntfs
他にも便利なコマンドとして list-deviceslist-partitionslvspvsvfs-type、および file などがあります。以下の出力のように help コマンド を入力すると、各コマンドの詳細と help を得ることができます。
><fs> help vfs-type
 NAME
    vfs-type - get the Linux VFS type corresponding to a mounted device
 
 SYNOPSIS
     vfs-type device
 
 DESCRIPTION
    This command gets the filesystem type corresponding to the filesystem on
    "device".
 
    For most filesystems, the result is the name of the Linux VFS module
    which would be used to mount this filesystem if you mounted it without
    specifying the filesystem type. For example a string such as "ext3" or
    "ntfs".
ファイルシステムの実際の内容を表示する場合はまずマウントする必要があります。この例では、前述の出力にある Windows パーティションの 1 つを使用しています (/dev/vda2)。このパーティションは C:\ ドライブに対応するものとして認識されています。
><fs> mount-ro /dev/vda2 /
><fs> ll /
total 1834753
 drwxrwxrwx  1 root root       4096 Nov  1 11:40 .
 drwxr-xr-x 21 root root       4096 Nov 16 21:45 ..
 lrwxrwxrwx  2 root root         60 Jul 14  2009 Documents and Settings
 drwxrwxrwx  1 root root       4096 Nov 15 18:00 Program Files
 drwxrwxrwx  1 root root       4096 Sep 19 10:34 Users
 drwxrwxrwx  1 root root      16384 Sep 19 10:34 Windows
ファイルやディレクトリーを表示してダウンロードする場合は、lsllcatmoredownloadtar-out などの guestfish コマンドを使用することができます。

注記

このシェルには現在の作業ディレクトリーという概念がありません。普通のシェルとは異なり、たとえば cd などのコマンドを使ったディレクトリー間の移動ができません。パスはすべてスラッシュ (/) を先頭に付けた完全修飾パスにしなければなりません。Tab キーを使用してパスを補完することができます。
guestfish シェルを終了するには、exit と入力するか、または Ctrl+d を押します。

17.4.1.2. guestfish による検出の使用

手作業でファイルシステムを表示させ、マウントする代わりに、guestfish 自体にイメージを検出させて、そのファイルシステムをゲスト仮想マシンでのマウントと同様にマウントさせます。これを実行するには、コマンドラインに -i オプションを追加します。
guestfish --ro -a /path/to/disk/image -i

Welcome to guestfish, the libguestfs filesystem interactive shell for
 editing virtual machine filesystems.
 
 Type: 'help' for help on commands
       'man' to read the manual
       'quit' to quit the shell
 
 Operating system: Red Hat Enterprise Linux AS release 4 (Nahant Update 8)
 /dev/VolGroup00/LogVol00 mounted on /
 /dev/vda1 mounted on /boot
 
 ><fs> ll /
 total 210
 drwxr-xr-x. 24 root root  4096 Oct 28 09:09 .
 drwxr-xr-x  21 root root  4096 Nov 17 15:10 ..
 drwxr-xr-x.  2 root root  4096 Oct 27 22:37 bin
 drwxr-xr-x.  4 root root  1024 Oct 27 21:52 boot
 drwxr-xr-x.  4 root root  4096 Oct 27 21:21 dev
 drwxr-xr-x. 86 root root 12288 Oct 28 09:09 etc
 [etc]
guestfish に検出とマウントを行わせるには libguestfs バックエンドを起動させる必要があるため、-i オプションを使用する場合は run コマンドは必要ありません。-i オプションは一般的な Linux や Windows のゲスト仮想マシンの多くで正常に動作します。

17.4.1.3. ゲスト仮想マシンの名前でゲスト仮想マシンにアクセスする

libvirt が認識できる名前を指定すると、コマンドラインからゲスト仮想マシンにアクセスすることができます (つまり、virsh list --all で表示される名前)。ゲスト仮想マシンの名前でそのゲスト仮想マシンにアクセスするには -d オプションを使用します。-i オプションは付けても付けなくても構いません。
guestfish --ro -d GuestName -i

17.4.2. guestfish を使ってファイルを編集する

ファイルの変更、ディレクトリーの作成、またはゲスト仮想マシンへの他の変更を加えるなどの場合には、このセクションの先頭にある「ゲスト仮想マシンをシャットダウンしてください (your guest virtual machine must be shut down)」という警告にまず注意してください。guestfish で実行中のディスクに編集や変更を加えたりすると、ディスクの破損を招きます。本セクションでは、/boot/grub/grub.conf ファイルの編集例を示します。ゲスト仮想マシンを確実にシャットダウンしたら、以下のようなコマンドを使って --ro フラグを省略し、書き込み権限を取得します。
guestfish -d RHEL3 -i

Welcome to guestfish, the libguestfs filesystem interactive shell for
 editing virtual machine filesystems.
 
 Type: 'help' for help on commands
       'man' to read the manual
       'quit' to quit the shell
 
 Operating system: Red Hat Enterprise Linux AS release 3 (Taroon Update 9)
 /dev/vda2 mounted on /
 /dev/vda1 mounted on /boot
 
><fs> edit /boot/grub/grub.conf
ファイルを編集するコマンドには editvi、および emacs などがあります。ファイルやディレクトリーを作成するコマンドには writemkdirupload、および tar-in など多数あります。

17.4.3. guestfish を使ったその他の動作

ファイルシステムのフォーマット化、パーティションの作成、LVM 論理ボリュームの作成およびサイズ変更などその他多くの動作が mkfspart-addlvresizelvcreatevgcreatepvcreate などのコマンドを使って行うことができます。

17.4.4. guestfish を使ってシェルスクリプトを作成する

インタラクティブな guestfish の使い方に慣れたら、必要に応じてシェルスクリプトを作成すると便利です。以下に新しい MOTD (その日のメッセージ) をゲストに追加する簡単なシェルスクリプトを示します。
#!/bin/bash -
 set -e
 guestname="$1"
 
 guestfish -d "$guestname" -i <<'EOF'
   write /etc/motd "Welcome to Acme Incorporated."
   chmod 0644 /etc/motd
 EOF

17.4.5. Augeas と libguestfs を使ってスクリプトを作成する

libguestfs と Augeas を組み合わせると、Linux ゲスト仮想マシンの設定を操作するスクリプトを作成する場合に便利です。たとえば、以下のスクリプトでは Augeas を使ってゲスト仮想マシンのキーボード設定を解析し、レイアウトを出力します。以下の例は Red Hat Enterprise Linux で実行するゲスト仮想マシンでのみ機能することに注意してください。
#!/bin/bash -
 set -e
 guestname="$1"
 
 guestfish -d "$1" -i --ro <<'EOF'
   aug-init / 0
   aug-get /files/etc/sysconfig/keyboard/LAYOUT
 EOF
Augeas は設定ファイルの修正に使用することもできます。キーボードのレイアウトを 変更 できるよう上記のスクリプトを修正することができます。
#!/bin/bash -
 set -e
 guestname="$1"
 
 guestfish -d "$1" -i <<'EOF'
   aug-init / 0
   aug-set /files/etc/sysconfig/keyboard/LAYOUT '"gb"'
   aug-save
 EOF
この 2 つのスクリプトでは異なる点が 3 カ所あります。
  1. 2 番目のスクリプトには --ro オプションがありません。ゲスト仮想マシンに書き込み権限を与えるためです。
  2. aug-get コマンドが aug-set コマンドに変わっています。値を新たに読み取りに行くのではなく、それを修正するためです。新しい値は "gb" になります (引用符を含む)。
  3. Augeas によって変更をディスクに書き込むよう aug-save コマンドが使用されています。

注記

Augeas の詳細については、Web サイト http://augeas.net をご覧ください。
guestfish では本ガイドでは取り上げきれないほどの多くのことができます。たとえば、ディスクイメージをゼロから作成することができます。
guestfish -N fs
または、ディスクイメージからディレクトリー全体をコピーします。
><fs> copy-out /home /tmp/home
詳細については guestfish(1) の man ページをご覧ください。

17.5. その他のコマンド

このセクションでは、ゲスト仮想マシンのディスクイメージの表示や編集を行う際に guestfish を使うよりシンプルなツールについて説明します。
  • virt-cat は guestfish の download コマンドと同じです。単一ファイルをダウンロードしてゲスト仮想マシンに表示します。たとえば、以下のようになります。
    # virt-cat RHEL3 /etc/ntp.conf | grep ^server
     server	    127.127.1.0	      # local clock
  • virt-edit は guestfish の edit コマンドに似ています。ゲスト仮想マシン内の単一ファイルをインタラクティブに編集するために使用できます。たとえば、起動しない Linux ベースのゲスト仮想マシンの grub.conf ファイルを編集しなければならないとします。
    # virt-edit LinuxGuest /boot/grub/grub.conf
    virt-edit には、 単一ファイルに一方的に直接の変更を加えることができる別モードもあります。この非インタラクティブなモードで編集を行う場合は -e オプションを使用します。たとえば、このコマンドでは Linux ゲスト仮想マシンの root パスワードをパスワードなしに変更します。
    # virt-edit LinuxGuest /etc/passwd -e 's/^root:.*?:/root::/'
  • virt-ls は guestfish の lsllfind の各コマンドと同様です。単一のディレクトリーまたは複数のディレクトリーを (再帰的に) 一覧表示するために使用されます。たとえば、以下のコマンドでは Linux ゲスト仮想マシンの /home の下にあるファイルとディレクトリーを再帰的に一覧表示します。
    # virt-ls -R LinuxGuest /home/ | less

17.6. virt-rescue: レスキューシェル

17.6.1. はじめに

このセクションでは、仮想マシンのレスキュー CD のようなものと捉えることができる virt-rescue について説明します。レスキューシェルでゲスト仮想マシンを起動するため、エラー修正などのメンテナンスを行ってゲスト仮想マシンを修復することができます。
virt-rescue と guestfish には機能的に重複している部分があります。両者の使い方の違いを区別しておくことは大切です。virt-rescue は、普通の Linux ファイルシステムツールを使ってインタラクティブに特別な変更を行う場合に使用します。特に問題が発生したゲスト仮想マシンを修復する場合などに適しています。virt-rescue をスクリプト化することはできません。
対照的に、guestfish は型通りのコマンド一式 (libguestfs API) を使って、スクリプト化によって構造化した変更を行う場合に便利です。また、guestfish はインタラクティブに使用することもできます。

17.6.2. virt-rescue を実行する

ゲスト仮想マシンで virt-rescue を使用する前に、そのゲスト仮想マシンが実行されていないことを確認してください。ゲスト仮想マシンが実行しているとディスクを破損させることになります。ゲスト仮想マシンがライブでないことを確認してから、以下を入力します。
virt-rescue GuestName
(上記の GuestName には libvirt が認識できるゲスト名を入力します) または、
virt-rescue /path/to/disk/image
(上記のパスは任意のファイル、論理ボリューム、LUN などいずれでも構いません) ゲスト仮想マシンのディスクが含まれます。
virt-rescue によってレスキュー仮想マシンが起動するため、その出力スクロールが表示されます。最終的には、以下が表示されます。
Welcome to virt-rescue, the libguestfs rescue shell.
 
 Note: The contents of / are the rescue appliance.
 You have to mount the guest virtual machine's partitions under /sysroot
 before you can examine them.
 
 bash: cannot set terminal process group (-1): Inappropriate ioctl for device
 bash: no job control in this shell
 ><rescue>
シェルプロンプトはここでは普通のバッシュシェルになるため、使用できる Red Hat Enterprise Linux コマンド数が少なくなります。たとえば、以下を入力できます。
><rescue> fdisk -l /dev/vda
上記のコマンドによってディスクパーティションが一覧表示されます。ファイルシステムをマウントする場合は、/sysroot の下にマウントすることをお勧めします。この空ディレクトリーは、レスキューマシン内にあるユーザーによって何がマウントされても構わないディレクトリーになります。/ の下にあるファイル群はレスキュー仮想マシン自体のファイルになるため注意してください。
><rescue> mount /dev/vda1 /sysroot/
EXT4-fs (vda1): mounted filesystem with ordered data mode. Opts: (null)
><rescue> ls -l /sysroot/grub/
 total 324
 -rw-r--r--. 1 root root     63 Sep 16 18:14 device.map
 -rw-r--r--. 1 root root  13200 Sep 16 18:14 e2fs_stage1_5
 -rw-r--r--. 1 root root  12512 Sep 16 18:14 fat_stage1_5
 -rw-r--r--. 1 root root  11744 Sep 16 18:14 ffs_stage1_5
 -rw-------. 1 root root   1503 Oct 15 11:19 grub.conf
 [...]
ゲスト仮想マシンの修復が完了したら、exit を入力するか、または Ctrl+d でシェルを終了します。
virt-rescue にはコマンドラインのオプションが多数あります。最もよく使用されるオプションを示します。
  • --ro: ゲスト仮想マシン上で読み取り専用モードで動作します。変更は保存されません。ゲスト仮想マシンを実験的に使用してみる場合にこのモードを使用します。シェルを終了すると、変更はすべて破棄されます。
  • --network: レスキューシェルからのネットワークアクセスを可能にします。RPM や他のファイルをゲスト仮想マシンにダウンロードする場合など必要に応じて使用します。

17.7. virt-df: ディスクの使用量を監視する

17.7.1. はじめに

ここでは、ディスクイメージやゲスト仮想マシンのファイルシステム使用量を表示する virt-df について説明します。Linux df コマンドに似ていますが、これは仮想マシン用になります。

17.7.2. virt-df を実行する

ディスクイメージ内にあるすべてのファイルシステムの使用量を表示する場合は、以下を入力します。
# virt-df /dev/vg_guests/RHEL6
 Filesystem                   1K-blocks       Used  Available  Use%
 RHEL6:/dev/sda1                 101086      10233      85634   11%
 RHEL6:/dev/VolGroup00/LogVol00 7127864    2272744    4493036   32%
(/dev/vg_guests/RHEL6 は Red Hat Enterprise Linux 6 ゲスト仮想マシンのディスクイメージになります。上記の例では、パスはこのディスクイメージがあるホスト物理マシンの論理ボリュームになります。)
virt-df を単体で使用して全ゲスト仮想マシンの情報を一覧表示させることもできます (つまり l