Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

仮想化ホスト設定およびゲストインストールガイド

Red Hat Enterprise Linux 6

仮想環境のインストールと設定

Tahlia Richardson

Red Hat Engineering Content Services

Dayle Parker

Red Hat Engineering Content Services

Laura Bailey

Red Hat Engineering Content Services

Scott Radvan

Red Hat Engineering Content Services

概要

本ガイドは、KVM パッケージ、互換性、および制限について説明します。また、ホスト設定の詳細や異なる種類のゲスト仮想マシンのインストール手順、PCI デバイス設定および SR-IOV についても説明します。

第1章 はじめに

1.1. このガイドについて

このガイドは、Red Hat Enterprise Linux 仮想化ホスト上における仮想化ソフトウェアのインストールおよびゲストマシンの設定に関する情報を提供します。
このガイドの初めの部分では、Red Hat Enterprise Linux ホストマシンによる仮想化のデプロイを可能とするための前提条件を説明します。システム要件や互換ハードウェア、サポート、製品の制限が詳細に説明されています。 
必須およびオプション仮想化パッケージを含む基本的なホスト設定は、5章仮想化パッケージのインストール で説明されています。
ゲスト仮想マシンのインストールは、6章ゲスト仮想マシンのインストール概要 以降で詳しく説明されており、完全仮想化の Red Hat Enterprise Linux ゲストおよび virt-manager と virsh を使用した Windows 準仮想化ゲストのインストール手順が示されています。
ネットワーキングや PCI デバイス設定、SR-IOV、KVM ゲストのタイミング管理、libvirt および SR-IOV のトラブルシューティングのヘルプに関する詳細情報は、このガイドの後半にあります。

注記

本書では、仮想化ホスト設定およびゲストインストールについての手引きを提供しています。システム設定のより詳細な情報については、『Red Hat Enterprise Linux 仮想化管理ガイド』 を参照してください。

1.2. ドキュメントスイート

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 ガイド』 には、KVM、Xen、および VMware ESX/ESX(i) ハイパーバイザーから Red Hat Enterprise Virtualization および libvirt で管理されている KVM への仮想マシンのインポートについて記載しています。

注記

これらのガイドはすべて、Red Hat カスタマーポータル (https://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/) からご利用いただけます。

第2章 システム要件

この章では、Red Hat Enterprise Linux 6 上の VM と呼ばれる仮想マシンを正常に実行するためのシステム要件を示しています。仮想化は、Intel 64 および AMD64 アーキテクチャー上の Red Hat Enterprise Linux 6 で利用可能です。
KVM ハイパーバイザーは、Red Hat Enterprise Linux 6 で提供されています。
仮想化パッケージのインストールに関する詳細は、5章仮想化パッケージのインストール を参照してください。

最小システム要件

  • 6 GB の空きディスク領域
  • 2 GB の RAM

推奨されるシステム要件

  • ゲスト仮想マシン内の最大数の仮想化 CPU に 1 つのプロセッサーコアまたはハイパースレッド、およびホストに 1 つのプロセッサーコアまたはハイパースレッド
  • 2 GB の RAM と仮想マシン用に別の RAM
  • ホスト用に 6 GB のディスク領域、および各仮想マシン用に必要なディスク領域
    ほとんどのゲストオペレーティングシステムは少なくとも 6GB のディスク領域を必要としますが、各ゲストに必要な追加のストレージ領域はイメージフォーマットによって異なります。
    raw イメージを使用するゲスト仮想マシンでは、ゲストが必要とする領域の合計 (total for raw format) は、ゲストの raw イメージファイル (images) で必要となる領域、ホストオペレーティングシステム (host) に必要な 6GB の領域、ゲストが必要とする swap 領域 (swap) の合計と同等もしくはそれ以上となります。

    式2.1 raw イメージを使用するゲスト仮想マシンで必要な領域の計算

    total for raw format = images + host + swap
    qcow イメージの場合、qcow および qcow2 イメージは必要に応じて拡大することから、ゲストの予測される最大ストレージ要件 (total for qcow format) も計算する必要があります。この拡大を可能にするには、まずゲストの予測される最大ストレージ要件 (expected maximum guest storage) を 1.01 倍にし、これにホスト (host) が必要とする領域と必要な swap 領域 (swap) を加えます。

    式2.2 qcow イメージを使用するゲスト仮想マシンで必要な領域の計算

    total for qcow format = (expected maximum guest storage * 1.01) + host + swap
ゲスト仮想マシン要件は、『Red Hat Enterprise Linux 6 仮想化管理ガイド』の第 6 章 「KVM でオーバーコミットを行う」で詳しく説明されています。
swap 領域の計算

swap 領域を使用することで、利用可能な物理メモリー以外の新たなメモリーを提供することが可能になります。メモリーのパフォーマンス速度を上げるために使用率の低いメモリーをハードドライブにスワップする際に使用するのが swap パーティションです。swap パーティションのデフォルトのサイズはホストの物理 RAM から計算します。

Red Hat ナレッジベースには、swap パーティションの適切なサイズを安全かつ効率的に確定する方法について記載した記事が掲載されています: https://access.redhat.com/site/solutions/15244
KVM 要件

KVM ハイパーバイザーには、以下が必要です。

  • x86 ベースシステム向けの Intel VT-x および Intel 64 拡張機能を備えた Intel プロセッサー
  • AMD-V および AMD64 拡張機能を備えた AMD プロセッサー
ご使用のプロセッサーが仮想化拡張機能を備えているかどうかを判別するには、『Red Hat Enterprise Linux 6 仮想化管理ガイド』 を参照してください。
ストレージ対応

ゲスト仮想マシンのストレージ方法は、以下の通りです。

  • ローカルストレージ上のファイル
  • 物理ディスクパーティション
  • ローカル接続の物理 LUN
  • LVM パーティション
  • NFS 共有ファイルシステム
  • iSCSI
  • クラスター化した GFS2 ファイルシステム
  • ファイバーチャネルベースの LUN
  • イーサネット経由のファイバーチャネル (FCoE)

第3章 KVM ゲスト仮想マシンの互換性

ご使用のプロセッサーが仮想化拡張に対応しているかどうかの確認方法および仮想化拡張の有効化に関する情報については、『Red Hat Enterprise Linux 仮想化管理ガイド』 を参照してください。

3.1. Red Hat Enterprise Linux 6 におけるサポート制限

Red Hat Enterprise Linux 6 サーバーには、サポートに関する制限がいくつかあります。
Red Hat Enterprise Linux のプロセッサーおよびメモリー容量の制限については、以下のサイトで説明されています。
サポートされるオペレーティングシステムとホストおよびゲストの組み合わせの詳細な対応表については、以下のサイトを参照してください。

3.2. 対応 CPU モデル

それぞれのハイパーバイザーには、ゲストにデフォルトで表示する CPU 機能に関して独自のポリシーがあります。QEMU/KVM がゲストに表示する CPU 機能のセットはゲスト仮想マシン設定で選択される CPU モデルによって異なります。qemu32qemu64 は基本的な CPU モデルですが、他にも (追加の機能と共に) 使用できる CPU モデルがあります。
Red Hat Enterprise Linux 6 は以下のQEMU CPU モデル定義の使用に対応しています。

<!-- This is only a partial file, only containing the CPU models. The XML file has more information (including supported features per model) which you can see when you open the file yourself -->
<cpus>
  <arch name='x86'>
...

    <!-- Intel-based QEMU generic CPU models -->
    <model name='pentium'>
      <model name='486'/>
     </model>

    <model name='pentium2'>
      <model name='pentium'/>
    </model>

    <model name='pentium3'>
      <model name='pentium2'/>
    </model>

    <model name='pentiumpro'>
    </model>

    <model name='coreduo'>
      <model name='pentiumpro'/>
      <vendor name='Intel'/>
    </model>

    <model name='n270'>
      <model name='coreduo'/>
    </model>

    <model name='core2duo'>
      <model name='n270'/>
    </model>

    <!-- Generic QEMU CPU models -->
    <model name='qemu32'>
      <model name='pentiumpro'/>
    </model>

    <model name='kvm32'>
      <model name='qemu32'/>
    </model>

    <model name='cpu64-rhel5'>
      <model name='kvm32'/>
    </model>

    <model name='cpu64-rhel6'>
      <model name='cpu64-rhel5'/>
    </model>

    <model name='kvm64'>
      <model name='cpu64-rhel5'/>
    </model>

    <model name='qemu64'>
      <model name='kvm64'/>
    </model>

    <!-- Intel CPU models -->
    <model name='Conroe'>
      <model name='pentiumpro'/>
      <vendor name='Intel'/>
    </model>

    <model name='Penryn'>
      <model name='Conroe'/>
    </model>

    <model name='Nehalem'>
      <model name='Penryn'/>
    </model>

    <model name='Westmere'>
      <model name='Nehalem'/>
      <feature name='aes'/>
    </model>

    <model name='SandyBridge'>
      <model name='Westmere'/>
    </model>

    <model name='Haswell'>
      <model name='SandyBridge'/>
    </model>

    <!-- AMD CPUs -->
    <model name='athlon'>
      <model name='pentiumpro'/>
      <vendor name='AMD'/>
     </model>

    <model name='phenom'>
      <model name='cpu64-rhel5'/>
      <vendor name='AMD'/>
    </model>

    <model name='Opteron_G1'>
      <model name='cpu64-rhel5'/>
      <vendor name='AMD'/>
    </model>

    <model name='Opteron_G2'>
      <model name='Opteron_G1'/>
    </model>

    <model name='Opteron_G3'>
      <model name='Opteron_G2'/>
    </model>

    <model name='Opteron_G4'>
      <model name='Opteron_G2'/>
    </model>

    <model name='Opteron_G5'>
      <model name='Opteron_G4'/>
    </model>
  </arch>
</cpus>

注記

対応 CPU モデルの詳細リストと認識される CPUID フラグは、qemu-kvm -cpu ? コマンドを使用して確認することもできます。

第4章 仮想化の制限

この章では、Red Hat Enterprise Linux 6 の仮想化パッケージにおける追加サポートと製品の制限を説明しています。

4.1. KVM の制限

KVM ハイパーバイザーには、以下の制限が適用されます。
ゲストあたりの最大 vCPU 数
ゲストあたりのサポートされる仮想 CPU の最大数は、Red Hat Enterprise Linux 6 のどのマイナーバージョンをホストマシンとして使用しているかによって異なります。6.0 のリリースでは最大 64 に対応し、6.3 は最大 160 に対応しています。現在、6.6 のリリースはゲストあたり最大 160 の仮想 CPU に対応しています。
不変タイムスタンプカウンター (TSC) ビット
不変 TSC を搭載してないシステムは、追加設定が必要です。不変 TSC が搭載されているかどうかを確認し、関連する問題を解決するための設定手順についての詳細は、14章KVM ゲストのタイミング管理 を参照してください。
メモリーのオーバーコミット
KVM はメモリーのオーバーコミットをサポートし、ゲスト仮想マシンのメモリーを swap に保存できます。スワップが頻繁になされると仮想マシンの実行速度が遅くなります。swap パーティションのサイズを安全かつ効率的に決定する方法についての記事は、Red Hat ナレッジベースの https://access.redhat.com/site/solutions/15244 に記載されています。メモリーのオーバーコミットに KSM が使用される場合は、swap サイズがこの記事で説明されている推奨サイズにしたがっていることを確認してください。

重要

デバイス割り当てが使用されている場合、DMA を割り当てデバイスで有効にするにはすべての仮想マシンメモリーが静的に事前割り当てされる必要があります。このため、メモリーのオーバーコミットはデバイス割り当てではサポートされません。
CPU のオーバーコミット
1 つの物理プロセッサーコアあたりに 11 個以上の仮想 CPU を割り当てることは推奨されません。CPU オーバーコミット率の決定にはキャパシティープラニングツールの使用が推奨されます。割合はそれぞれのワークロードによって大きく異なるため、理想的な割合を予想することは困難です。たとえば、あるユースケースではゲスト仮想マシンが CPU を 100% 消費しますが、別のケースでは複数のゲストが完全にアイドル状態になる場合もあります。
Red Hat は、システム上に存在する物理コアの全体数より多くの vCPU を単一ゲストで実行することをサポートしていません。ハイパースレッドはコアとみなすことはできますが、そのパフォーマンスはシナリオによって異なり、通常のコアと同等のパフォーマンスは期待することはできません。
CPU のオーバーコミットに関するヒントや推奨事項については、『Red Hat Enterprise Linux 仮想化管理ガイド』 を参照してください。
仮想化 SCSI デバイス
Red Hat Enterprise Linux の KVM では、SCSI エミュレーションはサポートされていません。
仮想化 IDE デバイス
KVM では、ゲスト仮想マシン 1 台あたりの仮想化 (エミュレートされた) IDE デバイスは最大 4 つまでに制限されています。
PCI デバイス
Red Hat Enterprise Linux 6 は、仮想マシン 1 台あたり 32 の PCI デバイススロットと、デバイススロット 1 つあたり 8 つの PCI 機能をサポートします。つまりマルチ機能が有効化されると、理論上はゲストあたり最大 256 の PCI 機能が提供されることになります。
しかし、この理論上の最大数は以下の制限を受けます。
  • それぞれの仮想マシンがサポートするのは、最大 8 つの割り当てデバイス機能です。
  • 4 つの PCI デバイススロットは、デフォルトで 5 つのエミュレートされたデバイスに設定されています。しかしユーザーは、ゲストオペレーティングシステムの操作に不要な場合、デフォルト設定のエミュレートされたデバイスの内 2 つを明示的に削除できます (スロット 2 のビデオアダプターデバイスと、通常はスロット 3 である一番下にある利用可能なスロットのメモリーバルーンドライバーデバイス)。これにより、ユーザーは仮想マシン 1 台あたり最大 30 の PCI デバイススロット機能のサポートを受けられます。
さらに PCI デバイス割り当てには、以下の制限が適用されます。
  • PCI デバイス割り当て (PCI デバイスの仮想マシンへのアタッチ) で PCI-e デバイスのデバイス割り当てを有効にするには、ホストシステムが AMD IOMMU または Intel VT-d サポートを備えている必要があります。
  • パラレル/レガシー PCI では、PCI ブリッジ内側の単一デバイスのみがサポートされています。
  • ルート非対応の PCIe スイッチで接続されている複数 PCIe エンドポイントは、PCIe スイッチの PCIe ブリッジ内での ACS サポートを必要とします。この制限を無効にするには、/etc/libvirt/qemu.conf ファイルを編集して、以下の行を挿入します。
    relaxed_acs_check=1
  • Red Hat Enterprise Linux 6 では、ゲストデバイスドライバーによる PCI 設定領域へのアクセスは制限されています。この制限により、PCI 設定領域に依存するドライバーの設定が失敗する場合があります。
  • Red Hat Enterprise Linux 6.2 は、割り込み再マッピングを PCI デバイス割り当て要件として導入します。プラットフォームが割り込み再マッピングをサポートしない場合、コマンドラインプロンプトで root ユーザーとして以下のコマンドを実行して、このサポートの KVM チェックを回避します。
    # echo 1 > /sys/module/kvm/parameters/allow_unsafe_assigned_interrupts
マイグレーションの制限
仮想マシンの排他的使用において、デバイス割り当ては仮想マシンに公開されている物理デバイスを参照します。デバイス割り当ては、仮想マシンが実行されている特定のホスト上のハードウェアを使用するため、デバイス割り当ての使用中は、マイグレーションおよび保存/復元がサポートされません。ゲストオペレーティングシステムがホットプラグをサポートしている場合は、マイグレーションまたは保存/復元操作前に割り当てデバイスを削除してこの機能を有効にできます。
ライブマイグレーションは、CPU タイプが同一のホスト間でのみ可能です (つまり、Intel から Intel 、または AMD から AMD のみ)。
ライブマイグレーションでは on または off で、両方のホストが No eXecution (NX) ビットの同一値セットを備えている必要があります。
マイグレーションが動作するには、書き込みモードで開かれたすべてのブロックデバイスで cache=none が特定される必要があります。

警告

cache=none オプションを加えない場合、ディスクの破損につながる恐れがあります。
ストレージの制限
ディスク全体やブロックデバイス全体 (/dev/sdb など) への書き込みアクセスをゲスト仮想マシンに与えることには、リスクが伴います。ゲスト仮想マシンにブロックデバイス全体へのアクセスがあると、ホストマシンとボリュームラベルやパーティションテーブルを共有できるようになります。ホストシステムのパーティション認識コードにバグがあった場合、セキュリティーリスクを発生させることになります。ホストマシンがゲスト仮想マシンに割り当てたデバイスを無視するように設定することで、このリスクを回避します。

警告

ストレージ制限に従わない場合、セキュリティーリスクにつながる恐れがあります。
SR-IOV の制限
SR-IOV は、以下のデバイスとのみ完全なテストを行っています。 (他の SR-IOV デバイスは機能する可能性がありますが、リリース時にはテストを実施していません)
  • Intel® 82576NS Gigabit Ethernet Controller (igb ドライバー)
  • Intel® 82576EB Gigabit Ethernet Controller (igb ドライバー)
  • Intel® 82599ES 10 Gigabit Ethernet Controller (ixgbe ドライバー)
  • Intel® 82599EB 10 Gigabit Ethernet Controller (ixgbe ドライバー)
コアダンプの制限
コアダンプは現在、マイグレーションの場合と同じインフラストラクチャーに実装されているので、デバイス割り当ての使用中はサポートされません。

4.2. アプリケーションの制限

仮想化には、特定の種類のアプリケーションを不安定にする側面があります。
I/O スループット要件の高いアプリケーションでは、完全仮想化ゲスト用の準仮想化ドライバーの使用をお勧めします。準仮想化ドライバーがないと、特定のアプリケーションは I/O 負荷が高い場合に予期できない動きをする場合があります。
以下のアプリケーションは、I/O 要件が高い場合に回避することをお勧めします。
  • kdump サーバー
  • netdump サーバー
I/O を過剰に使用したり、リアルタイムのパフォーマンスが要求されるアプリケーションやツールは、慎重に評価することをお勧めします。I/O パフォーマンスを高めるには、準仮想化ドライバーか PCI デバイス割り当てを検討してください。完全仮想化ゲスト用の準仮想化ドライバーの詳細については、10章KVM 準仮想化 (virtio) ドライバー を参照してください。PCI デバイス割り当ての詳細については、12章PCI デバイス割り当て を参照してください。
仮想化環境でアプリケーションを実行すると、パフォーマンスが若干低下します。仮想化によってより新しく速いハードウェアに統合することでパフォーマンスにどのような利点がもたらされるかを評価するには、仮想化の使用に関連する潜在的なアプリケーションのパフォーマンス問題と比較して行うことをお勧めします。

4.3. その他の制限

仮想化に影響するその他の制限および問題の全リストは、『Red Hat Enterprise Linux 6 リリースノート』 に記載されています。『Red Hat Enterprise Linux 6 リリースノート』 では、現時点での新機能と、更新または発見された既知の問題および制限が説明されています。

第5章 仮想化パッケージのインストール

仮想化を使用する前に、コンピューターに仮想化パッケージをインストールする必要があります。仮想化パッケージは、Subscription Manager を使用してホストのインストール時またはインストール後にインストールすることができます。
KVM ハイパーバイザーは、kvm カーネルモジュールを使うデフォルトの Red Hat Enterprise Linux カーネルを使用します。

5.1. 仮想化ホストのインストールの設定

このセクションでは、新たに Red Hat Enterprise Linux をインストールする際の一部として、仮想化ツールおよび仮想化パッケージのインストールについて説明します。

注記

https://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/ からご利用いただける 『Red Hat Enterprise Linux インストールガイド』 は、Red Hat Enterprise Linux のインストールについて詳細に説明しています。

手順5.1 仮想化パッケージグループのインストール

  1. Red Hat Enterprise Linux 6 インストールプログラムを起動します。

    Red Hat Enterprise Linux のインストール CD-ROM または DVD、または PXE から対話形式の Red Hat Enterprise Linux 6 インストールを開始します。
  2. パッケージの選択までインストールを進めます。

    パッケージ選択のステップまで完了します。
    The The Red Hat Enterprise Linux package selection screen showing options to select a different set of software from regular installation. Virtualization Host is selected in the upper menu, and Red Hat Enterprise Linux is selected from the list of additional repositories. Customize now is selected at the bottom of the window, with Back and Next buttons shown at the bottom right corner of the window.

    図5.1 Red Hat Enterprise Linux パッケージ選択の画面

    サーバーの役割に 仮想化ホスト を選択し、ゲスト仮想マシン用のプラットフォームをインストールします。または、次に進む前に 今すぐカスタマイズ のラジオボタンが選択されていることを確認して、個別のパッケージを指定します。
  3. 仮想化 パッケージグループを選択します。

    ここではインストールに qemu-kvm エミュレーター、virt-managerlibvirtvirt-viewer を選択します。
    The Red Hat Enterprise Linux package selection screen with Virtualization selected in the left menu.

    図5.2 Red Hat Enterprise Linux パッケージ選択の画面

    注記

    後でグラフィカルユーザーインターフェース (virt-manager) 内に仮想マシンを作成したい場合は、General Purpose Desktop パッケージグループも選択することをお勧めします。
  4. パッケージのカスタマイズ (必要な場合)

    他の仮想化パッケージが必要な場合は、仮想化 グループをカスタマイズします。
    The Red Hat Enterprise Linux package selection screen with a pop-up Packages in Virtualization window showing the packages available to be installed.

    図5.3 Red Hat Enterprise Linux パッケージ選択の画面

    閉じる ボタンをクリックし、次に ボタンをクリックしてインストールを続けます。
インストールが完了したら、システムを再起動します。

重要

仮想化パッケージの更新を受信するには、有効な仮想化エンタイトルメントが必要です。
キックスタートファイルによる KVM パッケージのインストール

キックスタートファイルを使用すると、ユーザーが手作業で個別のホストシステムをインストールすることなく、自動で大規模インストールが可能になります。このセクションでは、キックスタートファイルを作成し、これを使用して、仮想化パッケージで Red Hat Enterprise Linux をインストールする方法を説明します。

キックスタートファイルの %packages セクションでは、以下のパッケージグループを追加します。
@virtualization
@virtualization-client
@virtualization-platform
@virtualization-tools
キックスタートファイルについてさらに詳しくは、https://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/ からご利用いただける 『Red Hat Enterprise Linux インストールガイド』 を参照してください。

5.2. 既存の Red Hat Enterprise Linux システム上への仮想化パッケージのインストール

このセクションでは、動作中の Red Hat Enterprise Linux 6 またはそれ以降に KVM ハイパーバイザーをインストールするステップを説明します。
パッケージをインストールするには、マシンを登録しておく必要があります。Red Hat サブスクリプションマネージャーで登録するには、subscription-manager register コマンドを実行してプロンプトに従います。
有効な Red Hat サブスクリプションをお持ちでない場合は、Red Hat オンラインストア で取得してください。

注記

Red Hat Network (RHN) は非推奨となりました。登録のタスクには Subscription Manager を使用する必要があります。
yum を使用して仮想化パッケージをインストール

Red Hat Enterprise Linux 上で仮想化を使用するには、少なくとも qemu-kvmqemu-img パッケージが必要になります。これらのパッケージは、ホストの Red Hat Enterprise Linux システム上にユーザーレベルの KVM エミュレーターとディスクイメージマネージャーを提供します。

qemu-kvmqemu-img パッケージをインストールするには、以下のコマンドを実行します。
# yum install qemu-kvm qemu-img
以下の仮想化管理パッケージも利用可能です。
これらの推奨される仮想化パッケージすべては、以下のコマンドでインストールしてください。
# yum install virt-manager libvirt libvirt-python python-virtinst libvirt-client
仮想化パッケージグループのインストール

仮想化パッケージは、パッケージグループからもインストールできます。以下の表は、仮想化パッケージグループとその役割を示したものです。

注記

qemu-img パッケージは、システム上ですでにインストールされていない場合に Virtualization パッケージグループに依存する形でインストールされます。また、前述の yum install qemu-img コマンドで手動でインストールすることも可能です。

表5.1 仮想化パッケージグループ

パッケージグループ説明必須パッケージオプションパッケージ
Virtualization仮想化マシンのホスティング環境を提供qemu-kvmqemu-guest-agent、qemu-kvm-tools
Virtualization Client仮想化インスタンスのインストールおよび管理クライアントpython-virtinst、virt-manager、virt-viewervirt-top
Virtualization Platform仮想マシンおよびコンテナーのアクセスおよび制御インターフェースを提供libvirt、libvirt-client、virt-who、virt-whatfence-virtd-libvirt、fence-virtd-multicast、fence-virtd-serial、libvirt-cim、libvirt-java、libvirt-qmf、libvirt-snmp、perl-Sys-Virt
Virtualization Toolsオフラインでの仮想イメージ管理のツールlibguestfslibguestfs-java、libguestfs-tools、virt-v2v
パッケージグループをインストールするには、yum groupinstall <groupname> コマンドを実行します。たとえば、Virtualization Tools パッケージグループのインストールには、yum groupinstall "Virtualization Tools" コマンドを実行します。

第6章 ゲスト仮想マシンのインストール概要

仮想化パッケージをホストシステムにインストールすると、ゲストオペレーティングシステムの作成が可能になります。この章では、仮想マシンにゲストオペレーティングシステムをインストールする全般的なプロセスを説明します。ゲスト仮想マシンの作成は、virt-manager新規作成 ボタンか、virt-install コマンドラインインターフェースを使用します。どちらの方法も、この章で説明されています。
Red Hat Enterprise Linux および Microsoft Windows の特定バージョンの詳細なインストール方法は、この後に続く章で説明されています。

6.1. ゲスト仮想マシンの前提条件および留意事項

ゲスト仮想マシンを作成する前には、様々な要素を考慮すべきです。デプロイ前に仮想マシンの役割を考えるだけでなく、定期的な継続モニタリングと (負荷やクライアント数などの) 様々な要素に基づく評価の実行をお勧めします。考慮に入れる要素としては、以下のものが挙げられます。
パフォーマンス
ゲスト仮想マシンは、目的のタスクに基づいてデプロイし、設定することをお勧めします。ゲストシステムには、パフォーマンスで特別な考慮を必要とするものもあります (たとえば、データベースサーバーを実行するゲスト) 。ゲストの役割や予測されるシステム負荷によっては、ゲストがより多くの割り当て CPU やメモリーを必要とすることもあります。
入出力要件と入出力タイプ
ゲスト仮想マシンの中には、特別高い入出力要件があるものや、入出力タイプに基づいてさらなる注意や予測を必要とするものもあります (たとえば、通常のディスクブロックサイズのアクセスやクライアント数)。
ストレージ
ゲスト仮想マシンの中には、ストレージやより高速のディスクタイプへの優先度の高いアクセスを必要とするものもあります。ストレージのデプロイとメンテナンス時には、ゲストが使用するストレージ容量も定期的に監視して考慮することをお勧めします。
ネットワーク構成およびネットワークインフラストラクチャー
ゲスト仮想マシンの環境によっては、他のゲストより高速のネットワークリンクを必要とするものもあります。帯域幅や待ち時間はゲストのデプロイおよびメンテナンス時に考慮すべき要素であることが多々あり、要件や負荷が変化する際は特にそうです。
リクエスト要件
SCSI リクエストは、virtio ドライブがディスク全体をベースとし、ディスクデバイスパラメーターが以下の例のように lun に設定されいる場合にのみ、virtio ドライブ上のゲスト仮想マシンに発行されます。
<devices>
   <emulator>/usr/libexec/qemu-kvm</emulator>
   <disk type='block' device='lun'>

6.2. virt-install を使用したゲストの作成

コマンドラインから virt-install コマンドを使用してゲスト仮想マシンを作成することができます。 virt-install は、対話形式で、または仮想マシンの自動作成するスクリプトの一部として使用されます。virt-install をキックスタートファイルと共に使用すると、仮想マシンの無人インストールが可能になります。
virt-install ツールは、コマンドラインで使用可能な数多くのオプションを提供します。オプションのリストすべてを表示するには、以下のコマンドを実行します。
# virt-install --help
virt-install コマンドが正しく完了するには、root 権限が必要となります。virt-install の man ページも、各コマンドのオプションと重要な変数について記載しています。
qemu-img は、virt-install の前にストレージオプションを設定するために使用可能な関連コマンドです。
--graphics は重要なオプションで、仮想マシンのグラフィカルインストールを可能にします。

例6.1 virt-install を使用した Red Hat Enterprise Linux 5 のゲスト仮想マシンのインストール

この例では、Red Hat Enterprise Linux 5 ゲストを作成します。
virt-install \
   --name=guest1-rhel5-64 \
   --file=/var/lib/libvirt/images/guest1-rhel5-64.dsk \
   --file-size=8 \
   --nonsparse --graphics spice \
   --vcpus=2 --ram=2048 \
   --location=http://example1.com/installation_tree/RHEL5.6-Server-x86_64/os \
   --network bridge=br0 \
   --os-type=linux \
   --os-variant=rhel5.4
このコマンドを実行する際は、オペレーティングシステムで正しい os-type を選択していることを確認してください。
他の例については、man virt-install を参照してください。

注記

virt-install で Windows ゲストをインストールする場合は、--os-type=windows オプションが推奨されます。このオプションでは、インストール手順を実行中の再起動で CD-ROM の切断を回避します。--os-variant オプションは、特定のゲストオペレーティングシステムの設定をさらに最適化します。

6.3. virt-manager を使用したゲスト作成

仮想マシンマネージャーとしても知られる virt-manager は、ゲスト仮想マシンを作成、管理するグラフィカルツールです。

手順6.1 virt-manager を使ったゲスト仮想マシンの作成

  1. virt-manager を開く

    virt-manager を開始します。アプリケーション メニューを開き、システムツール サブメニューから仮想マシンマネージャー アプリケーションを起動します。または、root で virt-manager コマンドを実行します。
  2. オプション: リモートハイパーバイザーを開く

    ハイパーバイザーを選択し、接続 ボタンを押してリモートハイパーバイザーに接続します。
  3. 新規の仮想マシンを作成

    virt-manager ウィンドウで新規の仮想マシンを作成できます。新しい仮想マシンの作成 ボタン (図6.1「仮想マシンマネージャーのウィンドウ」) をクリックして 新しい仮想マシン ウィザードを開きます。
    仮想マシンマネージャーのウィンドウ

    図6.1 仮想マシンマネージャーのウィンドウ

    新しい仮想マシン ウィザードでは、仮想マシン作成が 5つ のステップで行われます。
    1. ゲスト仮想マシンの名前の入力とインストール方法の選択
    2. インストールメディアの場所の選択と設定
    3. メモリーと CPU オプションの設定
    4. 仮想マシンのストレージの設定
    5. ネットワーク、アーキテクチャー、他のハードウェアの設定
    次に進む前に、virt-manager がインストールメディアにアクセスできることを確認してください (ローカルまたはネットワーク経由) 。
  4. 名前とインストール方法の特定

    最初にゲスト仮想マシンに名前を付け、インストール方法を選択します。仮想マシンの名前にはアンダースコア (_) 、ピリオド (.) 、ハイフン (-) を使用することができます。
    仮想マシンに名前を付けてインストール方法を選択

    図6.2 仮想マシンに名前を付けてインストール方法を選択

    仮想マシンの名前を入力し、インストール方法を選択します。
    ローカルのインストールメディア (ISO イメージまたは CD-ROM ドライブ)
    この方法では、CD-ROM か DVD 、インストールディスクのイメージを使用します (例、.iso)。
    ネットワークインストール (HTTP, FTP, または NFS)
    この方法では、ミラー化された Red Hat Enterprise Linux または Fedora インストールツリーを使ってゲストをインストールします。インストールツリーには、HTTP または FTP、または NFS のいずれかでアクセスできる必要があります。
    ネットワークブート (PXE)
    この方法では、Preboot eXecution Environment (PXE) サーバーを使用してゲスト仮想マシンをインストールします。PXE サーバーの設定は、『導入ガイド』で説明されています。ネットワークブートでインストールするには、ゲストがルーティング可能な IP アドレスまたは共有ネットワークデバイスを備えている必要があります。PXE インストールのネットワーク設定要件に付いての情報は、「PXE を使用したゲスト仮想マシンのインストール」 を参照してください。
    既存のディスクイメージをインポート
    この方法では、新しいゲスト仮想マシンを作成し、そこにディスクイメージ (インストール済みの起動可能なオペレーティングシステムを含む) をインポートできます。
    進む をクリックし、続けます。
  5. インストール設定

    次に、インストールする OS の種類バージョン を選びます。仮想マシンに適した OS の種類を選択することを確認してください。インストール方法によっては、インストールの URL または既存のストレージパスを指定します。
    リモートインストールの URL

    図6.3 リモートインストールの URL

    ローカル ISO イメージのインストール

    図6.4 ローカル ISO イメージのインストール

  6. CPU およびメモリーの設定

    次に、仮想マシンに割り当てる CPU の数とメモリー量を設定します。ウィザードでは、割り当て可能な CPU の数とメモリー量が表示されます。これらを設定して、進む をクリックします。
    CPU およびメモリーの設定

    図6.5 CPU およびメモリーの設定

  7. ストレージの設定

    ゲスト仮想マシンにストレージを割り当てます。
    仮想マシンのストレージの設定

    図6.6 仮想マシンのストレージの設定

    最初のステップで既存のディスクイメージのインポートを選択した場合は、virt-manager はこのステップを飛ばします。
    仮想マシンと必要なアプリケーションに十分な領域を割り当て、進む をクリックして次に進みます。
  8. 最終設定

    仮想マシンの設定を確認し、問題がなければ完了 をクリックします。デフォルトのネットワーク設定、仮想化の種類、アーキテクチャーで仮想マシンが作成されます。
    設定の確認

    図6.7 設定の確認

    仮想マシンのハードウェアをさらに設定したい場合は、完了 をクリックする前に インストールの前に設定をカスタマイズする ボックスにチェックを入れます。新たなウィザードが開き、仮想マシンのハードウェア設定で追加や削除、設定が可能になります。
    仮想マシンのハードウェアを設定した後に 適用 をクリックします。virt-manager が指定されたハードウェア設定で仮想マシンを作成します。

6.4. PXE を使用したゲスト仮想マシンのインストール

要件

PXE ゲストインストールでは、インストールするゲスト仮想マシンと同じサブネット上で PXE サーバーが実行中である必要があります。この実行方法は、仮想マシンのネットワーク接続方法によって異なります。PXE サーバーの設定でヘルプが必要な場合は、サポートに連絡してください。

virt-install による PXE インストール

virt-install PXE インストールでは、installation がブリッジ名となる --network=bridge:installation パラメーターと、--pxe パラメーターの両方が必要となります。

デフォルトでは、ネットワークが見つからない場合、ゲスト仮想マシンは別の起動可能なデバイスから起動を試みます。起動可能なデバイスが見つからない場合は、ゲストは一時停止します。起動可能なデバイスが見つからない場合は、以下のような qemu-kvm ブートパラメーター reboot-timeout を使ってゲストの起動を再度試すことができます。
# qemu-kvm -boot reboot-timeout=1000

例6.2 virt-install を使用した完全仮想化 PXE インストール

# virt-install --hvm --connect qemu:///system \
--network=bridge:installation --pxe --graphics spice \
--name rhel6-machine --ram=756 --vcpus=4 \
--os-type=linux --os-variant=rhel6 \
--disk path=/var/lib/libvirt/images/rhel6-machine.img,size=10
上記のコマンドは、テキストのみの環境では実行できないことに注意してください。完全仮想化 (--hvm) ゲストは、--graphics spice パラメーターではなく、--location--extra-args "console=console_type" が指定されている場合にのみ、テキストのみの環境でインストールできます。

手順6.2 virt-manager を使用した PXE インストール

  1. PXE の選択

    インストール方法として PXE を選択し、続くステップで OS の種類やメモリー、CPU、およびストレージを設定します。
    Step 1 of 5 for creating a new virtual machine with virt-manager, with Network Boot (PXE) chosen for the method of installation.

    図6.8 インストール方法の選択

    Step 2 of 5 for creating a new virtual machine with virt-manager, with Linux chosen as OS Type and Red Hat Enterprise Linux 6 chosen for version.

    図6.9 インストールする OS の種類の選択

    Step 3 of 5 for creating a new virtual machine with virt-manager showing memory and CPU settings, with 1024MB of RAM and 2 CPUs selected.

    図6.10 仮想化ハードウェア詳細の指定

    Step 4 of 5 for creating a new virtual machine with virt-manager, with checkboxes selected next to "Enable storage for this virtual machine" and "Allocate entire disk now". 8GB is selected under the heading "Create a disk image on the computer's hard drive".

    図6.11 ストレージ詳細の指定

  2. インストールの開始

    インストールを開始する準備ができました。
    Step 5 of 5 for creating a new virtual machine with virt-manager reads "Ready to begin installation of (guest name)" with a summary of options already chosen, and advanced options to choose from.

    図6.12 仮想マシン詳細を完了

DHCP リクエストが送信され、有効な PXE サーバーが見つかるとゲスト仮想マシンのインストールプロセスが開始されます。

第7章 Red Hat Enterprise Linux 6 ホスト上での Red Hat Enterprise Linux 6 ゲスト仮想マシンのインストール

この章では、Red Hat Enterprise Linux 6 ホスト上で Red Hat Enterprise Linux 6 ゲスト仮想マシンをインストールする方法を説明します。
ここでは、KVM ハイパーバイザーと他の必要なパッケージがすべてインストールされ、ホストが仮想化用に設定されていることを前提としています。

注記

仮想化パッケージのインストールについてさらに詳しくは、5章仮想化パッケージのインストール を参照してください。

7.1. ローカルのインストールメディアを使用した Red Hat Enterprise Linux 6 ゲストの作成

ここでは、ローカルに保存されているインストール DVD や DVD イメージで Red Hat Enterprise Linux 6 のゲスト仮想マシンを作成する方法を説明します。Red Hat Enterprise Linux 6 の DVD イメージは、http://access.redhat.com で入手できます。

手順7.1 virt-manager を使用した Red Hat Enterprise Linux 6 ゲスト仮想マシンの作成

  1. オプション: 準備

    仮想マシン用のストレージ環境を準備します。ストレージの準備についてさらに詳しくは、『Red Hat Enterprise Linux 6 仮想化管理ガイド』 を参照してください。

    重要

    ゲスト仮想マシンの保存には、様々な種類のストレージが使用できます。しかし、仮想マシンでマイグレーション機能を使用するには、仮想マシンをネットワーク化されたストレージ上に作成する必要があります。
    Red Hat Enterprise Linux 6 には、少なくとも 1GB のストレージ領域が必要です。しかし Red Hat は、Red Hat Enterprise Linux 6 のインストールと本ガイドの手順に、5GB 以上のストレージ領域を推奨します。
  2. virt-manager を開き、ウィザードを開始する

    virt-manager を開くには、root で virt-manager コマンドを実行するか、または アプリケーションシステムツール仮想マシンマネージャー を開きます。
    仮想マシンマネージャーのウィンドウ

    図7.1 仮想マシンマネージャーのウィンドウ

    新しい仮想マシンの作成 ボタンをクリックして、新しい仮想化ゲストのウィザードを開始します。
    新しい仮想マシンの作成ボタン

    図7.2 新しい仮想マシンの作成ボタン

    新しい仮想マシン ウィンドウが開きます。
  3. 仮想マシンに名前を付ける

    仮想マシンの名前には、文字、数字と、アンダースコア (_)、ピリオド (.) 、ハイフン (-) を使用することができます。仮想マシンのマイグレーションでは、名前は一意のものである必要があり、数字のみの名前は使用できません。
    ローカルのインストールメディア (ISO イメージまたは CD-ROM ドライブ) ラジオボタンを選択します。
    新しい仮想マシンウィンドウ - ステップ 1

    図7.3 新しい仮想マシンウィンドウ - ステップ 1

    進む をクリックして次に進みます。
  4. インストールメディアの選択

    インストールメディアを選択します
    インストールメディアの場所

    図7.4 インストールメディアの場所

    • CD-ROM または DVD からインストールする場合は、CD-ROM または DVD を使用 ラジオボタンを選択し、利用可能なドライブのドロップダウンリストから適切なディスクドライブを選択します。
    • ISO イメージからインストールする場合は、ISO イメージを使用 を選択し、参照... ボタンをクリックして ISO メディアボリュームの検索 ウィンドウを開きます。
      使用するインストールイメージを選択し、ボリュームを選択 をクリックします。
      ISO メディアボリュームの検索 ウィンドウにイメージが表示されない場合、ローカルを参照 ボタンをクリックしてホストマシンにあるインストールイメージまたはインストールディスクのある DVD ドライブを参照します。インストールイメージまたはインストールディスクのある DVD ドライブを選択して 開く をクリックします。使用するボリュームが選択され、新しい仮想マシンを作成 ウィザードに戻ります。

      重要

      ISO イメージファイルまたはゲストストレージファイルで推奨されるロケーションは、/var/lib/libvirt/images/ です。それ以外のロケーションは、SELinux による新たな設定が必要になる可能性があります。SELinux の設定についてさらに詳しくは、Red Hat Enterprise Linux 6 『仮想化管理ガイド』 を参照してください。
    選択したインストールメディアに合ったオペレーティングシステムの種類とバージョンを選択します。
    新しい仮想マシンウィンドウ - ステップ 2

    図7.5 新しい仮想マシンウィンドウ - ステップ 2

    進む をクリックして次に進みます。
  5. RAM および 仮想 CPU の設定

    仮想 CPU と割り当てる RAM の適切な値を選択します。これらの値は、ホストとゲストのパフォーマンスに影響します。メモリーと仮想 CPU はオーバーコミットが可能です。オーバーコミットについてさらに詳しくは、『Red Hat Enterprise Linux 6 仮想化管理ガイド』 を参照してください。
    仮想マシンの効率的かつ効果的な実行には、十分な物理メモリー (RAM) が必要です。Red Hat は、仮想マシンでは最小 512MB の RAM をサポートします。論理コアあたりでは、最小 1024MB の RAM を推奨します。
    十分な数の仮想 CPU を仮想マシンに割り当てます。仮想マシンがマルチスレッドのアプリケーションを実行する場合は、効率的な実行に必要な数の仮想 CPU を割り当てます。
    ホストシステムで利用可能な物理プロセッサー (またはハイパースレッド) よりも多くの仮想 CPU を割り当てることはできません。利用可能な仮想 CPU 数は、最大 X 個まで使用できます のフィールドに表示されます。
    新しい仮想マシンウィンドウ - ステップ 3

    図7.6 新しい仮想マシンウィンドウ - ステップ 3

    進む をクリックして次に進みます。
  6. ストレージ

    ストレージを有効にして Red Hat Enterprise Linux 6 ゲスト仮想マシンに割り当てます。デスクトップのインストールでは少なくとも 5GB を、最小構成インストールでは少なくとも 1GB を割り当てます。

    注記

    ライブおよびオフラインマイグレーションでは、仮想マシンは共有ネットワークストレージにインストールされる必要があります。仮想マシン用の共有ストレージの設定についてさらに詳しくは、『Red Hat Enterprise Linux 仮想化管理ガイド』を参照してください。
    1. デフォルトのローカルストレージを使用

      コンピューターのハードディスク上にディスクイメージを作成 ラジオボタンを選択し、デフォルトのストレージプールである /var/lib/libvirt/images/ ディレクトリーにファイルベースのイメージを作成します。さらに、作成するディスクイメージのサイズを入力します。今すぐディスク全体を割り当てる チェックボックスが選択されていると、指定されたサイズのディスクイメージが即座に作成されます。選択されていない場合は、ディスクイメージは要求に応じて大きくなります。

      注記

      ストレージプールは仮想コンテナーであるものの、qemu-kvm によって許可される最大サイズとホストの物理マシン上のディスクのサイズという 2 つの要素によって制限されます。ストレージプールはホストの物理マシンのディスクのサイズを超えることはできません。以下が最大サイズです。
      • virtio-blk = 2^63 バイトまたは 8 エクサバイト (raw ファイルまたはディスクを使用)
      • Ext4 = ~ 16 TB (4 KB ブロックサイズを使用)
      • XFS = ~8 エクサバイト
      • qcow2 とホストファイルシステムはそれぞれ独自のメタデータを維持し、非常に大きなイメージサイズを使用する場合はスケーラビリティーの評価または調整を行う必要があります。raw ディスクを使用すると、スケーラビリティーや最大サイズに影響を与える可能性のある層の数が少なくなります。
      新しい仮想マシンウィンドウ - ステップ 4

      図7.7 新しい仮想マシンウィンドウ - ステップ 4

      進む をクリックしてローカルのハードドライブにディスクイメージを作成します。または、管理しているか、他の既存のストレージを選択する を選択し、参照 を選択して管理しているストレージを設定します。
    2. ストレージプールを使用

      前のステップでストレージプールの使用に 管理しているか、他の既存のストレージを選択する を選択し、参照 をクリックすると、ストレージボリュームの検索または作成 ウィンドウが表示されます。
      ストレージボリュームの検索または作成ウィンドウ

      図7.8 ストレージボリュームの検索または作成ウィンドウ

      1. Storage Pools リストからストレージプールを選択します。
      2. オプション: 新規ボリューム ボタンをクリックして新しいストレージボリュームを作成します。ストレージボリュームを追加 スクリーンが表示されます。新規ストレージボリュームの名前を入力します。
        フォーマット ドロップダウンメニューからフォーマットのオプションを選択します。フォーマットオプションには、raw、cow、qcow、qcow2、qed、vmdk、vpc があります。他のフィールドも必要に応じて調整します。
        ストレージボリュームを追加ウィンドウ

        図7.9 ストレージボリュームを追加ウィンドウ

    完了 ボタンをクリックして、次に進みます。
  7. 確認および終了

    ウィザード中にエラーがなく、期待通りにすべてが表示されていることを確認します。
    インストールの前に設定をカスタマイズする チェックボックスを選択し、ゲストのストレージまたはネットワークデバイスを変更して準仮想化ドライバーを使用するか、または新たなデバイスを追加します。
    詳細なオプション の下向き矢印キーをクリックし、詳細なオプションを確認し、修正します。標準的な Red Hat Enterprise Linux 6 インストールの場合、これらのオプションのいずれも修正する必要はありません。
    新しい仮想マシンウィンドウ - ローカルストレージ

    図7.10 新しい仮想マシンウィンドウ - ローカルストレージ

    完了 ボタンをクリックして Red Hat Enterprise Linux インストールを続けます。Red Hat Enterprise Linux 6 のインストールについてさらに詳しくは、『Red Hat Enterprise Linux 6 インストールガイド』 を参照してください。
これで ISO インストールディスクイメージから Red Hat Enterprise Linux 6 ゲスト仮想マシンが作成されました。

7.2. ネットワークインストールツリーを使用した Red Hat Enterprise Linux 6 ゲストの作成

手順7.2 virt-manager を使用した Red Hat Enterprise Linux 6 ゲストの作成

  1. オプション: 準備

    ゲスト仮想マシン用のストレージ環境を準備します。ストレージの準備についてさらに詳しくは、『Red Hat Enterprise Linux 6 仮想化管理ガイド』 を参照してください。

    重要

    ゲスト仮想マシンの保存には、様々な種類のストレージが使用できます。しかし、仮想マシンでマイグレーション機能を使用するには、仮想マシンをネットワーク化されたストレージ上に作成する必要があります。
    Red Hat Enterprise Linux 6 には、少なくとも 1GB のストレージ領域が必要です。しかし Red Hat は、Red Hat Enterprise Linux 6 のインストールと本ガイドの手順に、5GB 以上のストレージ領域を推奨します。
  2. virt-manager を開き、ウィザードを開始する

    virt-manager を開くには、root で virt-manager コマンドを実行するか、または アプリケーションシステムツール仮想マシンマネージャー を開きます。
    virt-manager のメインウィンドウ

    図7.11 virt-manager のメインウィンドウ

    新しい仮想マシンの作成 ボタンをクリックして、新しい仮想マシンのウィザードを開始します。
    新しい仮想マシンの作成ボタン

    図7.12 新しい仮想マシンの作成ボタン

    新しい仮想マシンを作成 ウィンドウが表示されます。
  3. 仮想マシンに名前を付ける

    仮想マシンの名前には、文字、数字と、アンダースコア (_)、ピリオド (.) 、ハイフン (-) を使用することができます。仮想マシンのマイグレーションでは、名前は一意のものである必要があり、数字のみの名前は使用できません。
    ラジオボタンのリストからインストール方法を選択します。
    新しい仮想マシンウィンドウ - ステップ 1

    図7.13 新しい仮想マシンウィンドウ - ステップ 1

    進む をクリックして次に進みます。
  4. インストール URL を指定します。必要に応じて、キックスタート URL およびカーネルオプションを指定します。
    新しい仮想マシンウィンドウ - ステップ 2

    図7.14 新しい仮想マシンウィンドウ - ステップ 2

    進む をクリックして次に進みます。
  5. 残りのステップは、ISO インストール手順と同じです。ISO インストール手順の ステップ 5 から続行します。

7.3. PXE を使用した Red Hat Enterprise Linux 6 ゲストの作成

手順7.3 virt-manager を使用した Red Hat Enterprise Linux 6 ゲストの作成

  1. オプション: 準備

    仮想マシン用のストレージ環境を準備します。ストレージの準備についてさらに詳しくは、『Red Hat Enterprise Linux 6 仮想化管理ガイド』 を参照してください。

    重要

    ゲスト仮想マシンの保存には、様々な種類のストレージが使用できます。しかし、仮想マシンでマイグレーション機能を使用するには、仮想マシンをネットワーク化されたストレージ上に作成する必要があります。
    Red Hat Enterprise Linux 6 には、少なくとも 1GB のストレージ領域が必要です。しかし Red Hat は、Red Hat Enterprise Linux 6 のインストールと本ガイドの手順に、5GB 以上のストレージ領域を推奨します。
  2. virt-manager を開き、ウィザードを開始する

    virt-manager を開くには、root で virt-manager コマンドを実行するか、または アプリケーションシステムツール仮想マシンマネージャー を開きます。
    virt-manager のメインウィンドウ

    図7.15 virt-manager のメインウィンドウ

    新しい仮想マシンの作成 ボタンをクリックして、新しい仮想化ゲストのウィザードを開始します。
    新しい仮想マシンの作成ボタン

    図7.16 新しい仮想マシンの作成ボタン

    新しい仮想マシン ウィンドウが開きます。
  3. 仮想マシンに名前を付ける

    仮想マシンの名前には、文字、数字と、アンダースコア (_)、ピリオド (.) 、ハイフン (-) を使用することができます。仮想マシンのマイグレーションでは、名前は一意のものである必要があり、数字のみの名前は使用できません。
    ラジオボタンのリストからインストール方法を選択します。
    新しい仮想マシンウィンドウ - ステップ 1

    図7.17 新しい仮想マシンウィンドウ - ステップ 1

    進む をクリックして次に進みます。
  4. 残りのステップは、ISO インストール手順と同じです。ISO インストール手順の ステップ 5 から続行します。これ以降の PXE 手順で唯一異なるのは、最後の 新しい仮想マシン 画面で インストール: PXE インストール フィールドが表示される点です。
    新しい仮想マシンウィンドウ - ステップ 5 - PXE インストール

    図7.18 新しい仮想マシンウィンドウ - ステップ 5 - PXE インストール

第8章 他のプラットフォーム上での Red Hat Enterprise Linux の仮想化

この章では、他の仮想化ホスト上で Red Hat Enterprise Linux 6 を仮想化オペレーティングシステムとして実行する際に便利な参考資料について記載しています。

8.1. VMware ESX

Red Hat Enterprise Linux 6.0 以降では、vmw_balloon ドライバーを提供しています。これは、VMWare ホスト上で Red Hat Enterprise Linux を実行する際に使用される準仮想化メモリーバルーニングドライバーです。このドライバーについてさらに詳しくは、http://kb.VMware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1002586 を参照してください。
Red Hat Enterprise Linux 6.3 以降では、vmmouse_drv ドライバーを提供しています。これは、VMware ホスト上で Red Hat Enterprise Linux を実行する際に使用される準仮想化マウスドライバーです。このドライバーについてさらに詳しくは、http://kb.VMware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=5739104 を参照してください。
Red Hat Enterprise Linux 6.3 以降では、vmware_drv ドライバーを提供しています。これは、VMware ホスト上で Red Hat Enterprise Linux を実行する際に使用される準仮想化ビデオドライバーです。このドライバーについてさらに詳しくは、http://kb.VMware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1033557 を参照してください。
Red Hat Enterprise Linux 6.3 以降では、vmxnet3 ドライバーを提供しています。これは、VMware ホスト上で Red Hat Enterprise Linux を実行する際に使用される準仮想化ネットワークアダプターです。このドライバーについてさらに詳しくは、http://kb.VMware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1001805 を参照してください。
Red Hat Enterprise Linux 6.4 以降では、vmw_pvscsi ドライバーを提供しています。これは、VMware ホスト上で Red Hat Enterprise Linux を実行する際に使用される準仮想化 SCSI アダプターです。このドライバーについてさらに詳しくは、http://kb.VMware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010398 を参照してください。

8.2. Hyper-V

Red Hat Enterprise Linux 6.4 以降には、Microsoft の Linux Integration Services が同梱されています。これは、対応する仮想化オペレーティングシステムで統合デバイスサポートを有効にするドライバーセットです。このドライバーについての詳細は、http://technet.microsoft.com/en-us/library/dn531030.aspx を参照してください。
以下の機能強化により、Red Hat Enterprise Linux ゲスト仮想マシンの導入と管理がより簡単になりました。
  • アップグレードされた VMBUS プロトコル - VMBUS プロトコルが Windows 8 レベルにアップグレードされました。この機能強化の一環として、VMBUS 割り込みがゲストの利用可能なすべての仮想 CPU で処理できるようになりました。さらに、Red Hat Enterprise Linux ゲスト仮想マシンと Windows ホスト物理マシン間のシグナルプロトコルが最適化されています。
  • 統合フレームバッファードライバー - グラフィックスパフォーマンスを強化し、Red Hat Enterprise Linux デスクトップのユーザーに対して優れた解像度を提供します。
  • ライブ仮想マシンバックアップサポート - ライブ Red Hat Enterprise Linux ゲスト仮想マシンの中断なしのバックアップサポートを提供します。
  • 固定サイズの Linux VHDX を動的に拡張 - ライブのマウントされている固定サイズの Red Hat Enterprise Linux VHDX の拡張を可能にします。
  • UEFI を使用した起動 - UEFI (Unified Extensible Firmware Interface) を使用して Hyper-V 2012 R2 ホスト上で仮想マシンを起動することが可能になりました。
さらに詳しくは、以下の記事を参照してください: Enabling Linux Support on Windows Server 2012 R2 Hyper-V

第9章 完全仮想化 Windows ゲストのインストール

この章では、コマンドライン (virt-install) を使用して完全仮想化 Windows ゲストを作成する方法、ゲスト内でオペレーティングシステムのインストーラーを起動する方法、 virt-viewer でインストーラーにアクセスする方法を説明します。
ゲスト上に Windows オペレーティングシステムをインストールするには、virt-viewer ツールを使用します。このツールは、仮想マシンのグラフィカルコンソールを (SPICE または VNC プロトコル経由で) 表示します。これにより、virt-viewer を使って、インストールするオペレーティングシステムのインストーラー (たとえば Windows XP インストーラー) で完全仮想化ゲストのオペレーティングシステムをインストールできるようになります。
Windows オペレーティングシステムのインストールには、2 つのステップがあります。
  1. virt-install または virt-manager のいずれかを使用してゲスト仮想マシンを作成する。
  2. virt-viewer を使用してゲスト仮想マシン上に Windows オペレーティングシステムをインストールする。
virt-install または virt-manager を使用したゲスト仮想マシンの作成については、6章ゲスト仮想マシンのインストール概要 を参照してください。
この章は、完全仮想化ゲスト上での Windows オペレーティングシステムのインストール方法を説明するものではなく、ゲストの作成方法とゲスト内でインストーラーを起動する方法を説明するものです。Windows オペレーティングシステムのインストール方法については、関連する Microsoft のインストール説明書を参照してください。

9.1. virt-install を使用したゲストの作成

virt-install コマンドを使うと、たとえば GUI を使わずにターミナルから完全仮想化ゲストを作成できます。

重要

ゲストを作成する前に、ゲストが KVM Windows 準仮想化ドライバーを使用する必要があるかどうかをまず検討してください。その必要がある場合は、Windows オペレーティングシステムをゲスト上にインストールしている 最中 または その後 にそれらを使用できることに注意してください。準仮想化ドライバーについてさらに詳しくは、10章KVM 準仮想化 (virtio) ドライバー を参照してください。
KVM Windows 準仮想化ドライバーのインストール方法については、「KVM Windows virtio ドライバーのインストール」 を参照してください。
1 つのコマンドで完全仮想化ゲストを作成することも可能です。以下のプログラムで実行できます (必要に応じて値を変更) 。
# virt-install \
   --name=guest-name \
   --os-type=windows \
   --network network=default \
   --disk path=path-to-disk,size=disk-size \
   --cdrom=path-to-install-disk \
   --graphics spice --ram=1024
path-to-disk はデバイス (例: /dev/sda3) またはイメージファイル (/var/lib/libvirt/images/name.img) である必要があります。さらに、disk-size をサポートできる十分な空き領域も必要になります。

重要

すべてのイメージファイルは、デフォルトで /var/lib/libvirt/images/ に保存されます。ファイルベースのイメージは他のディレクトリーでも保存可能ですが、SELinux 設定が必要な場合もあります。SELinux を強制モードで実行する場合の詳細については、『Red Hat Enterprise Linux 6 仮想化管理ガイド』 を参照してください。
virt-install を対話形式で実行することも可能です。以下のように、 --prompt コマンドを使用します。
# virt-install --prompt
完全仮想化ゲストが作成されると、virt-viewer がゲストを起動し、オペレーティングシステムのインストーラーを実行します。オペレーティングシステムのインストール方法については、関連する Microsoft のインストール説明書を参照してください。

第10章 KVM 準仮想化 (virtio) ドライバー

準仮想化ドライバーはゲストのパフォーマンスを強化し、I/O 待ち時間を短縮すると共に、スループットをベアメタルレベル近くにまで高めます。I/O 負荷の高いタスクとアプリケーションを実行する完全仮想マシンには、準仮想化ドライバーの使用が推奨されます。
virtio ドライバーは、KVM ホスト上で実行中の Windows ゲスト仮想マシンで利用できる KVM の準仮想化デバイスドライバーです。これらのドライバーは、virtio パッケージに含まれています。virtio パッケージは、ブロック (ストレージ) デバイスとネットワークインターフェースコントローラーに対応しています。
KVM virtio ドライバーは、以下のバージョンに自動的にロードされ、インストールされます。
  • Red Hat Enterprise Linux 4.8 およびそれ以降
  • Red Hat Enterprise Linux 5.3 およびそれ以降
  • Red Hat Enterprise Linux 6 およびそれ以降
  • Red Hat Enterprise Linux 7 およびそれ以降
  • 2.6.27 カーネルおよびそれ以降のバージョンをベースとしたいくつかの Linux バージョン
上記リストの Red Hat Enterprise Linux バージョンは、ドライバーを検知してインストールするので、追加のインストールステップは必要ありません。
Red Hat Enterprise Linux 3 (3.9 およびそれ以降) では、手動のインストールが必要になります。

注記

PCI デバイスは、仮想化システムアーキテクチャーによって制限されます。指定デバイスの使用時における新たな制限については、「KVM の制限」 を参照してください。
KVM virtio ドライバーを使用すると、以下の Microsoft Windows バージョンがベアメタルベースのシステムと同様の動作をすることが予想されます。
  • Windows XP Service Pack 3 およびそれ以降 (32 ビットのみ)
  • Windows Server 2003 (32 ビットおよび 64 ビット)
  • Windows Server 2008 (32 ビットおよび 64 ビット)
  • Windows Server 2008 R2 (64 ビットのみ)
  • Windows 7 (32 ビットおよび 64 ビット)
  • Windows Server 2012 (64 ビットのみ)
  • Windows Server 2012 R2 (64 ビットのみ)
  • Windows 8 (32 ビットおよび 64 ビットバージョン)
  • Windows 8.1 (32 ビットおよび 64 ビットバージョン)

10.1. KVM Windows virtio ドライバーのインストール

このセクションでは、KVM Windows virtio ドライバーのインストールプロセスを説明します。KVM virtio ドライバーは、Windows のインストール時にロードしたり、ゲストのインストール後にインストールしたりすることができます。
virtio ドライバーは、以下のいずれかの方法でゲスト仮想マシンにインストールできます。
  • 仮想マシンにアクセス可能なネットワーク上にインストールファイルをホスト
  • ドライバーインストールディスクの .iso ファイルの仮想化 CD-ROM デバイスを使用
  • CD-ROM に使用するのと同じ (指定) .ISO ファイルをマウントして USB ドライブを使用
  • 起動時に仮想化フロッピーデバイスを使用してドライバーをインストール (XP/2003 にのみ必須および推奨)
このガイドでは、仮想化 CD-ROM デバイスとしての準仮想化インストーラーディスクからのインストールについて説明します。
  1. ドライバーのダウンロード

    virtio-win パッケージには、サポート対象のすべての Windows ゲスト仮想マシン用の virtio ブロックおよびネットワークドライバーが含まれます。
    virtio-win パッケージをダウンロードし、ホスト上に yum コマンドでインストールします。
     # yum install virtio-win
    Windows オペレーティングシステム上でサポートされる virtio-win パッケージのリストと現行の認証済みパッケージバージョンは、windowsservercatalog.com で確認できます。
    Red Hat Enterprise Virtualization Hypervisor と Red Hat Enterprise Linux は、同じコードベース上で作成されるので、同じバージョンのドライバー (たとえば、Red Hat Enterprise Virtualization Hypervisor 3.3 と Red Hat Enterprise Linux 6.5) は両方の環境でサポートされます。
    virtio-win パッケージは、/usr/share/virtio-win/ ディレクトリーに CD-ROM イメージである virtio-win.iso をインストールします。
  2. virtio ドライバーのインストール

    virtio-win デバイスを使用する Windows ゲストを起動する場合、関連する virtio-win デバイスドライバーをこのゲストにインストールしておく必要があります。virtio-win ドライバーは Microsoft Windows インストールキットのインボックスドライバーとして提供されていないため、virtio-win ストレージデバイス (viostor/virtio-scsi) に Windows ゲストをインストールするには、インストール に、virtio-win.iso から直接か、または提供される仮想フロッピーイメージ virtio-win<version>.vfd のいずれかにより適切なドライバーを指定する必要があります。

10.2. インストール済みの Windows ゲスト仮想マシンへのドライバーのインストール

ここでは、Windows のインストール後に仮想化 CD-ROM を使用して virtio ドライバーをインストールする方法を説明します。
virt-manager を使って CD-ROM イメージを追加してからドライバーをインストールする方法については、以下の手順にしたがってください。

手順10.1 virt-manager を使用してドライバー CD-ROM イメージからインストールする

  1. virt-manager とゲスト仮想マシンの開始

    virt-manager を開き、ゲスト名をダブルクリックしてゲスト仮想マシンを開きます。
  2. ハードウェアウィンドウを開く

    ウィンドウ最上部のツールバーにある電球のアイコンをクリックして仮想ハードウェアの詳細を表示します。
    The Show virtual hardware details button.

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

    次に、表示される新たなビューの最下部にある ハードウェアを追加 ボタンをクリックします。これにより、新規デバイスを追加するためのウィザードが開きます。
  3. デバイスの種類の選択 — バージョン 6.2 より前の Red Hat Enterprise Linux 6

    Red Hat Enterprise Linux 6.2 またはそれ以降を使用している場合は、このステップを飛ばしてください。
    バージョン 6.2 より前の Red Hat Enterprise Linux 6 では、追加するデバイスの種類を選択する必要があります。このケースでは、ドロップダウンメニューから Storage を選択します。
    The Add new virtual hardware wizard window in Red Hat Enterprise Linux 6.1 with Storage selected as the hardware type.

    図10.2 Red Hat Enterprise Linux 6.1 の新たなハードウェア追加ウィザード

    完了 ボタンをクリックし、次に進みます。
  4. ISO ファイルの選択

    管理しているストレージか、他の既存のストレージを選択する ラジオボタンを選択し、virtio ドライバーの .iso イメージファイルを参照します。デフォルトでは、ドライバーの最新バージョンは、/usr/share/virtio-win/virtio-win.iso にあります。
    デバイスの種類IDE cdrom に変更し、進む ボタンをクリックして次に進みます。
    Selecting the ISO file in the Add new virtual hardware wizard window.

    図10.3 新たなハードウェア追加ウィザード

  5. 仮想ハードウェア追加の完了 — バージョン 6.2 より前の Red Hat Enterprise Linux 6

    Red Hat Enterprise Linux 6.2 またはそれ以降を使用している場合は、このステップを飛ばしてください。
    バージョン 6.2 より前の Red Hat Enterprise Linux 6 では、完了 ボタンをクリックして、仮想ハードウェアの追加ウィザードを終了します。
    The final screen of the Add new virtual hardware wizard in Red Hat Enterprise Linux 6.1.

    図10.4 Red Hat Enterprise Linux 6.1 の新たなハードウェア追加ウィザード

  6. 再起動

    ドライバーディスクを使用して仮想マシンをスタートさせるか、または再起動します。仮想マシンが新たなデバイスを認識するには、仮想化 IDE デバイスの再起動が必要です。
ドライバーの CD-ROM がアタッチされ、仮想マシンが開始したら、手順10.2「Windows 7 仮想マシン上への Windows インストール」 に進みます。

手順10.2 Windows 7 仮想マシン上への Windows インストール

ここでは、例としてドライバーを Windows 7 仮想マシンにインストールします。ご自分の Windows ゲストのバージョンに合わせて Windows のインストール指示にしたがってください。
  1. コンピューターの管理ウィンドウを開く

    Windows 仮想マシンのデスクトップ上で、画面下部にある Windows アイコンをクリックし、スタートメニューを開きます。
    コンピューター を右クリックし、ポップアップメニューから 管理 を選択します。
    A menu window opens on the Computer Management window when right-clicking D the My Computer icon on the desktop.

    図10.5 コンピューターの管理ウィンドウ

  2. デバイスマネージャーを開く

    左端のペインから デバイスマネージャー を選択します。これは、コンピューターの管理 > システムツール にあります。
    Opening the Device Manager on the right hand side of the Computer Management window.

    図10.6 コンピューターの管理ウィンドウ

  3. ドライバーアップデートウィザードの開始

    1. 利用可能なシステムデバイスの表示

      システムデバイス の左にある矢印をクリックして展開します。
      Detail of viewing available system devices from the Computer Management window.

      図10.7 コンピューターの管理ウィンドウで利用可能なシステムデバイスを表示

    2. 適切なデバイスの特定

      最大で以下の 4 種類のドライバーが利用可能です。バルーンドライバー、シリアルドライバー、ネットワークドライバー、ブロックドライバー。
      • Balloon: このバルーンドライバーは システムデバイス グループの PCI 標準 RAM コントローラー に影響します。
      • vioserial: このシリアルドライバーは、システムデバイス グループの PCI シンプル通信コントローラー に影響します。
      • NetKVM: このネットワークドライバーは、ネットワークアダプター グループに影響します。このドライバーは、virtio NIC が設定されている場合のみ利用可能です。このドライバーの設定可能パラメーターは、付録A NetKVM ドライバーパラメーター で説明されています。
      • viostor: このブロックドライバーは、ディスクドライブ グループに影響します。このドライバーは、virtio ディスクが設定されている場合のみ利用可能です。
      アップデートするドライバーのデバイスを右クリックし、ポップアップメニューから ドライバーソフトウェアの更新... を選択します。
      この例ではバルーンドライバーをインストールするので、PCI 標準 RAM コントローラー を右クリックします。
      Locate the appropriate device under the expanded System Devices entry in the Computer Management window.

      図10.8 コンピューターの管理ウィンドウ

    3. ドライバー更新ウィザードの開始

      ドロップダウンメニューから ドライバーソフトウェアの更新... を選択し、ドライバー更新ウィザードにアクセスします。
      Open the driver update wizard by right-clicking the device to be updated and selecting the first menu option, Update Driver Software, in the Computer Management window.

      図10.9 ドライバー更新ウィザードの開始

  4. ドライバーの検索方法の指定

    ドライバー更新ウィザードの最初のページでは、ドライバーソフトウェアの検索方法を聞かれます。2 つ目のオプションのコンピューターを参照してドライバーソフトウェアを検索します をクリックします。
    The driver update wizard provides two options for searching for driver software.

    図10.10 ドライバー更新ウィザード

  5. インストールするドライバーの選択

    1. ファイルのブラウザーを開きます。

      参照... をクリックします。
      The driver update wizard.

      図10.11 ドライバー更新ウィザード

    2. ドライバーの場所を参照

      オペレーティングシステムとアーキテクチャーの組み合わせごとに、別のドライバーが提供されます。ドライバーは以下のように、ドライバータイプ、オペレーティングシステム、インストールされるアーキテクチャーという階層で配置されます。driver_type/os/arch/ 。たとえば、x86 (32 ビット) アーキテクチャーの Windows 7 オペレーティングシステム用バルーンドライバーは、Balloon/w7/x86 ディレクトリーに配置されます。
      The Browse For Folder window, which pops up after choosing "Browse" to search for driver software on your computer. Select the folder that contains drivers for your hardware from this window.

      図10.12 ドライバーソフトウェア参照のポップアップウィンドウ

      正しい場所まで移動したら、OK をクリックします。
    3. 次へ をクリックして続ける

      The Update Driver Software wizard, with the specified location to search for driver software selected, with the Browse button on the right, and the Next and Cancel buttons at the bottom right of the window.

      図10.13 ドライバーソフトウェア更新ウィザード

      ドライバーのインストール中に以下の画面が表示されます。
      As the driver software installs, a flashing bar in the Update Driver Software wizard window shows the system is busy.

      図10.14 ドライバーソフトウェア更新ウィザード

  6. インストーラーを閉じる

    インストールが完了すると、以下の画面が表示されます。
    After the driver software installs, the Update Driver Software wizard window read "Windows has successfully updated your driver software".

    図10.15 ドライバーソフトウェア更新ウィザード

    閉じる ボタンをクリックして、インストーラーを閉じます。
  7. 再起動

    仮想マシンを再起動してドライバーのインストールを完了します。

10.3. Windows インストール中のドライバーのインストール

ここでは、Windows インストール中に virtio ドライバーをインストールする方法を説明します。
この方法では、Windows ゲスト仮想マシンは virtio ドライバーをデフォルトのストレージデバイスに使用できます。

手順10.3 Windows インストール時の virtio ドライバーのインストール

  1. virtio-win パッケージをインストールします。
    # yum install virtio-win
  2. ゲスト仮想マシンの作成

    重要

    仮想マシンを開始せずに、通常どおりに仮想マシンを作成します。以下のいずれかの手順にしたがいます。
    以下のゲスト作成方法のうち、どれか 一つ を選び、指示にしたがいます。
    1. virsh を使ったゲスト仮想マシンの作成

      この方法では、インストール 前に virtio ドライバーフロッピーディスクを Windows ゲストにアタッチします。
      virsh で XML 定義ファイルから仮想マシンが作成された場合、virsh create コマンドではなく、virsh define コマンドを使用してください。
      1. 仮想マシンを作成します。ただし、仮想マシンを開始しないでください。virsh コマンドを使用して仮想マシンを作成する方法についてさらに詳しくは、『Red Hat Enterprise Linux 仮想化管理ガイド』 を参照してください。
      2. virsh コマンドでドライバーディスクを仮想化フロッピーディスクとして追加します。ゲスト仮想マシンに他の仮想化フロッピーディスクがアタッチされていない場合に、この例を適用することができます。vm_name は仮想マシン名と置き換えることに注意してください。
        # virsh attach-disk vm_name /usr/share/virtio-win/virtio-win.vfd fda --type floppy
        ステップ 3 に進みます。
    2. virt-manager を使用してゲスト仮想マシンを作成し、ディスクの種類を変更する

      1. virt-manager ゲスト作成ウィザードの最後のステップで、インストールの前に設定をカスタマイズする チェックボックスにチェックを入れます。
        Step 5 of 5 of creating a new virtual machine with virt-manager, with a checkbox selected under Storage to customize configuration before install.

        図10.16 virt-manager でのゲスト作成ウィザード

        完了 ボタンをクリックし、続けます。
      2. ハードウェア追加ウィザード

        新しいパネルの左下にある ハードウェアを追加 ボタンをクリックします。
      3. ストレージデバイスの選択

        ハードウェアのタイプ のリストでは、ストレージ がデフォルトで選択されています。
        The Add new virtual hardware wizard with Storage selected in the Hardware type field.

        図10.17 新たなハードウェア追加ウィザード

        管理しているストレージか、他の既存のストレージを選択する ラジオボタンを選択します。参照... をクリックします。
        The Add new virtual hardware wizard with Storage selected in the Hardware type field, and the Select managed or other existing storage radio button selected.

        図10.18 管理しているストレージか、他の既存のストレージを選択する

        新しいウィンドウが開くので、ローカルを参照 をクリックします。/usr/share/virtio-win/virtio-win.vfd を選択し、開く をクリックして確定します。
        デバイスの種類Floppy disk に変更し、完了 をクリックして続けます。
        The Device type field, set to Floppy Disk.

        図10.19 デバイスの種類の変更

      4. 設定の確認

        デバイス設定を確認します。
        The virtual machine hardware information window with the target device (Floppy 1) selected.

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

        これで、仮想マシンがアクセス可能なリムーバブルデバイスが作成されました。
      5. ハードディスクの種類の変更

        ハードディスクの種類を IDE Disk から Virtio Disk に変更するには、まず既存のハードディスクである Disk 1 を削除する必要があります。ディスクを選択し、削除 ボタンをクリックします。
        The virtual machine hardware information window with virtual disk Disk 1 selected, with the Remove button available at the bottom right corner of the window.

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

        ハードウェアを追加 をクリックして、新たな仮想ストレージデバイスを追加します。次に、デバイスの種類IDE disk から Virtio Disk に変更します。完了 をクリックして確定します。
        The virtual machine hardware information window with the Floppy 1 target device selected, and the Add Hardware on the left bottom corner of the window.

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

      6. 設定が正しいことの確認

        VirtIO Disk 1 の設定を確認します。
        The virtual machine hardware information window with the Overview option selected, showing Basic Details, Hypervisor Details, plus expandable headings Machine Setting and Security, in the right part of the window.

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

        設定詳細が正しければ、インストールの開始 ボタンをクリックします。
        ステップ 3 に進みます。
    3. virt-install を使ったゲスト仮想マシンの作成

      virt-install コマンドでインストールにドライバーディスクを追加するには、以下のパラメーターをそのまま追加します。
      --disk path=/usr/share/virtio-win/virtio-win.vfd,device=floppy

      重要

      追加したいデバイスが disk の場合 (つまり、floppycdrom でない場合)、--disk パラメーターの最後に bus=virtio オプションを加える必要もあるので、以下のようになります。
      --disk path=/usr/share/virtio-win/virtio-win.vfd,device=disk,bus=virtio
      インストールする Windows のバージョンによって、virt-install コマンドに以下のオプションのいずれかを追加します。
      --os-variant winxp
      --os-variant win2k3
      --os-variant win7
      ステップ 3 に進みます。
  3. ドライバーインストールの追加ステップ

    インストール中に、Windows ゲストの種類によってはドライバーをインストールする追加ステップが必要になります。
    1. Windows Server 2003 および Windows XP

      サードパーティードライバーの場合、インストールのブルースクリーンで F6 を繰り返し押します。
      The Windows pre-installation blue screen reads Window Setup at the top in plain text, and "Press F6 if you need to install a third party SCSI or RAID driver..." at the bottom.

      図10.24 Windows セットアップ画面

      新たなデバイスドライバーをインストールするには、S を押します。
      The next Windows pre-installation blue screen reads Window Setup at the top in plain text and details the option to install an additional device. Options at the bottom of the screen include S to "Specify Additional Device", ENTER to continue, or F3 to exit.

      図10.25 Windows セットアップ画面

      The next Windows blue screen reads Window Setup at the top in plain text and provides options to select the SCSI Adapter to be installed. Options at the bottom of the screen include ENTER to select, or F3 to exit.

      図10.26 Windows セットアップ画面

      Enter を押して、インストールを続行します。
    2. Windows Server 2008

      Windows Server 2003 と同じ手順ですが、インストーラーがドライバーを表示した時には、Load Driver をクリックし、インストーラーを Drive A: に向けて、ご使用のゲストオペレーティングシステムとアーキテクチャーに適切なドライバーを選択します。

10.4. Red Hat Enterprise Linux 3.9 ゲストでの virtio ドライバーの使用

Red Hat Enterprise Linux 3.9 用の virtio ドライバーは、以下の 5 つのカーネルモジュールで構成されています。 virtiovirtio_blkvirtio_netvirtio_pcivirtio_ring。virtio ブロックおよびネットワークデバイスドライバーの両方を使用するには、これら 5 つのモジュールすべてをロードする必要があります。

重要

Red Hat Enterprise Linux 3.9 ゲストでは、kmod-virtio パッケージは virtio モジュールの要件です。

注記

ネットワークデバイスドライバーのみを使用する場合は、virtiovirtio_netvirtio_pci モジュールをロードします。ブロックデバイスドライバーのみを使用する場合は、virtiovirtio_ringvirtio_blkvirtio_pci モジュールをロードします。

重要

virtio パッケージは、/boot ディレクトリーの initrd RAM ディスクファイルを変更します。オリジナルの initrd ファイルは、/boot/initrd-kernel-version.img.virtio.orig に保存されています。オリジナルの initrd ファイルは、virtio ドライバーモジュールを含む新たな initrd RAM ディスクに置換されます。initrd RAM ディスクが変更されると、仮想マシンは virtio ドライバーを使ってストレージデバイスから起動できるようになります。別の initrd ファイルを使うには、ドライバーが sysinit スクリプト (sysinit スクリプトを使用した virtio ドライバーのロード) を使ってロードされているか、または新たな initrd RAM ディスクが作成される (virtio ドライバーを initrd RAM ディスクに追加) 際にロードされていることを確認する必要があります。
sysinit スクリプトを使用した virtio ドライバーのロード

ここでは、Red Hat Enterprise Linux 3.9 以降の起動中に sysinit スクリプトを使用して virtio ドライバーモジュールをロードする方法を説明します。sysinit スクリプトを使用してモジュールがロードされる場合、ゲスト仮想マシンはデフォルト状態の起動ディスクには virtio ドライバーを使用できないことに注意してください。

ドライバーは以下の順序でロードする必要があります。
  1. virtio
  2. virtio_ring
  3. virtio_pci
  4. virtio_blk
  5. virtio_net
virtio_netvirtio_blk の順番のみ、変更が可能です。他のドライバーが異なる順番でロードされると、機能しません。
次にモジュールを設定します。/etc/rc.d/rc.sysinit ファイルの以下のセクションを見つけます。
if [ -f /etc/rc.modules ]; then
   /etc/rc.modules
fi
このセクションに以下の行を追加します。
if [ -f /etc/rc.modules ]; then
  /etc/rc.modules
fi

modprobe virtio
modprobe virtio_ring # Comment this out if you do not need block driver
modprobe virtio_blk  # Comment this out if you do not need block driver
modprobe virtio_net  # Comment this out if you do not need net driver
modprobe virtio_pci
ゲスト仮想マシンを再起動してカーネルモジュールをロードします。
virtio ドライバーを initrd RAM ディスクに追加

ここでは、initrd RAM ディスクに準仮想化モジュールを含めることで Red Hat Enterprise Linux 3.9 以降のカーネルで virtio ドライバーのモジュールをロードする方法を説明します。mkinitrd ツールが initrd RAM ディスクを設定して、モジュールをロードします。追加のモジュールは、mkinitrd コマンドの --with パラメーターで指定します。カスタムの initrd RAM ディスクの作成に mkinitrd コマンドを使用する際は、以下の一連のパラメーターをそのままの順序で追加してください。

--with virtio --with virtio_ring --with virtio_blk --with virtio_net --with virtio_pci
AMD64 および Intel 64 の問題

AMD64 システムには、virtio パッケージの x86_64 バージョンを使用します。

Intel 64 システムには、virtio パッケージの ia32e バージョンを使用します。virtiox86_64 バージョンを使用すると、Intel 64 システム上での起動中に 'Unresolved symbol' エラーが発生する可能性があります。
ネットワークパフォーマンスの問題

virtio ネットワークドライバーを使用していてパフォーマンスが低い場合は、ホストシステムの GSO および TSO 機能の設定を確認します。virtio ネットワークドライバーのパフォーマンスを最適化するには、GSO および TSO オプションが無効になっている必要があります。

ホスト上で以下のコマンドを使用して (interface をゲストが使用するネットワークインターフェースに置換)、GSO と TSO の設定ステータスを確認します。
# ethtool -k interface
ホスト上で以下のコマンドを使用して、GSO と TSO のオプションを無効にします。
# ethtool -K interface gso off
# ethtool -K interface tso off
virtio ドライバーの swap パーティション問題

virtio ブロックデバイスドライバーをアクティベートすると、swap パーティションが利用できない場合があります。この問題は、ディスクデバイス名の変更により発生する可能性があります。この問題を解決するには、/etc/fstab ファイルを開き、以下のような swap パーティションを含む行を見つけます。

/dev/hda3       swap	                swap	defaults	0 0
virtio ドライバーは、/dev/hd* 命名規則ではなく /dev/vd* 命名規則を使用します。この問題を解決するには、/etc/fstab ファイルの誤った swap エントリーを /dev/vd* 規則を使って、以下のように変更します。
/dev/vda3	swap	                swap	defaults	0 0
変更を保存し、ゲスト仮想マシンを再起動します。これで仮想マシンに swap パーティションが作成されました。

10.5. 既存デバイスでの KVM virtio ドライバーの使用

ゲストにアタッチされている既存ハードディスクデバイスを変更して、仮想化 IDE ドライバーの代わりに virtio ドライバーを使用することができます。このセクションの例では、libvirt 設定ファイルを編集します。これらのステップを実行するためにゲスト仮想マシンをシャットダウンする必要はありませんが、変更が適用されるには、ゲストを完全にシャットダウンして再起動する必要があります。

手順10.4 既存デバイスでの KVM virtio ドライバーの使用

  1. この手順を実行する前に、「KVM Windows virtio ドライバーのインストール」 で説明されている適切なドライバー (viostor) がインストールされていることを確認してください。
  2. root で virsh edit <guestname> コマンドを実行し、デバイスの XML 設定ファイルを編集します (例: virsh edit guest1)。設定ファイルは、/etc/libvirt/qemu にあります。
  3. 以下の例は、仮想化 IDE ドライバーを使用したファイルベースのブロックデバイスです。これは、virtio ドライバーを使用しない仮想マシンの通常のエントリーです。
    <disk type='file' device='disk'>
       <source file='/var/lib/libvirt/images/disk1.img'/>
       <target dev='hda' bus='ide'/>
    </disk>
  4. virtio デバイスを使用するために、bus= エントリーを virtio に変更します。ディスクが以前に IDE だった場合は、hda や hdb、hdc などと同様のターゲットを持つことになります。bus=virtio に変更する場合は、ターゲットもそれに応じて vda や vdb、vdc に変更する必要があります。
    <disk type='file' device='disk'>
       <source file='/var/lib/libvirt/images/disk1.img'/>
       <target dev='vda' bus='virtio'/>
    </disk>
  5. disk タグ内の address タグを削除します。これは、この手順を機能させるために必要な作業です。仮想マシンの次回スタート時に、libvirt が address タグを適切に再生成します。
別の方法としては、virtio ドライバーを使用して virt-managervirsh attach-disk、または virsh attach-interface で新規デバイスを追加することもできます。
Virtio 使用方法の詳細については、libvirt の Web サイト http://www.linux-kvm.org/page/Virtio を参照してください。

10.6. KVM virtio ドライバーを使用した新規デバイスの作成

ここでは、KVM virtio ドライバーを使用した virt-manager での新規デバイスの作成について説明します。
別の方法としては、virsh attach-disk または virsh attach-interface コマンドで virtio ドライバーを使用して、デバイスをアタッチすることもできます。

重要

新規デバイスのインストールに進む前に、Windows ゲストにドライバーがインストールされていることを確認してください。ドライバーが利用可能でない場合、デバイスは認識されず、動作しません。

手順10.5 virtio ストレージドライバーを使用してストレージデバイスを追加する

  1. virt-manager でゲスト名をダブルクリックしてゲスト仮想マシンを開きます
  2. 電球 ボタンをクリックして 仮想ハードウェアの詳細表示 タブを開きます。
    仮想ハードウェアの詳細表示タブ

    図10.27 仮想ハードウェアの詳細表示タブ

  3. 仮想ハードウェアの詳細表示 タブで、ハードウェアを追加 ボタンをクリックします。
  4. ハードウェアの種類を選択

    ストレージハードウェアの種類 を選びます。
    The Add new virtual hardware wizard with Storage selected as the hardware type.

    図10.28 新たなハードウェア追加ウィザード

  5. ストレージデバイスとドライバーの選択

    新規ディスクイメージを作成するか、またはストレージプールボリュームを選択します。
    デバイスの種類Virtio disk に設定して virtio ドライバーを使用します。
    The Add new virtual hardware wizard Storage window, with "Create a disk image on the computer's hard drive" selected.

    図10.29 新たなハードウェア追加ウィザード

    完了 をクリックして終了します。

手順10.6 virtio ネットワークドライバーを使用してネットワークデバイスを追加する

  1. virt-manager でゲスト名をダブルクリックしてゲスト仮想マシンを開きます
  2. 電球 ボタンをクリックして 仮想ハードウェアの詳細表示 タブを開きます。
    仮想ハードウェアの詳細表示タブ

    図10.30 仮想ハードウェアの詳細表示タブ

  3. 仮想ハードウェアの詳細表示 タブで、ハードウェアを追加 ボタンをクリックします。
  4. ハードウェアの種類を選択

    ハードウェアの種類ネットワーク を選びます。
    The Add new virtual hardware wizard with Network selected as the hardware type.

    図10.31 新たなハードウェア追加ウィザード

  5. ネットワークデバイスとドライバーの選択

    Device modelvirtio に設定して virtio ドライバーを使用します。必要な ホストデバイス を選択します。
    The Add new virtual hardware wizard Network window, with Device model set to virtio.

    図10.32 新たなハードウェア追加ウィザード

    完了 をクリックして終了します。
すべての新規デバイスが追加されたら、仮想マシンを再起動します。Windows 仮想マシンは再起動するまでデバイスを認識しない可能性があります。

第11章 ネットワークの設定

この章では、libvirt ベースのゲスト仮想マシンが使用する一般的なネットワーク設定について説明します。詳細な情報については、libvirt ネットワークアーキテクチャー資料 (http://libvirt.org/intro.html) を参照してください。
Red Hat Enterprise Linux 6 は以下の仮想化ネットワーク設定に対応しています。
  • Network Address Translation (NAT) を使用した仮想ネットワーク
  • PCI デバイス割り当てを使用して直接割り当てられた物理デバイス
  • PCIe SR-IOV を使用して直接割り当てられた仮想機能
  • ブリッジネットワーク
ゲスト仮想マシン上のネットワークサービスに外部ホストがアクセスするには、NAT またはネットワークブリッジングを有効にするか、または PCI デバイスを直接割り当てる必要があります。

11.1. libvirt による Network Address Translation (NAT)

ネットワーク接続共有の最も一般的な方法の 1 つは、Network Address Translation (NAT) 転送 (別名、仮想ネットワーク) です。
ホスト設定

標準的な libvirt インストールはすべて、デフォルトの仮想ネットワークで仮想マシンへの NAT ベースの接続を提供します。virsh net-list --all コマンドでこれが利用可能であること確認します。

# virsh net-list --all
Name                 State      Autostart 
-----------------------------------------
default              active     yes
存在しない場合は、サンプルのXML 設定ファイルを再度読み込んで、アクティブ化します。
# virsh net-define /usr/share/libvirt/networks/default.xml
デフォルトのネットワークは /usr/share/libvirt/networks/default.xml で定義されています。
デフォルトのネットワークが自動的に開始するようマークします。
# virsh net-autostart default
Network default marked as autostarted
デフォルトのネットワークを開始します。
# virsh net-start default
Network default started
libvirt デフォルトのネットワークが実行されると、分離されたブリッジデバイスがあることが分かります。このデバイスには、物理インターフェースが追加されて いません 。新規デバイスは、NAT および IP 転送を使用して物理ネットワークに接続します。新規インターフェースを追加しないでください。
# brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.000000000000       yes
libvirtiptables ルールを追加します。このルールは、INPUTFORWARDOUTPUTPOSTROUTING チェーンで virbr0 デバイスにアタッチされたゲスト仮想マシンから/へのトラフィックを可能にするものです。次に libvirt は、ip_forward パラメーターの有効化を試みます。一部のアプリケーションが ip_forward を無効にする場合もあるので、/etc/sysctl.conf に以下を追加することが最善の選択肢です。
 net.ipv4.ip_forward = 1
ゲスト仮想マシンの設定

ホスト設定が完了したら、ゲスト仮想マシンはその名前をベースにした仮想ネットワークに接続可能になります。ゲストをデフォルトの仮想ネットワークに接続するには、ゲストの (/etc/libvirtd/qemu/myguest.xml などの) XML 設定ファイルで以下を使用します。

<interface type='network'>
   <source network='default'/>
</interface>

注記

MAC アドレスの定義はオプションです。定義されない場合、MAC アドレスは自動生成され、ネットワークが使用するブリッジデバイスの MAC アドレスとして使用されます。MAC アドレスの手動設定は、ご使用の環境内での一貫性や容易に参照できる状態を維持し、可能性は非常に低いものの競合を回避するのに役立ちます。
<interface type='network'>
  <source network='default'/>
  <mac address='00:16:3e:1a:b3:4a'/>
</interface>

11.2. vhost-net の無効化

vhost-net モジュールは virtio ネットワーキング用のカーネルレベルのバックエンドで、virtio パケット処理タスクをユーザー領域 (qemu プロセス) からカーネル (vhost-net ドライバー) に移すことで仮想化オーバーヘッドを低減します。vhost-net は、virtio ネットワークインターフェースでのみ利用可能です。vhost-net カーネルモジュールがロードされている場合、デフォルトですべての virtio インターフェース用に有効化されています。ただし、vhost-net の使用時に特定のワークロードのパフォーマンスが低下した場合は、インターフェース設定で無効にできます。
具体的には、UDP トラフィックがホストマシンからホスト上のゲスト仮想マシンに送信された場合、ゲスト仮想マシンの着信データ処理速度がホストマシンの送信速度より遅いと、パフォーマンスが低下する可能性があります。この状況で vhost-net を有効にすると、UDP ソケットの受信バッファーをより早くオーバーフローさせることになり、多大なパケットロスにつながります。このため、この状況ではトラフィックを遅らせ、全体のパフォーマンスを上げるために、vhost-net を無効にすることが適切です。
vhost-net を無効にするには、ゲスト仮想マシンの XML 設定ファイルにある <interface> サブ要素を編集し、ネットワークを以下のように定義します。
<interface type="network">
   ...
   <model type="virtio"/>
   <driver name="qemu"/>
   ...
</interface>
ドライバー名を qemu に設定するとパケット処理を qemu ユーザー領域に強制するので、そのインスタンスで vhost-net を事実上無効にします。

11.3. libvirt を使用したブリッジネットワーキング

ブリッジネットワーキング(別名、物理デバイス共有)は、物理デバイスを仮想マシン専用にするために使用します。ブリッジングは多くの場合、高度なセットアップや複数のネットワークインターフェースを持つサーバー上で使用されます。
eth0 インターフェースベースのブリッジ (br0) を作成するには、ホスト上で以下のコマンドを実行します。
# virsh iface-bridge eth0 br0

重要

NetworkManager はブリッジングをサポートしません。ネットワークスクリプト (/etc/sysconfig/network-scripts/ ディレクトリー内にある) でネットワーキングを使用するには、NetworkManager を無効にする必要があります。
# chkconfig NetworkManager off
# chkconfig network on
# service NetworkManager stop
# service network start
NetworkManager を完全に無効にしたくない場合は、"NM_CONTROLLED=no" をブリッジに使用されている ifcfg-* ネットワークスクリプトに追加します。

第12章 PCI デバイス割り当て

Red Hat Enterprise Linux 6 は、以下の 3 つのクラスのデバイスを仮想マシンに公開します。
  • エミュレートされたデバイス は、実際のハードウェアを模倣する純粋の仮想デバイスです。変換されていないゲストオペレーティングシステムは標準のインボックスドライバーを使ってこれらのデバイスと動作できるようになります。
  • Virtio デバイス は、仮想マシン内で最適に動作するように設計された純粋の仮想デバイスです。Virtio デバイスは、エミュレートされたデバイスと似ていますが、Linux 以外の仮想マシンにはこれらデバイスが必要とするドライバーがデフォルトで含まれていません。仮想マシンマネージャー (virt-manager) や Red Hat Enterprise Virtualization Hypervisor といった仮想化管理ソフトウェアは、対応する Linux 以外のゲストオペレーティングシステムにこれらのドライバーを自動的にインストールします。
  • 割り当てデバイス は、仮想マシンに公開されている物理デバイスです。この方法は、「パススルー」とも呼ばれます。デバイス割り当てにより、仮想マシンは幅広いタスクで PCI デバイスへの独占アクセスが可能になり、PCI デバイスはゲストオペレーティングシステムに物理的にアタッチされているかのように表示され、動作することが可能になります。
    デバイス割り当ては、グラフィックスカードを除いて PCI Express デバイス上でサポートされています。パラレル PCI デバイスは割り当てデバイスとしてのサポートが可能ですが、セキュリティーとシステム設定の競合により厳しい制限があります。
Red Hat Enterprise Linux 6 は、仮想マシン 1 台あたり 32 の PCI デバイススロットと、デバイススロット 1 つあたり 8 つの PCI 機能をサポートします。これにより、理論上はゲストあたり最大 256 の設定可能な PCI 機能が提供されることになります。
しかし、この理論上の最大数は以下の制限に影響されます。
  • 仮想マシンがサポートするのは、最大 8 つの割り当てデバイス機能です。
  • 4 つの PCI デバイススロットは、デフォルトで 5 つのエミュレートされたデバイスに設定されています。しかしユーザーは、ゲストオペレーティングシステムの操作に不要な場合、デフォルト設定のエミュレートされたデバイスの内 2 つを明示的に削除できます (スロット 2 のビデオアダプターデバイスと、通常はスロット 3 である一番下にある利用可能なスロットのメモリーバルーンドライバーデバイス)。これにより、ユーザーは仮想マシン 1 台あたり最大 30 の PCI デバイススロット機能のサポートを受けられます。
Red Hat Enterprise Linux 6.0 およびそれ以降は、仮想マシンへの割り当て PCI デバイスのホットプラグをサポートします。しかし、PCI デバイスのホットプラグはスロットレベルで行われていることから、マルチ機能の PCI デバイスをサポートしていません。マルチ機能の PCI デバイスは、静的デバイスの設定にのみ推奨されます。

注記

Red Hat Enterprise Linux 6.0 では、ゲストオペレーティングシステムドライバーによるデバイスの標準および拡張設定領域へのアクセスが制限されていました。Red Hat Enterprise Linux 6.0 での制限は、Red Hat Enterprise Linux 6.1 で大幅に少なくなっており、より大型の PCI Express デバイスのセットが KVM ゲストに正常に割り当てられるようになっています。
セキュアなデバイス割り当ては、割り込み再マッピングのサポートも必要とします。プラットフォームが割り込み再マッピングをサポートしない場合、デバイス割り当ては失敗します。開発環境で割り込み再マッピングのサポートなしにデバイス割り当てを使用するには、allow_unsafe_assigned_interrupts KVM モジュールパラメーターを 1 に設定します。
PCI デバイス割り当ては、Intel VT-d または AMD IOMMU 対応のハードウェアプラットフォーム上でのみ利用可能です。PCI デバイス割り当てが機能するには、Intel VT-d または AMD IOMMU の仕様が BIOS で有効化されている必要があります。

手順12.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 パラメーターを /boot/grub/grub.conf ファイル内のカーネル行に追加します。
    以下の修正例は、grub.conf ファイルで Intel VT-d がアクティブ化されたものです。
    default=0
    timeout=5
    splashimage=(hd0,0)/grub/splash.xpm.gz
    hiddenmenu
    title Red Hat Enterprise Linux Server (2.6.32-330.x86_645)
            root (hd0,0)
            kernel /vmlinuz-2.6.32-330.x86_64 ro root=/dev/VolGroup00/LogVol00 rhgb quiet intel_iommu=on
            initrd /initrd-2.6.32-330.x86_64.img
  3. 準備完了

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

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

  1. AMD IOMMU 仕様の有効化

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

    amd_iommu=on/boot/grub/grub.conf 内のカーネルコマンド行に追加します。これで AMD IOMMU 仕様は起動後に有効になります。
  3. 準備完了

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

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

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

手順12.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 コマンドと grep コマンドを組み合わせて使用し、ホストマシンにアタッチされている特定の種類 (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>
        <capability type='virt_functions'>
        </capability>
      </capability>
    </device>
  3. 必要な設定詳細の決定

    設定ファイルで必要な値については、virsh nodedev-dumpxml pci_0000_00_19_0 コマンドの出力を参照します。
    別の方法では、スロットと機能の値を (10 進法から) 16 進法に変換して PCI bus アドレスを確認します。出力の最初に "0x" を加えることで、コンピューターに値が 16 進法の値であることを知らせます。
    サンプルのデバイスでは、以下の値となっています。bus = 0、slot = 25、function = 0。10 進法の設定では、これらの値を使用します。
    bus='0'
    slot='25'
    function='0'
    10 進法から 16 進法に値を変換したい場合は、以下の例で示すように printf ユーティリティーを使います。
    $ printf %x 0
    0
    $ printf %x 25
    19
    $ printf %x 0
    0
    サンプルのデバイスでは、設定ファイルで以下の 16 進法の値を使います。
    bus='0x0'
    slot='0x19'
    function='0x0'
  4. 設定詳細の追加

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

    SELinux boolean を設定して仮想マシンからの PCI デバイス管理を可能にします。
    # setsebool -P virt_use_sysfs 1
  6. 仮想マシンの開始

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

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

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

手順12.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.

    図12.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.

    図12.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.

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

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

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

手順12.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>
        <capability type='virt_functions'>
        </capability>
      </capability>
    </device>
  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.1-Server-x86_64/os \
    --nonetworks \
    --os-type=linux \
    --os-variant=rhel6 \
    --host-device=pci_0000_01_00_0
  3. インストールの完了

    これでゲストインストールが完了しました。PCI デバイスはゲストにアタッチされています。

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

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

手順12.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
    これでこのデバイスはホストで使用できます。

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

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

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

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

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

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

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

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

第13章 SR-IOV

13.1. はじめに

PCI-SIG (PCI Special Interest Group) が開発したシングルルート I/O 仮想化 (SR-IOV) 仕様は、単一デバイスを複数の仮想マシンで共有できる PCI デバイス割り当てにおける標準です。SR-IOV は、仮想マシンのデバイスパフォーマンスを改善します。
SR-IOV のしくみ

図13.1 SR-IOV のしくみ

SR-IOV は、シングルルート機能 (たとえば、シングルイーサネットポート) を複数の別個の物理デバイスのように見せることができます。SR-IOV 対応の物理デバイスは、PCI 設定領域で複数機能のように見せる設定ができます。各デバイスには、Base Address Registers (BAR) を備えた独自の設定領域があります。
SR-IOV は、以下の 2 つの PCI 機能を使用します。
  • 物理機能 (PF) は、SR-IOV 機能を含む完全な PCIe デバイスです。物理機能は、通常の PCI デバイスとして検出し、管理し、設定されます。物理機能は、仮想機能を割り当てることで SR-IOV の機能性を設定し、管理します。
  • 仮想機能 (VF) は、I/O のみを処理する単純な PCIe 機能です。それぞれの仮想機能は、物理機能に由来しています。デバイス 1 台に備わる仮想機能の数は、デバイスのハードウェアによって制限されます。物理デバイスであるシングルイーサネットポートは、仮想マシンで共有可能な多くの仮想機能を呼び出すことができます。
ハイパーバイザーは 1 つまたはそれ以上の仮想機能を仮想マシンに呼び出すことができます。仮想機能の設定領域は、ゲストに提示された設定領域にマッピングされます。
各仮想機能は実際のハードウェアリソースを必要とするので、一度に 1 つのゲストにしかマッピングできません。仮想マシンは複数の仮想機能を持つことができます。仮想機能は、通常のネットワークカードがオペレーティングシステムに対して表示されるのと同じ方法でネットワークカードとして表示されます。
SR-IOV ドライバーはカーネル内に実装されています。コア実装は PCI サブシステム内に内包されていますが、物理機能 (PF) と仮想機能 (VF) デバイスの両方にもドライバーサポートが必要です。SR-IOV 対応デバイスは、物理機能から仮想機能を割り当てることができます。仮想機能は、キューやレジスターセットなどのリソースで物理 PCI デバイスにバックアップされている PCI デバイスのように表示されます。
SR-IOV の利点

SR-IOV デバイスは、1 つの物理ポートを複数の仮想マシンと共有できます。

仮想機能は、ネイティブに近いパフォーマンスを発揮し、準仮想化ドライバーやエミュレートされたアクセスよりも優れたパフォーマンスを提供します。仮想機能ではデータがハードウェアによって管理および制御されるため、同一の物理サーバー上における仮想マシン間でのデータ保護が提供されます。
これらの機能により、データセンター内でのホスト上の仮想マシン密度は高くなります。
SR-IOV は、複数ゲストとのデバイスの帯域幅を有効活用できます。

13.2. SR-IOV の使用

このセクションでは、SR-IOV 対応のマルチポイントネットワークカードの仮想機能をネットワークデバイスとして仮想マシンに割り当てる、PCI パススルーの使い方を説明します。
virsh edit または virsh attach-device コマンドで <hostdev> 内のデバイスエントリーを追加することにより、SR-IOV 仮想機能を仮想マシンに割り当てられます。しかし、通常のネットワークデバイスと違って SR-IOV VF は永久的な固有の MAC アドレスを持たず、ホストが再起動するたびに新たな MAC アドレスを割り当てられるので、これは問題となります。このため、再起動後にゲストに同じ仮想機能が割り当てられても、ホストが再起動すると、ゲストは新規の MAC アドレスを持つための新たなネットワークアダプターを決定します。その結果、ゲストは毎回新たなハードウェアが接続されたと考え、通常、ゲストのネットワークの再設定を要求することになります。
libvirt-0.9.10 およびそれ以降には、<interface type='hostdev'> インタフェースデバイスが含まれています。このインタフェースデバイスを使って、libvirt は指定されたネットワーク特定のハードウェア/スイッチの初期化をまず行います (MAC アドレスや VLAN タグ、802.1Qbh virtualport パラメーターの設定など)。その後に、ゲストへの PCI デバイス割り当てを実行します。
<interface type='hostdev'> インタフェースデバイスの使用には、以下が必要です。
  • SR-IOV 対応ネットワークカード
  • Intel VT-d または AMD IOMMU 拡張をサポートするホストハードウェア
  • 割り当てられる仮想機能の PCI アドレス

重要

SR-IOV デバイスを仮想マシンに割り当てるには、ホストハードウェアが Intel VT-d または AMD IOMMU 仕様に対応している必要があります。
SR-IOV ネットワークデバイスを Intel または AMD システムにアタッチするには、以下の手順にしたがいます。

手順13.1 SR-IOV ネットワークデバイスを Intel または AMD システムにアタッチする

  1. Intel VT-d または AMD IOMMU 仕様を BIOS およびカーネル内で有効にする

    Intel システムでは、Intel VT-d が有効化されていない場合、BIOS でこれを有効にします。BIOS およびカーネル内での Intel VT-d の有効化に関しては、手順12.1「Intel システムでの PCI デバイス割り当て準備」 を参照してください。
    Intel VT-d が有効化され、機能している場合は、このステップを飛ばしてください。
    AMD システムでは、AMD IOMMU 仕様が有効化されていない場合、BIOS でこれを有効にします。BIOS での IOMMU の有効化に関しては、手順12.2「AMD システムでの PCI デバイス割り当て準備」 を参照してください。
  2. サポートの確認

    SR-IOV 対応の PCI デバイスが検出されるかどうかを確認します。この例では、SR-IOV 対応の Intel 82576 ネットワークインタフェースカードがリストされています。lspci コマンドを使ってデバイスが検出されたかどうかを確認します。
    # lspci
    03:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    03:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    出力が変更されて、他のデバイスがすべて削除されたことに注意してください。
  3. SR-IOV カーネルモジュールの開始

    デバイスが対応していれば、ドライバーカーネルモジュールがカーネルによって自動的にロードされます。オプションのパラメーターは、modprobe コマンドを使ってモジュールに送信できます。Intel 82576 ネットワークインタフェースカードは、igb ドライバーカーネルモジュールを使用します。
    # modprobe igb [<option>=<VAL1>,<VAL2>,]
    # lsmod |grep igb
    igb    87592  0
    dca    6708    1 igb
  4. 仮想機能のアクティブ化

    igb モジュールの max_vfs パラメーターは、最大数の仮想機能を割り当てます。max_vfs パラメーターにより、ドライバーは最大パラメーターの値までの仮想機能を発生させます。このカードでは、有効な範囲は 0 から 7 です。
    モジュールを削除して、変数を変更します。
    # modprobe -r igb
    max_vfs7 またはご使用のデバイスがサポートする最大数の仮想機能数に設定し、モジュールを再起動します。
    # modprobe igb max_vfs=7
  5. 仮想機能に一貫性を持たせる

    /etc/modprobe.d にあるすべてのファイルに options igb max_vfs=7 の行を追加し、仮想機能に一貫性を持たせます。たとえば、以下のようになります。
    # echo "options igb max_vfs=7" >>/etc/modprobe.d/igb.conf
  6. 新たな仮想機能の検証

    lspci コマンドを使用して、Intel 82576 ネットワークデバイスにアタッチされ、新たに追加された仮想機能をリストします (別の方法では、grep を使って Virtual Function、または Virtual Function をサポートするデバイスを検索します。)。
    # lspci | grep 82576
    0b:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    0b:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection(rev 01)
    0b:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:10.1 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:10.2 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:10.3 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:10.4 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:10.5 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:10.6 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:10.7 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:11.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:11.1 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:11.2 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:11.3 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:11.4 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:11.5 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    PCI デバイスの識別子は、lspci コマンドの -n パラメーターで見つけます。物理機能は、0b:00.0 および 0b:00.1 に対応しています。仮想機能にはすべて Virtual Function と記されています。
  7. virsh を使用してデバイスの有無を確認する

    デバイスを仮想マシンに追加する前に、libvirt サービスはそのデバイスを認識する必要があります。libvirt は、lspci の出力に類似した表示を使用します。lspci の出力では、すべての句読点とセミコロン (;) およびピリオド (.) は、アンダースコア (_) に変換されます。
    virsh nodedev-list コマンドと grep コマンドを使って、利用可能なホストデバイスのリストから Intel 82576 ネットワークデバイスを選び出します。この例の 0b は、Intel 82576 ネットワークデバイスのフィルターです。これはお使いのシステムによっても異なり、結果的にデバイスがさらに加わる場合もあります。
    # virsh nodedev-list | grep 0b
    pci_0000_0b_00_0
    pci_0000_0b_00_1
    pci_0000_0b_10_0
    pci_0000_0b_10_1
    pci_0000_0b_10_2
    pci_0000_0b_10_3
    pci_0000_0b_10_4
    pci_0000_0b_10_5
    pci_0000_0b_10_6
    pci_0000_0b_11_7
    pci_0000_0b_11_1
    pci_0000_0b_11_2
    pci_0000_0b_11_3
    pci_0000_0b_11_4
    pci_0000_0b_11_5
    リストには、仮想機能と物理機能のシリアル番号が表示されます。
  8. virsh を使用してデバイスの詳細を確認する

    pci_0000_0b_00_0 は物理機能の 1 つで、pci_0000_0b_10_0 はこの物理機能に対応する最初の仮想機能です。virsh nodedev-dumpxml コマンドを使って、両方のデバイスの詳細な出力を表示します。
    # virsh nodedev-dumpxml pci_0000_0b_00_0
    <device>
       <name>pci_0000_0b_00_0</name>
       <parent>pci_0000_00_01_0</parent>
       <driver>
          <name>igb</name>
       </driver>
       <capability type='pci'>
          <domain>0</domain>
          <bus>11</bus>
          <slot>0</slot>
          <function>0</function>
          <product id='0x10c9'>82576 Gigabit Network Connection</product>
          <vendor id='0x8086'>Intel Corporation</vendor>
       </capability>
    </device>
    # virsh nodedev-dumpxml pci_0000_0b_10_0
    <device>
       <name>pci_0000_0b_10_0</name>
       <parent>pci_0000_00_01_0</parent>
       <driver>
          <name>igbvf</name>
       </driver>
       <capability type='pci'>
          <domain>0</domain>
          <bus>11</bus>
          <slot>16</slot>
          <function>0</function>
          <product id='0x10ca'>82576 Virtual Function</product>
          <vendor id='0x8086'>Intel Corporation</vendor>
       </capability>
    </device>
    この例では、仮想機能 pci_0000_0b_10_0ステップ 9 の仮想マシンに追加します。仮想機能の busslotfunction パラメーターは、デバイスを追加するのに必要になります。
    /tmp/new-interface.xml などの一時 XML ファイルにこれらのパラメーターをコピーします。
       <interface type='hostdev' managed='yes'>
         <source>
           <address type='pci' domain='0' bus='11' slot='16' function='0'/>
         </source>
       </interface>

    注記

    MAC アドレスは、指定されない場合は自動生成されます。<virtualport> 要素は、802.11Qbh ハードウェアスウィッチに接続する場合のみ使用されます。<vlan> 要素は、Red Hat Enterprise Linux 6.4 で初めて導入されたもので、ゲストのデバイスを 42 にタグ付けされた VLAN 上に透過的に配置します。
    仮想マシンは、物理アダプターが提供し、MAC アドレスが設定されたタイプのネットワークデバイスをスタート時に認識します。このMAC アドレスは、ホストおよびゲストが再起動しても変化しません。
    以下の <interface> の例では、<mac address><virtualport><vlan> 要素オプションの構文を表示しています。実際には、<vlan> または <virtualport> を、例のように両方同時にではなく、どちらかを使用します。
    ...
     <devices>
       ...
       <interface type='hostdev' managed='yes'>
         <source>
           <address type='pci' domain='0' bus='11' slot='16' function='0'/>
         </source>
         <mac address='52:54:00:6d:90:02'>
         <vlan>
            <tag id='42'/>
         </vlan>
         <virtualport type='802.1Qbh'>
           <parameters profileid='finance'/>
         </virtualport>
       </interface>
       ...
     </devices>
  9. 仮想機能を仮想マシンに追加する

    上記のステップで作成された一時ファイルで以下のコマンドを使用して、仮想機能を仮想マシンに追加します。これで新規デバイスは即座にアタッチされ、これ以降のゲスト再スタートにも保存されます。
    virsh attach-device MyGuest /tmp/new-interface.xml  --config
    --config オプションを使用すると、これ以降のゲスト再スタート後も新規デバイスが確実に利用可能になります。
仮想マシンが新規ネットワークインタフェースカードを検出します。この新規カードが、SR-IOV デバイスの仮想機能です。

13.3. SR-IOV のトラブルシューティング

このセクションでは、SR-IOV に影響する可能性のある問題の解決方法を説明します。
ゲストスタート時のエラー
設定済みの仮想マシンのスタート時に、以下のようなエラーが発生する場合があります。
# virsh start test
error: Failed to start domain test
error: internal error unable to start guest: char device redirected to
/dev/pts/2
get_real_device: /sys/bus/pci/devices/0000:03:10.0/config: Permission denied
init_assigned_device: Error: Couldn't get real device (03:10.0)!
Failed to initialize assigned device host=03:10.0
このエラーは多くの場合、すでに別のゲストかホスト自体に割り当てられているデバイスが引き起こすものです。
ゲストの移行、保存、ダンプ時のエラー
仮想マシンの移行およびダンプを試行すると、以下のようなエラーが発生する場合があります。
# virsh dump --crash 5 /tmp/vmcore
error: Failed to core dump domain 5 to /tmp/vmcore
error: internal error unable to execute QEMU command 'migrate': An undefined
error has occurred
デバイス割り当ては、仮想マシンがスタートした特定のホスト上のハードウェアを使用するため、デバイス割り当ての使用中は、ゲストの移行および保存がサポートされません。現在は、同様の制限がゲストのコアダンピングにも適用されます。これは将来、変更される可能性があります。

第14章 KVM ゲストのタイミング管理

仮想化では、ゲスト仮想マシンのタイミング管理に内在する各種の課題があります。仮想マシン内の割り込みは実際の割り込みではなく、ホストマシンがゲスト仮想マシンに挿入しているものです。このため、割り込みは常に同時かつ即座に配信できるわけではありません。ホストは別のゲスト仮想マシンを実行していたり、別のプロセスを実行している場合もあり、割り込みに通常必要となる正確なタイミングを得ることが常に可能とは限りません。
セッションの妥当性やマイグレーション、他のネットワークアクティビティーはタイムスタンプに依存して正確性を保持しているため、正確なタイミング管理機能を実行していないゲスト仮想マシンは、ネットワークアプリケーションおよびプロセスに関して問題が発生する可能性があります。
KVM は、ゲスト仮想マシンに準仮想化クロック (kvm-clock) を提供することにより、この問題に対処します。しかし、時間管理が不正確な場合に影響を受ける可能性のあるアクティビティーの前には、時間をテストすることが依然として重要です。

注記

Red Hat Enterprise Linux 5.5 およびそれ以降、また Red Hat Enterprise Linux 6.0 およびそれ以降は、デフォルトのクロックソースに kvm-clock を使用します。kvm-clock なしでこれらを実行するには特別な設定が必要になり、この方法は推奨されません。

重要

ホストとゲスト仮想マシンで、Network Time Protocol (NTP) デーモンが稼働している必要があります。ntpd サービスを有効にしてください。
# service ntpd start
デフォルトの起動シーケンスに ntpd サービスを追加します。
# chkconfig ntpd on
クロックの実行速度と参照クロックソースとの違いが 0.05% 以下であれば、ntpdサービスはクロックスキューの影響を修正します。ntp 起動スクリプトが必要に応じて起動時のシステムクロックを調整することで、参照時間からのクロックのオフセットを調整します。

14.1. 不変タイムスタンプカウンター (TSC)

最新の Intel と AMD の CPU は、不変タイムスタンプカウンター (TSC) を提供します。不変 TSC のカウント頻度は、たとえば CPU コア自体が節電ポリシーに従うために周波数を変更しても変わりません。不変 TSC の周波数を備えた CPU は、KVM ゲストで TSC をクロックソースとして使用するために必要です。
constant_tsc フラグが付いている場合には、CPU は 不変 TSC を搭載しています。CPU に constant_tsc フラグが付いているかどうかを確認するには、以下のコマンドを実行します。
$ cat /proc/cpuinfo | grep constant_tsc
いずれかの出力が表示された場合は、CPU に constant_tsc ビットが搭載されていることになります。出力が全く表示されなかった場合には、以下の手順にしたがってください。

14.1.1. 不変 TSC を搭載していないホストの設定

不変 TSC の周波数のないシステムは、仮想マシンのクロックソースに TSC を使用できず、追加設定が必要になります。電源管理機能により正確な時間管理が妨げられるので、KVM を使用して仮想マシンで正確な時間を管理するには、この機能を無効にする必要があります。

重要

以下に説明する手順は、AMD リビジョン F の CPU のみが対象となります。
CPU に constant_tsc ビットが搭載されていない場合には、電源管理機能をすべて無効にします (BZ#513138)。各システムには、時間管理のためのタイマーが複数あります。TSC は、ホスト上では安定していません。これは、cpufreq の変化やディープ C ステート、より高速な TSC を搭載したホストへの移行などが原因となる場合があります。ディープ C スリープ状態に入ると、TSC が停止する可能性があります。カーネルがディープ C ステートを使用しないようにするには、ホスト上の grub.conf ファイルのカーネルブートオプションに、processor.max_cstate=1 を追記します。
title Red Hat Enterprise Linux (2.6.32-330.x86_64)
        root (hd0,0)
	kernel /vmlinuz-2.6.32-330.x86_64 ro root=/dev/VolGroup00/LogVol00 rhgb quiet \
   processor.max_cstate=1
/etc/sysconfig/cpuspeed 設定ファイルを編集して MIN_SPEEDMAX_SPEED の変数を使用可能な最高の周波数に変更することにより、cpufreq を無効にします (constant_tsc が搭載されていないホストのみ必要)。有効な上限値は、/sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies ファイルに記載されています。

14.2. Red Hat Enterprise Linux ゲストで必要なパラメーター

一部の Red Hat Enterprise Linux ゲスト仮想マシンには、追加のカーネルパラメーターが必要です。これらのパラメーターは、ゲスト仮想マシンの /boot/grub/grub.conf ファイルの /kernel の行の末尾に追記することで設定できます。
以下の表は、Red Hat Enterprise Linux のバージョンと各システムで必要となるパラメーターを表示しています。

表14.1 カーネルパラメーター要件

Red Hat Enterprise Linux バージョンゲストの追加カーネルパラメーター
準仮想化クロック搭載の 6.0 AMD64/Intel 64追加のパラメーターは不要
準仮想化クロックを搭載していない 6.0 AMD64/Intel 64notsc lpj=n
準仮想化クロック搭載の 5.5 AMD64/Intel 64追加のパラメーターは不要
準仮想化クロックを搭載していない 5.5 AMD64/Intel 64notsc lpj=n
準仮想化クロック搭載の 5.5 x86追加のパラメーターは不要
準仮想化クロックを搭載していない 5.5 x86clocksource=acpi_pm lpj=n
5.4 AMD64/Intel 64notsc
5.4 x86clocksource=acpi_pm
5.3 AMD64/Intel 64notsc
5.3 x86clocksource=acpi_pm
4.8 AMD64/Intel 64notsc
4.8 x86clock=pmtmr
3.9 AMD64/Intel 64追加のパラメーターは不要
3.9 x86追加のパラメーターは不要

注記

lpj パラメーターは、ゲスト仮想マシンが稼働する特定の CPU の loops per jiffy 値と同じ数値を必要とします。この値が不明な場合は、lpj パラメーターを設定しないでください。

警告

divider カーネルパラメーターはこれまで、高い即応性要件のない Red Hat Enterprise Linux 4 および 5 ゲスト仮想マシンやゲスト密度の高いシステム上にある Red Hat Enterprise Linux 4 および 5 ゲスト仮想マシンに推奨されていました。今では、Red Hat Enterprise Linux 4 およびバージョン 5.8 より前の Red Hat Enterprise Linux 5 を実行するゲストでのこのカーネルパラメーターの使用は推奨されていません。
Red Hat Enterprise Linux 5 のバージョン 5.8 およびそれ以降において、divider は、タイマー割り込みの頻度を下げることでスループットを改善できます。たとえば、HZ=1000 で、 divider10 に設定されると (つまり、divider=10)、期間ごとのタイマーの割り込み数がデフォルト値 (1000) から 100 (デフォルト値の 1000 ÷ divider 値 10) に変わります。
BZ#698842 では、divider パラメーターによる割り込みや tick recording とのやりとりが記述されています。 このバグは Red Hat Enterprise Linux 5.8 の時点で修正されています。ただし、Red Hat Enterprise Linux 4 またはバージョン 5.8 より前の Red Hat Enterprise Linux 5 バージョンを使用するゲストでは、依然として divider パラメーターによるカーネルパニックが発生する可能性があります。
Red Hat Enterprise Linux 3 の場合にはこのパラメーターが実装されなかったため Red Hat Enterprise Linux 3 のゲストへの影響はありません。
Red Hat Enterprise Linux 6 には割り込み数が固定されたクロック割り込みはありません。ティックレスモード で動作し、必要に応じて動的にタイマーを使用します。したがって、 Red Hat Enterprise Linux 6 では divider パラメーターは不要であり、Red Hat Enterprise Linux 6 のゲストへの影響もありません。

14.3. Windows Server 2003 および Windows XP ゲストでのリアルタイムクロックの使用

Windows は、リアルタイムクロック (RTC) とタイムスタンプカウンター (TSC) の両方を使用します。Windows ゲスト仮想マシンでは、TSC の代わりに RTC をすべてのタイムリソースに対して使用することができます。これによって、ゲストのタイミング問題が解決されます。
PMTIMER クロックソース ( PMTIMER は通常 TSC を使用) に対して RTC を有効にするには、Windows のブート設定に以下のオプションを追加します。Windows のブート設定は、boot.ini ファイルに記載されています。boot.ini ファイルの Window ブート行の最後に以下のオプションを追加してください。
/usepmtimer
Windows のブート構成および usepmtimer オプションに関する詳しい情報は、Windows XP および Windows Server 2003 の Boot.ini ファイルで使用可能なスイッチ オプション を参照してください。

14.4. Windows Server 2008、Windows Server 2008 R2、および Windows 7 ゲストでのリアルタイムクロックの使用

Windows は、リアルタイムクロック (RTC) とタイムスタンプカウンター (TSC) の両方を使用します。Windows ゲスト仮想マシンでは、TSC の代わりに RTC をすべてのタイムリソースに対して使用することができます。これによって、ゲストのタイミング問題が解決されます。
Windows Server 2008 およびそれ以降では、boot.ini ファイルは使用されていません。Windows Server 2008 と Windows Server 2008 R2、Windows 7 では、hypervisor-present ビットが設定されていると、TSC をタイムソースとして使用しません。Red Hat Enterprise Linux 6 KVM ハイパーバイザーは、この CPUID ビットをデフォルトで有効化しているので、Boot Configuration Data Editor (bcdedit.exe) を使用して Windows ブートパラメーターを修正する必要はなくなります。

手順14.1 Windows Server 2008 R2 および Windows 7 ゲストでのリアルタイムクロックの使用

  1. Windows ゲスト仮想マシンを開きます。
  2. スタート メニューの アクセサリ を開きます。コマンドプロンプト を右クリックして、管理者として実行 を選択します。.
  3. セキュリティー例外が出てきた場合は、これを確認します。
  4. ブートマネージャーでプラットホームクロックを使用するように設定します。これで Windows にプライマリークロックソースでの PM タイマーの使用を指示します。システム UUID (以下の例では、{default}) がデフォルトのブートデバイスと異なる場合は、これを変更します。
    C:\Windows\system32>bcdedit /set {default} USEPLATFORMCLOCK on
    The operation completed successfully
この修正で、Windows Server 2008 R2 および Windows 7 のゲストの時間管理が改善されます。Windows 2008 (R2 以外) は USEPLATFORMCLOCK パラメーターをサポートしませんが、デフォルトでリアルタイムクロックをすでに使用しています。

14.5. スチールタイムアカウンティング

スチールタイムは、ゲスト仮想マシンが必要とする CPU 時間の内のホストが提供していない時間です。スチールタイムは、ホストがこれらのリソースを別のゲストなどの他に割り当てる場合に発生します。
スチールタイムは、/proc/stat の CPU 時間フィールドに st としてレポートされます。topvmstat などのユーティリティーが自動でレポートし、スイッチオフにすることはできません。
スチールタイムが多いと CPU 競合を生じさせし、ゲストのパフォーマンス低下につながる可能性があります。CPU 競合を緩和するには、ゲストの CPU 優先度または CPU 割り当てを高めるか、またはホスト上で実行するゲスト数を減らします。

第15章 libvirt を使用したネットワークブート

ゲスト仮想マシンは、PXE が有効な場合に起動できます。PXE により、ゲスト仮想マシンを起動し、ネットワーク自体から設定をロードできるようになります。このセクションでは、libvirt を使って PXE ゲストを設定する基本的なステップを説明します。
このセクションでは、ブートイメージの作成や PXE サーバーについては説明しません。プライベートまたはブリッジネットワークで libvirt を設定し、PXE ブートの有効化でゲスト仮想マシンを起動する方法を説明します。

警告

ここでの手順は、例としてのみ示されています。次に進む前に、十分なバックアップがなされていることを確認してください。

15.1. ブートサーバーの準備

本章のステップを実行するには、以下が必要となります。
  • PXE サーバー (DHCP および TFTP) - これは libvirt 内部サーバー、手動設定の DHCP および TFTP、dnsmasq、Cobbler 設定のサーバーその他のサーバーのいずれでも可能です。
  • ブートイメージ - たとえば、手動設定または Cobbler 設定の PXELINUX

15.1.1. プライベート libvirt ネットワーク上での PXE ブートサーバー設定

この例では デフォルト ネットワークを使用します。以下のステップを実行してください。

手順15.1 PXE ブートサーバーの設定

  1. PXE ブートイメージと設定を /var/lib/tftp に配置します。
  2. 以下のコマンドを実行します。
    # virsh net-destroy default
    # virsh net-edit default
  3. デフォルト ネットワークの設定ファイルで <ip> 要素を編集し、適切なアドレス、ネットワークマスク、DHCP アドレス範囲、およびブートファイルを含めます。BOOT_FILENAME はゲスト仮想マシンの起動に使用するファイル名を示しています。
    <ip address='192.168.122.1' netmask='255.255.255.0'>
       <tftp root='/var/lib/tftp' />
       <dhcp>
          <range start='192.168.122.2' end='192.168.122.254' />
          <bootp file='BOOT_FILENAME' />
       </dhcp>
    </ip>
  4. PXE を使用してゲストを起動します ( 「PXE を使用したゲストの起動」 を参照) 。

15.2. PXE を使用したゲストの起動

このセクションでは、PXE を使用してゲスト仮想マシンを起動する方法を説明します。

15.2.1. ブリッジネットワークの使用

手順15.2 PXE およびブリッジネットワークを使用したゲストの起動

  1. ブリッジングが有効化され、PXE ブートサーバーがネットワーク上で利用可能なことを確認します。
  2. PXE ブートが有効な状態でゲスト仮想マシンを起動します。以下のコマンド例のように、virt-install コマンドで PXE ブートが有効化された新規の仮想マシンを作成することができます。
    virt-install --pxe --network bridge=breth0 --prompt
    別の方法では、ゲストネットワークがブリッジネットワークを使用するように設定され、以下の例のように XML ゲスト設定ファイルの <os> 内に <boot dev='network'/> 要素があることを確認します。
    <os>
       <type arch='x86_64' machine='rhel6.2.0'>hvm</type>
       <boot dev='network'/>
       <boot dev='hd'/>
    </os>
    <interface type='bridge'>       
       <mac address='52:54:00:5a:ad:cb'/>
       <source bridge='breth0'/>     
       <target dev='vnet0'/>
       <alias name='net0'/>
       <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

15.2.2. プライベート libvirt ネットワークの使用

手順15.3 プライベート libvirt ネットワークの使用

  1. 「プライベート libvirt ネットワーク上での PXE ブートサーバー設定」 に示されるように libvirt 上で PXE ブートを設定します。
  2. PXE ブートが有効な状態で libvirt を使用してゲスト仮想マシンを起動します。以下のように、virt-install コマンドを使い、PXE を使用して新規の仮想マシンを作成/インストールすることができます。
    virt-install --pxe --network network=default --prompt
別の方法では、ゲストネットワークがブリッジネットワークを使用するように設定され、以下の例のように XML ゲスト設定ファイルの <os> 内に <boot dev='network'/> 要素があることを確認します。
<os>
   <type arch='x86_64' machine='rhel6.2.0'>hvm</type>
   <boot dev='network'/>         
   <boot dev='hd'/>
</os>
また、ゲスト仮想マシンがプライベートネットワークに接続されていることを確認します。
<interface type='network'>     
   <mac address='52:54:00:66:79:14'/>
   <source network='default'/>      
   <target dev='vnet0'/>
   <alias name='net0'/>
   <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>

第16章 QEMU ゲストエージェント

QEMU ゲストエージェントは、ホストマシンによるゲストオペレーティングシステムへのコマンド発行を可能にします。ゲストオペレーティングシステムはその後、これらのコマンドに非同期的に応答します。
このセクションでは、ゲストが利用できるオプションとコマンドを詳細にわたって説明します。また、フォアグラウンドでゲストエージェントを実行する方法と、バックグラウンドでデーモンとして実行する方法を説明します。

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

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

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

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

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

  1. キャラクターデバイスドライバーで QEMU を起動

    ゲストエージェントとの通信で必要となるキャラクターデバイスドライバーの新たな定義で QEMU を通常の方法で起動します。
    以下の例では QEMU を起動し、 Unix ソケット /tmp/qga.sock で通信します。
    /usr/libexec/qemu-kvm [...] -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 \
                                -device virtio-serial \
                                -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0
  2. ゲストエージェントのスタート

    ゲスト上で以下のコマンドを実行し、ゲストエージェントをスタートします。
    qemu-ga --path device_path --method method
    ゲストエージェントはコマンドの着信 QMP メッセージを解析し、有効であれば実行します。
    --method または --path オプションで他のメソッドやパスが指定されていない場合、ゲストエージェントは /dev/virtio-ports/org.qemu.guest_agent.0 デバイスパスで virtio-serial をリッスンします。
これで確立されたキャラクターデバイスドライバーで有効な QMP コマンドが送信され、ゲストと通信することができます。
ゲストエージェントについてさらに詳しくは、『Red Hat Enterprise Linux 6 仮想化管理ガイド』 を参照してください。

付録A NetKVM ドライバーパラメーター

NetKVM ドライバーは、インストール後にご使用の環境に適合するように設定できます。このセクションにあるパラメーターは、Windows の デバイスマネージャー (devmgmt.msc) で設定できます。

重要

ドライバーのパラメーターを修正すると、Windows はそのドライバーを再ロードします。これにより、既存のネットワークアクティビティーへの割り込みが生じます。

手順A.1 NetKVM パラメーターの設定

  1. デバイスマネージャー を開く

    スタート ボタンをクリックします。右側のペインで コンピューター を右クリックし、管理 をクリックします。要求されたら、ユーザーアカウント制御 ウィンドウの 続行 をクリックします。これで コンピューターの管理 ウィンドウが開きます。
    コンピューターの管理 ウィンドウの左側のペインで、デバイスマネージャー をクリックします。
  2. 正しいデバイスの特定

    コンピューターの管理 ウィンドウの中央のペインで、ネットワークアダプター の横にある + 記号をクリックします。
    Red Hat VirtIO Ethernet Adapter デバイスの下にあるリストで、NetKVM をダブルクリックします。これでそのデバイスの 設定 ウィンドウが開きます。
  3. デバイスパラメーターの表示

    設定 ウィンドウで 詳細 タブをクリックします。
  4. デバイスパラメーターの修正

    修正するパラメーターをクリックし、そのパラメーターのオプションを表示させます。
    オプションを適切に修正し、OK をクリックして変更を保存します。

A.1. 設定可能な NetKVM パラメーター

ロギングパラメーター

Logging.Enable
ロギングが有効かどうかを決定するブール値。デフォルト値は 1 (有効) 。
Logging.Level
ロギングレベルを定義する整数。この整数が増すにつれ、ログの詳細度も増します。デフォルト値は、0 です (エラーのみ) 。1-2 は設定メッセージを追加します。3-4 はパケットフロー情報を追加します。5-6 は割り込みおよび DPC レベル追跡情報を追加します。

重要

高いロギングレベルは、ゲスト仮想マシンのパフォーマンスを低下させます。
Logging.Statistics(sec)
ログ統計が印刷されるかどうか、および各期間の統計印刷の秒単位の間隔を定義する整数。デフォルト値は、0 (ロギング統計なし)。

初期パラメーター

Assign MAC
準仮想化 NIC 用にローカルで管理された MAC アドレスを定義するストリング。デフォルトでは設定されていません。
Init.ConnectionRate(Mb)
接続率をメガバイトで表示する整数。Windows 2008 およびそれ以降のデフォルト値は 10000
Init.Do802.1PQ
Priority/VLAN タグ取り込みおよび削除サポートを有効化するブール値。デフォルト値は 1 (有効) 。
Init.UseMergedBuffers
マージ可能な RX バッファーを有効化するブール値。デフォルト値は 1 (有効) 。
Init.UsePublishEvents
公開されたイベント使用を有効化するブール値。デフォルト値は 1 (有効) 。
Init.MTUSize
maximum transmission unit (MTU) を定義する整数。デフォルト値は 1500。500 から 65500 の間の値であれば使用可能。
Init.IndirectTx
間接的なリング記述子の使用を制御。デフォルト値は Disable で、これは間接的なリング記述子の使用を無効にします。他の有効な値は Enable で、これは間接的なリング記述子の使用を可能にします。また、Enable* は、間接的なリング記述子の条件付き使用を可能にします。
Init.MaxTxBuffers
割り当てられる TX リング記述子の量を表示する整数。デフォルト値は、1024。有効な値は、16、32、64、128、256、512、1024 のいずれか。
Init.MaxRxBuffers
割り当てられる RX リング記述子の量を表示する整数。デフォルト値は、256。有効な値は、16、32、64、128、256、512、1024 のいずれか。
Offload.Tx.Checksum
TX チェックサムオフロードモードを指定。
Red Hat Enterprise Linux 6.4 およびそれ以降でのこのパラメーターの有効値は以下の通りです。All (デフォルト): IPv4 と IPv6 の両方で IP、TCP、UDP のチェックサムオフロードを有効にします。TCP/UDP(v4,v6): IPv4 と IPv6 の両方で TCP と UDP のチェックサムオフロードを有効にします。TCP/UDP(v4): IPv4 のみで TCP と UDP のチェックサムオフロードを有効にします。TCP(v4): IPv4 のみで TCP のチェックサムオフロードだけを有効にします。
Red Hat Enterprise Linux 6.3 およびそれ以前でのこのパラメーターの有効値は以下の通りです。TCP/UDP (デフォルト値): TCP と UDP のチェックサムオフロードを有効にします。TCP: TCP のチェックサムオフロードのみを有効にします。Disable: TX チェックサムオフロードを無効にします。
Offload.Tx.LSO
TX TCP Large Segment Offload (LSO) を有効にするブール値。デフォルト値は 1 (有効)。
Offload.Rx.Checksum
RX チェックサムオフロードモードを指定
Red Hat Enterprise Linux 6.4 およびそれ以降でのこのパラメーターの有効値は以下の通りです。All (デフォルト): IPv4 と IPv6 の両方で IP、TCP、UDP のチェックサムオフロードを有効にします。TCP/UDP(v4,v6): IPv4 と IPv6 の両方で TCP と UDP のチェックサムオフロードを有効にします。TCP/UDP(v4): IPv4 のみで TCP と UDP のチェックサムオフロードを有効にします。TCP(v4): IPv4 のみで TCP のチェックサムオフロードだけを有効にします。
Red Hat Enterprise Linux 6.3 およびそれ以前での有効値は以下の通りです。Disable (デフォルト値): RX チェックサムオフロードを無効にします。All: IP、TCP、UDP のチェックサムオフロードを有効にします。TCP/UDP: TCP と UDP のチェックサムオフロードを有効にします。TCP: TCP のチェックサムオフロードのみを有効にします。

テストおよびデバッグパラメーター

重要

テストおよびデバッグパラメーターは、テストまたはデバッグのみに使用することをお勧めします。本番環境での使用は推奨されません。
TestOnly.DelayConnect(ms)
スタート時に接続を遅らせる時間 (ミリ秒単位)。デフォルト値は、0
TestOnly.DPCChecking
DPC 確認モードを設定。0 (デフォルト値) は DPC 確認を無効にします。1 は DPC 確認を有効にします。各ハングテストは DPC アクティビティーを検証し、DPC が作成されたかのように行動します。2 は、デバイス割り込みステータスを消去するほかは、1 と同じです。
TestOnly.Scatter-Gather
スキャッター/ギャザー機能が有効かどうかを判断するブール値。デフォルト値は 1 (有効)。この値を 0 に設定すると、スキャッター/ギャザー機能とすべての依存機能が無効になります。
TestOnly.InterruptRecovery
割り込み回復が有効かどうかを決定するブール値。デフォルト値は 1 (有効)。
TestOnly.PacketFilter
パケットフィルタリングが有効かどうかを決定するブール値。デフォルト値は 1 (有効)。
TestOnly.BatchReceive
パケットがバッチかまたは 1 回で受信されたかを決定するブール値。デフォルト値は 1 で、パケットのバッチ受信が有効。
TestOnly.Promiscuous
プロミスキャスモードが有効かどうかを決定するブール値。デフォルト値は 0 (無効)。
TestOnly.AnalyzeIPPackets
送信 IP パケットのチェックサムフィールドがデバッグ目的でテストされ、検証されたかどうかを決定するブール値。デフォルト値は 0 (確認なし)。
TestOnly.RXThrottle
単一 DPC で処理される受信パケット数を決定する整数。デフォルト値は、1000
TestOnly.UseSwTxChecksum
ハードウェアチェックサムが有効かどうかを決定するブール値。デフォルト値は 0 (無効)。

付録B 一般的な libvirt エラーおよびトラブルシューティング

この付録では、libvirt 関連の一般的な問題とエラーおよびそれらの対処法について説明します。
以下の表でエラーを特定し、Solution (解決法) の対応するリンク先で詳細なトラブルシューティング情報を参照してください。

表B.1 一般的な libvirt エラー

エラー問題の概要解決法
libvirtd failed to startlibvirt デーモンがスタートに失敗するが、/var/log/messages にはこのエラーに関する情報がない。libvirtd がスタート失敗」
Cannot read CA certificateURI がハイパーバイザー接続に失敗する際に発生するエラーの 1 つです。「URI がハイパーバイザー接続に失敗する」
Failed to connect socket ... : Permission deniedURI がハイパーバイザー接続に失敗する際に発生するエラーの 1 つです。「URI がハイパーバイザー接続に失敗する」
他の接続エラーURI がハイパーバイザー接続に失敗する際に発生するその他のエラーです。「URI がハイパーバイザー接続に失敗する」
Internal error guest CPU is not compatible with host CPUホストとゲストのプロセッサーが異なるため、ゲスト仮想マシンがスタートできない。「ゲスト仮想マシンがスタートできずエラーが発生: internal error guest CPU is not compatible with host CPU
Failed to create domain from vm.xml error: monitor socket did not show up.: Connection refusedゲスト仮想マシン (またはドメイン) がスタートに失敗し、このエラーまたは同様のエラーを返す。「ゲストがスタートに失敗しエラーが発生: monitor socket did not show up
Internal error cannot find character device (null)このエラーは、ゲストのコンソールに接続しようとする際に発生します。ゲスト仮想マシン用に設定されたシリアルコンソールがない、とレポートされます。Internal error cannot find character device (null)
No boot device既存のディスクイメージからゲスト仮想マシンを構築した後、ゲストの起動がストールするが、QEMU コマンドを直接使うとゲストは正常にスタートできる。「ゲスト仮想マシンの起動がストールしエラーが発生: No boot device
The virtual network "default" has not been started
default ネットワーク (またはローカル作成された別のネットワーク) がスタートできないと、そのネットワークを接続に使用するように設定されたすべての仮想マシンもスタートに失敗する。
「Virtual network default has not been started」
ゲスト上の PXE ブート (または DHCP ) が失敗ゲスト仮想マシンは正常にスタートするが、DHCP から IP アドレスを取得できない、または PXE を使用したブートができない、もしくはその両方。この原因は多くの場合、ブリッジでの転送遅延時間が長く設定されているか、iptables パッケージとカーネルがチェックサム難号化ルールをサポートしないためです。「ゲスト上の PXE ブート (または DHCP ) が失敗」
ゲストは外部ネットワークにアクセスできるが、macvtap インターフェースの使用時にはホストにアクセスできない
ゲストは他のゲストと通信できるが、macvtap (または type='direct') ネットワークインターフェース使用の設定後にはホストに接続できない。
この状況は、実際にはエラーではなく macvtap の定義済み動作です。
「ゲストは外部ネットワークにアクセスできるが、macvtap 使用時にはホストにアクセスできない」
Could not add rule to fixup DHCP response checksums on network 'default'この警告メッセージはほとんどの場合、無害ですが、間違って問題の証拠と見なされることが多くあります。「Could not add rule to fixup DHCP response checksums on network 'default'
Unable to add bridge br0 port vnet0: No such deviceこのエラーメッセージと、同様の Failed to add tap interface to bridge 'br0': No such device というメッセージは、ゲストの (またはドメインの) <interface> 定義で指定されたブリッジデバイスが存在しないことを示しています。「Unable to add bridge br0 port vnet0: No such device」
Warning: could not open /dev/net/tun: no virtual network emulation qemu-kvm: -netdev tap,script=/etc/my-qemu-ifup,id=hostnet0: Device 'tap' could not be initializedホストシステムの type='ethernet' (別名、ジェネリックイーサネット) インターフェースの設定後にゲスト仮想マシンがスタートしない。このエラーまたは同様のエラーが libvirtd.log または /var/log/libvirt/qemu/name_of_guest.log のどちらか、または両方に表示される。「ゲストがスタートできずエラーが発生: warning: could not open /dev/net/tun
Unable to resolve address name_of_host service '49155': Name or service not knownQEMU ゲストマイグレーションが失敗し、このエラーメッセージが知らないホスト名とともに表示される。「マイグレーションに失敗しエラーが発生 Error: unable to resolve address
Unable to allow access for disk path /var/lib/libvirt/images/qemu.img: No such file or directorylibvirt がディスクイメージにアクセスできないため、ゲスト仮想マシンを移行できない。「マイグレーションに失敗しエラーが発生: Unable to allow access for disk path: No such file or directory
libvirtd のスタート時にゲスト仮想マシンがないlibvirt デーモンは正常にスタートしたが、virsh list --all を実行してもゲスト仮想マシンが見当たらないlibvirtd のスタート時にゲスト仮想マシンが見当たらない」
Unable to connect to server at 'host:16509': Connection refused ... error: failed to connect to the hypervisorlibvirtd が接続のために TCP ポートをリッスンしている間に、ハイパーバイザーへの接続が失敗する。「Unable to connect to server at 'host:16509': Connection refused ... error: failed to connect to the hypervisor」
一般的な XML エラーlibvirt は XML ドキュメントを使用して構造化データを保存します。XML ドキュメントのエラーのいくつかは、XML ドキュメントが API で libvirt に渡される際に発生します。このエントリーでは、ゲスト XML 定義の編集に関する指示と、XML 構文および設定における一般的なエラーの詳細を提供します。「一般的な XML エラー」

B.1. libvirtd がスタート失敗

現象
libvirt デーモンが自動的にスタートしない。手動での libvirt デーモンのスタートも失敗
# /etc/init.d/libvirtd start
* Caching service dependencies ...                                                                                             [ ok ]
* Starting libvirtd ...
/usr/sbin/libvirtd: error: Unable to initialize network sockets. Check /var/log/messages or run without --daemon for more info.
* start-stop-daemon: failed to start `/usr/sbin/libvirtd'                                                                      [ !! ]
* ERROR: libvirtd failed to start
さらには、/var/log/messages にこのエラーの 'more info' もない。
調査
以下の行でコメントを解除し、/etc/libvirt/libvirtd.conflibvirt のロギングを変更します。コメントを解除するには、テキストエディターで /etc/libvirt/libvirtd.conf ファイルを開き、以下の行の先頭からハッシュ (または #) 記号を削除して、変更を保存します。
log_outputs="3:syslog:libvirtd"

注記

この行は、libvirt が過剰なログメッセージを作成しないように、デフォルトではコメントアウトされています。問題の診断後には、/etc/libvirt/libvirtd.conf ファイルでこの行を再度コメント化することが推奨されます。
libvirt を再起動し、問題が解決されたか確認します。
libvirtd がまだ正常にスタートしない場合、/var/log/messages ファイルに以下と同様のエラーが表示されます。
Feb  6 17:22:09 bart libvirtd: 17576: info : libvirt version: 0.9.9
Feb  6 17:22:09 bart libvirtd: 17576: error : virNetTLSContextCheckCertFile:92: Cannot read CA certificate '/etc/pki/CA/cacert.pem': No such file or directory
Feb  6 17:22:09 bart /etc/init.d/libvirtd[17573]: start-stop-daemon: failed to start `/usr/sbin/libvirtd'
Feb  6 17:22:09 bart /etc/init.d/libvirtd[17565]: ERROR: libvirtd failed to start
libvirtd man ページには、libvirtListen for TCP/IP connections モードで実行された際に、見つからない cacert.pem ファイルが TLS 認証として使用されたことが示されています。つまり、--listen パラメーターが渡されています。
解決法
libvirt デーモンを以下のいずれかの方法で設定します。
  • CA 証明書をインストールする。

    注記

    CA 証明書およびシステム認証の設定に関する詳細は、『Red Hat Enterprise Linux 6 導入ガイド』 の認証の設定の章を参照して下さい。
  • TLS を使わずにベア TCP を使用する。/etc/libvirt/libvirtd.conflisten_tls = 0listen_tcp = 1 に設定する。デフォルト値は、listen_tls = 1listen_tcp = 0
  • --listen パラメーターを渡さない。/etc/sysconfig/libvirtd.confLIBVIRTD_ARGS 変数を変更する。

B.2. URI がハイパーバイザー接続に失敗する

サーバー接続時にいくつかの異なるエラーが発生する (たとえば、virsh 実行時)。

B.2.1. CA 証明書を読み込めない

現象
コマンド実行中に、以下のエラー (または同様のエラー) が表示される。
$ virsh -c name_of_uri list
error: Cannot read CA certificate '/etc/pki/CA/cacert.pem': No such file or directory
error: failed to connect to the hypervisor
調査
このエラーメッセージは、実際の原因に関して誤解を招くものです。このエラーは、誤って指定された URI や未設定の接続など様々な要素によって起こり得ます。
解決法
誤って指定された URI
qemu://system または qemu://session を接続 URI として指定すると、virsh はそれぞれのホスト名 system または session に接続しようとします。これは、virsh が 2 つ目のスラッシュの後のテキストをホストとして認識するためです。
スラッシュを 3 つ使ってローカルホストに接続します。たとえば、qemu:///system を指定すると、ローカルホスト上で libvirtdsystem インスタンスに接続するようvirsh に指示します。
ホスト名が指定されていると、QEMU トランスポートがデフォルトで TLS を選択します。これで証明書が作成されます。
接続が未設定
URI は正しい (たとえば、qemu[+tls]://server/system) が、マシン上で証明書が正しく設定されていない。TLS の設定に関する詳細は、libvirt の Web サイトの Setting up libvirt for TLS を参照してください。

B.2.2. Failed to connect socket ... : Permission denied

現象
virsh コマンドの実行中に、以下のエラー (または同様のエラー) が表示される。
$ virsh -c qemu:///system list
error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied
error: failed to connect to the hypervisor
調査
ホスト名が指定されていないと、QEMU への接続にはデフォルトで UNIX ソケットが使用されます。root でこのコマンド実行時にエラーが発生しない場合、/etc/libvirt/libvirtd.conf のUNIX ソケットオプションの設定が間違っている可能性があります。
解決法
root 以外のユーザーで UNIX ソケットを使用して接続するには、/etc/libvirt/libvirtd.conf で以下のオプションを設定します。
unix_sock_group = <group>
unix_sock_ro_perms = <perms>
unix_sock_rw_perms = <perms>

注記

virsh を実行するユーザーは、unix_sock_group オプションで指定された group のメンバーである必要があります。

B.2.3. 他の接続エラー

Unable to connect to server at server:port: Connection refused
デーモンがサーバー上で動作していないか、listen_tcp または listen_tls 設定オプションを使用していて、リッスンしないように設定されている。
End of file while reading data: nc: using stream socket: Input/output error
ssh トランスポートが指定されている場合、デーモンはサーバー上で動作していない可能性があります。デーモンがサーバー上で実行しているかどうかを確認して、このエラーを解消します。

B.3. ゲスト仮想マシンがスタートできずエラーが発生: internal error guest CPU is not compatible with host CPU

現象
Intel Core i7 プロセッサー (virt-managerNehalem として参照。または以前の Core 2 Duo の場合は Penryn として参照) 上で動作する KVM ゲスト (またはドメイン) は、virt-manager を使用して作成されます。インストール後に、ゲストのプロセッサーはホストの CPU に適合するように変更されます。その後ゲストはスタートできず、以下のエラーメッセージを表示します。
2012-02-06 17:49:15.985+0000: 20757: error : qemuBuildCpuArgStr:3565 : internal error guest CPU is not compatible with host CPU
さらに、virt-managerCopy host CPU configuration をクリックすると、NehalemPenryn ではなく、Pentium III が表示されます。
調査
/usr/share/libvirt/cpu_map.xml ファイルは、各 CPU モデルを定義するフラグをリスト表示します。Nehalem および Penryn の定義には、以下が含まれます。
<feature name='nx'/>
その結果、CPU を Nehalem または Penryn として特定するには、NX (または No eXecute) フラグを提示する必要があります。しかし、/proc/cpuinfo にはこのフラグがありません。
解決法
ほとんどすべての新規 BIOSes では、No eXecute ビットの有効化や無効化が可能です。しかし、無効にされている場合、このフラグをレポートしない CPU もあり、そのため libvirt は別の CPU を検出します。この機能を有効にすると、libvirt に対し、正しい CPU をレポートするように指示します。この問題の詳細な指示に関しては、ご使用のハードウェアの資料を参照してください。

B.4. ゲストがスタートに失敗しエラーが発生: monitor socket did not show up

現象
ゲスト仮想マシン (またはドメイン) がスタートに失敗し、以下のエラーメッセージが表示される。
# virsh -c qemu:///system create name_of_guest.xml error: Failed to create domain from name_of_guest.xml error: monitor socket did not show up.: Connection refused
調査
このエラーメッセージが示しているのは、以下の点です。
  1. libvirt は動作している
  2. QEMU プロセスはスタートに失敗した
  3. libvirtQEMU または QEMU エージェントモニターソケットに接続しようとした際に終了した
エラーの詳細を理解するために、ゲストログを検証します。
# cat /var/log/libvirt/qemu/name_of_guest.log
LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -S -M pc -enable-kvm -m 768 -smp 1,sockets=1,cores=1,threads=1 -name name_of_guest -uuid ebfaadbe-e908-ba92-fdb8-3fa2db557a42 -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/name_of_guest.monitor,server,nowait -mon chardev=monitor,mode=readline -no-reboot -boot c -kernel /var/lib/libvirt/boot/vmlinuz -initrd /var/lib/libvirt/boot/initrd.img -append method=http://www.example.com/pub/product/release/version/x86_64/os/ -drive file=/var/lib/libvirt/images/name_of_guest.img,if=none,id=drive-ide0-0-0,boot=on -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -device virtio-net-pci,vlan=0,id=net0,mac=52:40:00:f4:f1:0a,bus=pci.0,addr=0x4 -net tap,fd=42,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -vnc 127.0.0.1:0 -k en-gb -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,
addr=0x3 
char device redirected to /dev/pts/1
qemu: could not load kernel '/var/lib/libvirt/boot/vmlinuz':
Permission denied
解決法
ゲストログには、エラーの修正に必要な詳細が含まれています。
ゲストが libvirt の 0.9.5 以前のバージョンを実行中にホストがシャットダウンした場合、libvirt ゲストの init スクリプトはゲストの管理保存を実行しようとします。管理保存が不完全な場合 (たとえば、管理保存イメージがディスクにフラッシュされる前に電源を喪失するなど)、保存イメージは破損し、QEMU はロードしません。古いバージョンの libvirt は破損を認識せず、問題は永続化します。このケースでは、ゲストログには -incoming の使用を試みたことが引数の 1 つとして表示されます。これは、libvirt が保存状態のファイル内で移行することで QEMU のスタートを試みていることを意味します。
この問題は、virsh managedsave-remove name_of_guest を実行して破損した管理保存イメージを削除することで修正できます。新しいバージョンの libvirt は、最初の段階で破損を回避するステップを取り、virsh start --force-boot name_of_guest を追加して管理保存イメージも迂回します。

B.5. Internal error cannot find character device (null)

現象
ゲスト仮想マシンのコンソールに接続を試みる際にこのエラーメッセージが表示されます。
# virsh console test2 Connected to domain test2 Escape character is ^] error: internal error cannot find character device (null)
調査
このエラーメッセージは、ゲスト仮想マシン用に設定されたシリアルコンソールがないことを示しています。
解決法
ゲストの XML ファイル内でシリアルコンソールを設定します。

手順B.1 ゲストの XML ファイル内でのシリアルコンソール設定

  1. virsh edit を使用して、以下の XML をゲストの仮想マシンの XML に追加します。
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
  2. ゲストのカーネルコマンドラインにコンソールを設定します。
    これを行うには、ゲスト仮想マシンにログインして /boot/grub/grub.conf ファイルを直接編集するか、または virt-edit コマンドラインツールを使用します。ゲストのカーネルコマンドラインに以下を追加します。
    console=ttyS0,115200
  3. 以下のコマンドを実行します。
    # virsh start vm && virsh console vm

B.6. ゲスト仮想マシンの起動がストールしエラーが発生: No boot device

現象
既存のディスクイメージからゲスト仮想マシンを作成した後、ゲストの起動がストールし、エラーメッセージ No boot device が表示される。ただし、QEMU コマンドを直接使うとゲスト仮想マシンは正常にスタートする。
調査
既存ディスクイメージをインポートするコマンドでディスクのバスの種類が指定されていない。
# virt-install \
--connect qemu:///system \
--ram 2048 -n rhel_64 \
--os-type=linux --os-variant=rhel5 \
--disk  path=/root/RHEL-Server-5.8-64-virtio.qcow2,device=disk,format=qcow2 \
--vcpus=2 --graphics spice --noautoconsole --import
しかし、QEMU を直接使用してゲスト仮想マシンを起動したコマンドラインではバスの種類に virtio を使用したことを示している
# ps -ef | grep qemu
/usr/libexec/qemu-kvm -monitor stdio -drive file=/root/RHEL-Server-5.8-32-virtio.qcow2,index=0,if=virtio,media=disk,cache=none,format=qcow2 -net nic,vlan=0,model=rtl8139,macaddr=00:30:91:aa:04:74 -net tap,vlan=0,script=/etc/qemu-ifup,downscript=no -m 2048 -smp 2,cores=1,threads=1,sockets=2 -cpu qemu64,+sse2 -soundhw ac97 -rtc-td-hack -M rhel5.6.0 -usbdevice tablet -vnc :10 -boot c -no-kvm-pit-reinjection
インポートされたゲスト用に libvirt が生成した bus= がゲストの XMLにあることに注意。
<domain type='qemu'>
 <name>rhel_64</name>
 <uuid>6cd34d52-59e3-5a42-29e4-1d173759f3e7</uuid>
 <memory>2097152</memory>
 <currentMemory>2097152</currentMemory>
 <vcpu>2</vcpu>
 <os>
   <type arch='x86_64' machine='rhel5.4.0'>hvm</type>
   <boot dev='hd'/>
 </os>
 <features>
   <acpi/>
   <apic/>
   <pae/>
 </features>
 <clock offset='utc'>
   <timer name='pit' tickpolicy='delay'/>
 </clock>
 <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='qcow2' cache='none'/>
     <source file='/root/RHEL-Server-5.8-64-virtio.qcow2'/>
     <emphasis role="bold"><target dev='hda' bus='ide'/></emphasis>
     <address type='drive' controller='0' bus='0' unit='0'/>
   </disk>
   <controller type='ide' index='0'/>
   <interface type='bridge'>
     <mac address='54:52:00:08:3e:8c'/>
     <source bridge='br0'/>
   </interface>
   <serial type='pty'>
     <target port='0'/>
   </serial>
   <console type='pty'>
     <target port='0'/>
   </console>
   <input type='mouse' bus='ps2'/>
   <graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/>
   <video>
     <model type='cirrus' vram='9216' heads='1'/>
   </video>
 </devices>
 </domain>
ディスクのバスの種類は ide に設定されており、これは libvirt によって設定されるデフォルト値です。これは間違ったバスの種類で、インポートされたゲストが正常に起動できない原因となっています。
解決法

手順B.2 ディスクのバスの種類の訂正

  1. インポートされたゲストの定義を解除し、以下のように bus=virtio を使って再度インポートします。
    # virsh destroy rhel_64
    # virsh undefine rhel_64
    # virt-install \
    --connect qemu:///system \
    --ram 1024 -n rhel_64 -r 2048 \
    --os-type=linux --os-variant=rhel5  \
    --disk path=/root/RHEL-Server-5.8-64-virtio.qcow2,device=disk,bus=virtio,format=qcow2 \ 
    --vcpus=2 --graphics spice --noautoconsole --import
  2. virsh edit を使ってインポートされてゲストの XML を編集し、ディスクのバスの種類を訂正します。

B.7. Virtual network default has not been started

現象
通常、libvirt パッケージの一部として default 名で仮想ネットワークの設定がインストールされており、libvirtd のスタート時に自動スタートするように設定されています。
default ネットワーク (またはローカルで作成されたネットワーク) がスタートできない場合、接続にそのネットワークを使うように接続されている仮想マシンもスタートに失敗し、以下のエラーメッセージが表示されます。
Virtual network default has not been started
調査
libvirt 仮想ネットワークのスタート失敗でよくある理由の 1 つは、そのネットワーク上でクライアントからの DHCP および DNS リクエストに応えるために必要な dnsmasq インスタンスがスタートに失敗するケースです。
これが理由であることを確かめるには、root シェルから virsh net-start default を実行し、default 仮想ネットワークをスタートします。
この方法で仮想ネットワークが正常にスタートしない場合、/var/log/libvirt/libvirtd.log を開いて詳細なエラーログメッセージを表示します。
以下と同様のメッセージが表示される場合、問題は libvirt のブリッジ上ですでにリッスンしているシステムワイドの dnsmasq インスタンスである可能性が高いと言えます。このインスタンスは、libvirt の dnsmasq イスタンスがリッスンすることを妨げています。エラーメッセージで最も注目すべき点は、dnsmasqexit status 2 です。
Could not start virtual network default: internal error
Child process (/usr/sbin/dnsmasq --strict-order --bind-interfaces
--pid-file=/var/run/libvirt/network/default.pid --conf-file=
--except-interface lo --listen-address 192.168.122.1
--dhcp-range 192.168.122.2,192.168.122.254
--dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases
--dhcp-lease-max=253 --dhcp-no-override) status unexpected: exit status 2
解決法
物理ネットワークで DHCP の応答にマシンが dnsmasq を使用していない場合は、dnsmasq を完全に無効にします。
物理ネットワークで DHCP の応答に dnsmasq の実行が必要な場合は、/etc/dnsmasq.conf ファイルを編集します。最初の行と続く 2 行の内のどちらかを追加するか、またはコメントを解除します。3 行すべての追加またはコメント解除はしないでください。
bind-interfaces
interface=name_of_physical_interface
listen-address=chosen_IP_address
この変更を加えてファイルを保存した後、システムワイドの dnsmasq サービスを再起動します。
次に、default ネットワークを virsh net-start default コマンドでスタートします。
仮想マシンを起動します。

B.8. ゲスト上の PXE ブート (または DHCP ) が失敗

現象
ゲスト仮想マシンは正常にスタートするが、DHCP から IP アドレスを取得できない、または PXE を使用したブートができない、もしくはその両方。このエラーには 2 つの一般的な原因があります。ブリッジでの転送遅延時間が長く設定されている場合と、iptables パッケージとカーネルがチェックサム難号化ルールをサポートしない場合です。
ブリッジの転送遅延時間が長い
調査
このエラーにおける最も一般的な原因です。ゲストのネットワークインターフェースが STP (Spanning Tree Protocol) 対応のブリッジデバイスに接続しており、かつ長時間の転送遅延時間が設定されていると、ブリッジは少なくともゲストがブリッジに接続してからその転送遅延時間が経過してからでなければゲスト仮想マシンからのネットワークパケットを転送しません。この遅延により、インターフェースからのトラフィックの監視、背後での MAC アドレスの決定、ネットワークトポロジー内の転送ループ防止がブリッジ時間で可能になります。
転送遅延がゲストの PXE や DHCP クライアントのタイムアウトよりも長い場合、クライアントの作業は失敗し、ゲストは (PXE の場合) 起動に失敗するか (DHCP の場合) IP アドレスの取得に失敗します。
解決法
これが原因の場合は、ブリッジにおける転送遅延を 0 に変更するか、またはブリッジの STP を無効にします。

注記

この解決法は、ブリッジが複数のネットワーク接続に使用されておらず、複数のエンドポイントを単一のネットワーク接続のみ (libvirt が使用する最も一般的なブリッジのユースケース) に使用されている場合にだけ、適用されます。
ゲストが libvirt 管理の仮想ネットワークに接続するインターフェースを備えている場合、そのネットワークの定義を編集し、再起動します。たとえば、以下のコマンドでデフォルトのネットワークを編集します。
# virsh net-edit default
<bridge> 要素に以下の属性を追加します。
<name_of_bridge='virbr0' delay='0' stp='on'/>

注記

delay='0'stp='on' は、仮想ネットワークのデフォルト設定なので、このステップは設定がデフォルトから変更されている場合にのみ必要となります。
ゲストインターフェースが、libvirt 外で設定されているホストブリッジに接続されている場合、遅延設定を変更します。
/etc/sysconfig/network-scripts/ifcfg-name_of_bridge ファイルで以下の行を追加または編集して、STP を on に、遅延を 0 秒にします。
STP=on
DELAY=0
設定ファイルの変更後にブリッジデバイスを再起動します。
/sbin/ifdown name_of_bridge
/sbin/ifup name_of_bridge

注記

name_of_bridge がネットワークの root ブリッジでない場合、そのブリッジの遅延は最終的には root ブリッジで設定されている遅延時間をリセットします。この場合の唯一の解決法は、name_of_bridge 上で STP を完全に無効にすることです。
iptables パッケージとカーネルがチェックサム難号化ルールをサポートしない場合
調査
このメッセージは、以下の 4 つの条件すべてが該当する場合にのみ、問題となります。
  • ゲストが virtio ネットワークデバイスを使用している。
    その場合、設定ファイルに model type='virtio' が含まれている。
  • ホストに vhost-net モジュールがロードされている。
    これは、ls /dev/vhost-net が空の結果を返さない場合に該当します。
  • ホスト上で直接実行中の DHCP サーバーからホストが IP アドレスを取得しようとしている。
  • ホスト上の iptables バージョンが 1.4.10 またはそれ以降のもの。
    iptables 1.4.10 は、libxt_CHECKSUM 拡張を追加する最初のバージョンでした。libvirtd ログに以下のメッセージが表示されると、これに該当します。
    warning: Could not add rule to fixup DHCP response checksums on network default
    warning: May need to update iptables package and kernel to support CHECKSUM rule.

    重要

    はじめの 3 つの条件すべてが該当していなければ上記の警告メッセージは問題を示すものではなく、無視することができます。
これらの条件が当てはまる場合は、ホストからゲストへ送信された UDP パケットに未算出のチェックサムがあります。これにより、ホストの UDP パケットがゲストのネットワークスタックには無効に見えるようになります。
解決法
この問題を解決するには、上記の 4 つの条件のいずれかを無効にします。最善の解決法は、可能であればホストの iptables およびカーネルを iptables-1.4.10 またはそれ以降に更新することです。別の方法としては、この特定のゲストの vhost-net ドライバーを無効にしてしまうことが最も的確な修正方法です。これを行うには、以下のコマンドでゲスト設定を編集します。
virsh edit name_of_guest
<interface> セクションに <driver> 行を変更するか、または追加します。
<interface type='network'>
  <model type='virtio'/>
  <driver name='qemu'/>
  ...
</interface>
変更を保存し、ゲストをシャットダウンしてから再起動します。
これで解決されない場合、問題の原因は firewalld とデフォルトの libvirt ネットワークの競合である可能性があります。
これを修正するには、service firewalld stop コマンドで firewalld を停止し、service libvirtd restart コマンドで libvirt を再起動します。

B.9. ゲストは外部ネットワークにアクセスできるが、macvtap 使用時にはホストにアクセスできない

現象
ゲストは他のゲストと通信できるが、macvtap (別名 type='direct') ネットワークインターフェース使用の設定後にはホストに接続できない。
調査
Virtual Ethernet Port Aggregator (VEPA) や VN-Link 対応スイッチに接続していない時でも、macvtap インターフェースは役に立ちます。インターフェースのモードを bridge に設定すると、非常に簡単な方法でゲストは物理ネットワークに直接接続することができます。従来のホストブリッジデバイスにつきものの設定問題 (または、NetworkManager の非互換性) がありません。
しかし、ゲスト仮想マシンが macvtap などの type='direct' ネットワークインターフェースを使用するように設定されていると、ネットワーク上で他のゲストや他の外部ホストと通信する機能がありながら、ゲストは自分のホストと通信できなくなります。
この状況は、実際にはエラーではなく macvtap の定義済み動作です。ホストの物理イーサネットが macvtap ブリッジにアタッチされている方法が原因で、物理インターフェースに転送されるゲストからそのブリッジへのトラフィックは、ホストの IP スタックに跳ね返ってくることができません。さらには、物理インターフェースに送信されたホストの IP スタックからのトラフィックも macvtap ブリッジに跳ね返って来ず、ゲストに転送することができません。
解決法
libvirt を使って、分離したネットワークとこのネットワークに接続する各ゲスト仮想マシン用に 2 つ目のインターフェースを作成します。これでホストとゲストはこの分離したネットワーク上で直接通信できる一方、NetworkManager との互換性も維持できます。

手順B.3 libvirt による分離ネットワークの作成

  1. 以下の XML を /tmp/isolated.xml ファイルに追加して保存します。自分のネットワーク上で 192.168.254.0/24 がすでに使われている場合、別のネットワークを選びます。
    <network>
      <name>isolated</name>
      <ip address='192.168.254.1' netmask='255.255.255.0'>
        <dhcp>
          <range start='192.168.254.2' end='192.168.254.254' />
        </dhcp>
      </ip>
    </network>
  2. 以下のコマンドでネットワークを作成します: virsh net-define /tmp/isolated.xml
  3. virsh net-autostart isolated コマンドでネットワークの自動スタートを設定します。
  4. virsh net-start isolated コマンドでネットワークを起動します。
  5. virsh edit name_of_guest を使って、ネットワーク接続に macvtap を使用するゲストの設定を編集し、以下と同様の新たな <interface><devices> セクションに追加します。( <model type='virtio'/> 行を含めるかはオプション )
    <interface type='network'>
      <source network='isolated'/>
      <model type='virtio'/>
    </interface>
  6. 各ゲストをシャットダウンし再起動します。
これでゲストは 192.168.254.1 のアドレスにあるホストにアクセスでき、ホストは各ゲストが DHCP から取得した IP アドレスでゲストにアクセスできます (または、ゲストに手動で IP アドレスを設定することもできます)。この新たなネットワークはこのホストとゲスト専用に分離されているので、ゲストからの他の通信はすべて macvtap インターフェースを使用することになります。

B.10. Could not add rule to fixup DHCP response checksums on network 'default'

現象
以下のメッセージが表示されます。
Could not add rule to fixup DHCP response checksums on network 'default'
調査
このメッセージはエラーに見えますが、ほとんどの場合問題ありません。
解決法
ゲスト仮想マシンが DHCP から IP アドレスを取得できないという問題が発生していない限り、このメッセージは無視してかまいません。
この問題が発生している場合は、「ゲスト上の PXE ブート (または DHCP ) が失敗」 を参照してください。

B.11. Unable to add bridge br0 port vnet0: No such device

現象
以下のエラーメッセージが表示されます。
Unable to add bridge name_of_bridge port vnet0: No such device
たとえばブリッジ名が br0 の場合、エラーメッセージは以下のようになります。
Unable to add bridge br0 port vnet0: No such device
libvirt のバージョン 0.9.6 およびそれ以前では、以下のようなメッセージになります。
Failed to add tap interface to bridge name_of_bridge: No such device
たとえばブリッジ名が br0 の場合、エラーメッセージは以下のようになります。
Failed to add tap interface to bridge 'br0': No such device
調査
いずれのエラーメッセージも、ゲストの (またはドメインの) <interface> 定義で指定されたブリッジデバイスが存在しないことを示しています。
エラーメッセージで表示されたブリッジデバイスが存在しないことを確認するには、シェルコマンド ifconfig br0 を使います。
以下のようなメッセージが表示されると、その名前のブリッジが存在しないことが確認できます。
br0: error fetching interface information: Device not found
存在しない場合は、解決法に進みます。
ただし、メッセージが以下のようであれば、問題は別に存在します。
br0        Link encap:Ethernet  HWaddr 00:00:5A:11:70:48  
           inet addr:10.22.1.5  Bcast:10.255.255.255  Mask:255.0.0.0
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:249841 errors:0 dropped:0 overruns:0 frame:0
           TX packets:281948 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0 
	   RX bytes:106327234 (101.4 MiB)  TX bytes:21182634 (20.2 MiB)
解決法
virsh で既存のブリッジを編集または新規ブリッジを作成
virsh を使って既存のブリッジもしくはネットワークの設定を編集するか、ブリッジデバイスをホストシステム設定に追加します。
virsh を使った既存ブリッジ設定の編集
virsh edit name_of_guest を使って既存のブリッジまたはネットワークを使用するための <interface> 定義を変更します。
たとえば、type='bridge'type='network' に、<source bridge='br0'/><source network='default'/> に変更します。
virsh を使ったホストブリッジの作成
libvirt のバージョン 0.9.8 およびそれ以降では、virsh iface-bridge コマンドでブリッジデバイスが作成できます。これで作成されるのは、eth0 のあるブリッジデバイス br0 で、ブリッジの一部として設定された物理ネットワークインターフェースがアタッチされます。
virsh iface-bridge eth0 br0
オプション: このブリッジを削除して、以下のコマンドでオリジナルの eth0 設定を回復することもできます。
virsh iface-unbridge br0
ホストブリッジを手動で作成
libvirt の古いバージョンでは、ホスト上に手動でブリッジデバイスを作成することもできます。指示に関しては 「libvirt を使用したブリッジネットワーキング」 を参照してください。

B.12. ゲストがスタートできずエラーが発生: warning: could not open /dev/net/tun

現象
ホストシステムの type='ethernet' (別名、ジェネリックイーサネット) インターフェースの設定後にゲスト仮想マシンがスタートしない。以下と同様のエラーメッセージが libvirtd.log または /var/log/libvirt/qemu/name_of_guest.log のどちらか、または両方に表示される。
warning: could not open /dev/net/tun: no virtual network emulation qemu-kvm: -netdev tap,script=/etc/my-qemu-ifup,id=hostnet0: Device 'tap' could not be initialized
調査
ジェネリックイーサネットのインターフェースタイプ (<interface type='ethernet'>) の使用は推奨されません。これを使用するには、QEMU およびゲストにおけるホストの潜在的なセキュリティーの不備に対する保護レベルを下げる必要があるからです。しかし、このタイプのインターフェースを使用して libvirt で直接サポートされていない別の機能を活用することも必要なこともあります。たとえば、openvswitchlibvirt では libvirt-0.9.11 までサポートされていなかったので、libvirt の古いバージョンでは <interface type='ethernet'> がゲストを openvswitch ブリッジに接続する唯一の方法でした。
しかし、ホストシステムに他の変更を加えることなく <interface type='ethernet'> インターフェースを設定すると、ゲスト仮想マシンは正常にスタートしなくなります。
この失敗の原因は、この種類のインターフェースでは、QEMU に呼び出されるスクリプトはタップデバイスを操作する必要があることにあります。しかし、type='ethernet' が設定されていると、QEMU をロックダウンする目的で、libvirt と SELinux はこれを妨げるためのチェックをいくつか確立します (通常、libvirt はタップデバイス作成および操作のすべてを実行し、タップデバイスのオープンファイル記述子を QEMU に渡します。)。
解決法
ホストシステムがジェネリックイーサネットインターフェースと互換性を持つように再設定します。

手順B.4 ホストシステムがジェネリックイーサネットインターフェースを使用するように再設定

  1. /etc/selinux/configSELINUX=permissive と設定し、SELinux を permissive に設定します。
    # This file controls the state of SELinux on the system.
    # SELINUX= can take one of these three values:
    #       enforcing - SELinux security policy is enforced.
    #       permissive - SELinux prints warnings instead of enforcing.
    #       disabled - No SELinux policy is loaded.
    SELINUX=permissive
    # SELINUXTYPE= can take one of these two values:
    #       targeted - Targeted processes are protected,
    #       mls - Multi Level Security protection.
    SELINUXTYPE=targeted
  2. root シェルから setenforce permissive コマンドを実行します。
  3. /etc/libvirt/qemu.conf で以下の行を追加または編集します。
    clear_emulator_capabilities = 0
    user = "root"
    group = "root"
    cgroup_device_acl = [
            "/dev/null", "/dev/full", "/dev/zero",
            "/dev/random", "/dev/urandom",
            "/dev/ptmx", "/dev/kvm", "/dev/kqemu",
    	"/dev/rtc", "/dev/hpet", "/dev/net/tun",
  4. libvirtd を再起動します。

重要

これらのステップは QEMU ゲストドメインに対するホストのセキュリティー保護を大幅に低下させるので、この設定は <interface type='ethernet'> 以外に方法がない場合にのみ使用してください。

注記

SELinux についてさらに詳しくは、『Red Hat Enterprise Linux 6 Security-Enhanced Linux User Guide』 を参照してください。

B.13. マイグレーションに失敗しエラーが発生 Error: unable to resolve address

現象
QEMU ゲストマイグレーションが失敗し、以下のエラーメッセージが表示される。
# virsh migrate qemu qemu+tcp://192.168.122.12/system
  error: Unable to resolve address name_of_host service '49155': Name or service not known
たとえば、移行先のホスト名が "newyork" であるとすると、エラーメッセージは以下のようになります。
# virsh migrate qemu qemu+tcp://192.168.122.12/system
error: Unable to resolve address 'newyork' service '49155': Name or service not known
しかし、ホスト名 "newyork" はどこにも使用していないため、このエラーには違和感があります。
調査
マイグレーション中に、移行先ホスト上で稼働しているlibvirtd はマイグレーションデータの受信を予想しているアドレスおよびポートから URI を作成し、これをソースホスト上で稼働している libvirtd に送信します。
上記の例では、移行先ホスト (192.168.122.12) は名前を 'newyork' に設定していました。何らかの理由で、そのホスト上で実行中の libvirtd は IP アドレスに対して名前を解決できず、送信されるべきものが有効なままとなっています。このため、ソースの libvirtd が名前を解決することを期待して、ホスト名 'newyork' が返されました。DNS が適切に設定されていなかったり、/etc/hosts にローカルループバックアドレス (127.0.0.1) に関連するホスト名があったりすると、このようなことが発生します。
マイグレーションデータに使用されるアドレスは、移行先 libvirtd への接続に使用されるアドレス (たとえば、qemu+tcp://192.168.122.12/system) から自動的に決定されることはありません。これは、移行先 libvirtd と通信するために、ソースの libvirtd は (別のマシンで実行中かもしれない) virsh が必要とするネットワークインフラストラクチャーとは別のものを使用する必要がある場合があるためです。
解決法
最善の解決法は、DNS を正しく設定し、マイグレーションに関連するすべてのホストがすべてのホスト名を解決できるようにすることです。
DNS をこのように設定できない場合は、各ホスト上の /etc/hosts ファイルにマイグレーションに使用するすべてのホストのリストを手動で追加することができます。しかし、動的な環境ではそのようなリストの一貫性の維持は困難です。
どの方法でもホスト名を解決可能にできない場合、virsh migrate はマイグレーションホストの特定をサポートします。
# virsh migrate qemu qemu+tcp://192.168.122.12/system tcp://192.168.122.12
移行先 libvirtdtcp://192.168.122.12 URI を取得し、自動生成されたポート番号を追加します。この番号が望ましくない場合は (たとえば、ファイアウォール設定のため)、ポート番号は以下のコマンドで指定できます。
# virsh migrate qemu qemu+tcp://192.168.122.12/system tcp://192.168.122.12:12345
別のオプションでは、トンネル化したマイグレーションを使用します。トンネル化したマイグレーションでは、マイグレーションデータ用に別の接続を作成しませんが、その代わりに移行先 libvirtd との通信で使用される接続でデータをトンネルします。(たとえば、qemu+tcp://192.168.122.12/system)
# virsh migrate qemu qemu+tcp://192.168.122.12/system --p2p --tunnelled

B.14. マイグレーションに失敗しエラーが発生: Unable to allow access for disk path: No such file or directory

現象
libvirt がディスクイメージにアクセスできないため、ゲスト仮想マシン (またはドメイン) を移行できない。
# virsh migrate qemu qemu+tcp://name_of_host/system
error: Unable to allow access for disk path /var/lib/libvirt/images/qemu.img: No such file or directory
たとえば、移行先のホスト名が "newyork" の場合、エラーメッセージは以下のようになります。
# virsh migrate qemu qemu+tcp://newyork/system
error: Unable to allow access for disk path /var/lib/libvirt/images/qemu.img: No such file or directory
調査
デフォルトでは、マイグレーションで移動するのは実行中のゲストのメモリー内の状態のみです (メモリ−または CPU 状態など)。マイグレーション中にはディスクイメージは移動しませんが、両方のホストから同じパスでアクセスできる状態である必要があります。
解決法
両方のホストの同じ位置に共有ストレージをマウントしてセットアップします。一番簡単な方法は、NFS を使用することです。

手順B.5 共有ストレージのセットアップ

  1. ホスト上に共有ストレージとして機能する NFS サーバーをセットアップします。関連するすべてのホストが NFS で共有ストレージにアクセスしている限り、NFS サーバーにはマイグレーションに関与しているいずれかのホストを使用できます。
    # mkdir -p /exports/images
    # cat >>/etc/exports <<EOF
    /exports/images    192.168.122.0/24(rw,no_root_squash)
    EOF
  2. libvirt を実行しているすべてのホスト上の共通の場所にエクスポートされたディレクトリーをマウントします。たとえば、NFS サーバーの IP アドレスが 192.168.122.1 の場合、ディレクトリーを以下のコマンドでマウントします。
    # cat >>/etc/fstab <<EOF
    192.168.122.1:/exports/images  /var/lib/libvirt/images  nfs  auto  0 0
    EOF
    # mount /var/lib/libvirt/images

注記

NFS を使っているホストからローカルディレクトリーをエクスポートし、別のホストの同じパスにマウントすることはできません。ディスクイメージの保存に使われるディレクトリーは、両方のホスト上の共有ストレージからマウントされる必要があります。これが正確に設定されていない場合、ゲスト仮想マシンはマイグレーション中にそのディスクイメージへのアクセスを失う可能性があります。これは、ゲストを移行先に正常に移行した後に、ソースホストの libvirt デーモンがディスクイメージ上のオーナーやパーミッション、SELinux ラベルを変更する可能性があるからです。
libvirt は、ディスクイメージが共有ストレージの場所からマウントされたことを検出すると、これらの変更を実施しません。

B.15. libvirtd のスタート時にゲスト仮想マシンが見当たらない

現象
libvirt デーモンは正常にスタートしたが、ゲスト仮想マシンが見当たらない
# virsh list --all
 Id    Name                           State
----------------------------------------------------
#
調査
この問題の原因はいくつも考えられます。以下のテストを実施して原因を特定します。
KVM カーネルモジュールの確認
KVM カーネルモジュールがカーネルに挿入されていることを確認する。
# lsmod | grep kvm
kvm_intel             121346  0
kvm                   328927  1 kvm_intel
AMD マシンを使用している場合は、root シェルで同様の lsmod | grep kvm_amd コマンドを使用してカーネルに kvm_amd カーネルモジュールが挿入されていることを確認します。
モジュールが確認されない場合、modprobe <modulename> コマンドを使用して挿入します。

注記

一般的ではありませんが、KVM 仮想化サポートがカーネルにコンパイルされている場合もあります。その場合は、モジュールは必要ありません。
仮想化拡張機能の確認
仮想化拡張機能がホスト上でサポートされ、有効となっていることを確認します。
# egrep "(vmx|svm)" /proc/cpuinfo
flags		: fpu vme de pse tsc ... svm ... skinit wdt npt lbrv svm_lock nrip_save
flags		: fpu vme de pse tsc ... svm ... skinit wdt npt lbrv svm_lock nrip_save
ご使用のハードウェアの BIOS 設定内のファームウェア設定で仮想化拡張機能を有効にします。詳細は、ご使用のハードウェア資料を参照してください。
クライアント URI 設定の確認
クライアントの URI が適切に設定されていることを確認します。
# virsh uri
vbox:///system
たとえば、このメッセージは URI が QEMU ではなく VirtualBox ハイパーバイザーに接続されていることを示し、本来は QEMU ハイパーバイザーに接続するように設定されているはずの URI の設定エラーを示しています。URI がQEMU に正常に接続している場合は、メッセージは以下のようになります。
# virsh uri
qemu:///system
他のハイパーバイザーが存在し、libvirt がこのハイパーバイザーにデフォルトで接続する場合に、この状況が発生します。
解決法
これらのテスト実行後に、以下のコマンドでゲスト仮想マシンのリストを表示させます。
# virsh list --all

B.16. Unable to connect to server at 'host:16509': Connection refused ... error: failed to connect to the hypervisor

現象
libvirtd 接続で TCP ポートをリッスンしている間に、接続が失敗する。
# virsh -c qemu+tcp://host/system
error: unable to connect to server at 'host:16509': Connection refused
error: failed to connect to the hypervisor
/etc/libvirt/libvirtd.conf で設定を変更した後でも、libvirt デーモンが TCP ポートをリッスンしない。
# grep listen_ /etc/libvirt/libvirtd.conf
listen_tls = 1
listen_tcp = 1
listen_addr = "0.0.0.0"
しかし、設定変更も libvirt の TCP ポートは開いていない。
# netstat -lntp | grep libvirtd
#
調査
libvirt デーモンが --listen オプションなしにスタートしたことを以下のコマンドを実行して確認します。
# ps aux | grep libvirtd
root     27314  0.0  0.0 1000920 18304 ?       Sl   Feb16   1:19 libvirtd --daemon
出力には --listen は含まれません。
解決法
--listen オプションでデーモンをスタートします。
これを実行するには、/etc/sysconfig/libvirtd ファイルを編集し、以下の行のコメント解除を行います。
#LIBVIRTD_ARGS="--listen"
以下の行で libvirtd サービスを再スタートします。
# /etc/init.d/libvirtd restart

B.17. 一般的な XML エラー

libvirt ツールは XML ドキュメントを使用して構造化データを保存します。XML ドキュメントの様々なエラーは、XML ドキュメントが API で libvirt に渡される際に発生します。一般的な XML エラー (XML の不適切なフォーマットや不適切な値、要素の欠如を含む) のいくつかを以下で詳述します。

B.17.1. ドメイン定義の編集

これは推奨されませんが、ゲスト仮想マシン (またはドメイン) の XML ファイルを手動で編集することも時には必要になります。編集目的でゲストの XML にアクセスするには、以下のコマンドを使用します。
# virsh edit name_of_guest.xml
このコマンドで、ゲスト仮想マシンの現在の定義によるファイルがテキストエディターで開かれます。編集して変更を保存した後、XML はリロードされ、libvirt が解析します。XML が正しければ、以下のメッセージが表示されます。
# virsh edit name_of_guest.xml

Domain name_of_guest.xml XML configuration edited.

重要

virshedit コマンドを使用して、XML ドキュメントを編集する際は、エディターを終了する前にすべての変更を保存します。
XML ファイルの保存後に、xmllint コマンドで XML が整形式かどうかを確認します。または、virt-xml-validate コマンドで使用法の問題をチェックします。
# xmllint --noout config.xml
# virt-xml-validate config.xml
エラーが表示されない場合、XML 記述子は整形式で libvirt スキーマに合致しています。スキーマはすべての制約をキャッチしませんが、レポートされたエラーを修正することでトラブルシューティングが促進されます。
libvirt が保存する XML ドキュメント
これらのドキュメントには、ゲストの状態や設定の定義が含まれています。ドキュメントは自動生成され、手動での編集は推奨されません。ドキュメントにあるエラーには、破損したドキュメントのファイル名が含まれています。このファイル名は、URI によって定義されたホストマシン上でのみ有効で、コマンドが実行されたマシンを参照する場合があります。
libvirt が作成したファイルでのエラーは稀にしかありません。エラーの原因となり得るのは、libvirt のダウングレードです。新しいバージョンの libvirt は、古いバージョンが生成した XML を常に読み込めるのに対して、古いバージョンの libvirt は、新しいバージョンで追加された XML 要素で混乱する可能性があります。

B.17.2. XML 構文エラー

構文エラーは、XML パーサーがキャッチします。エラーメッセージには、問題特定のための情報が含まれています。
以下の例では、XML パーサーからのエラーメッセージは、3 行から構成されています。最初の行はエラーメッセージを表示し、残りの 2 行にはエラーを含む XML コードのコンテキストと場所が含まれています。3 行目には、上の行のどこにエラーがあるかのおおよその位置を示す表示が含まれています。
error: (name_of_guest.xml):6: StartTag: invalid element name
<vcpu>2</vcpu><
-----------------^
このメッセージに含まれている情報
(name_of_guest.xml)
これは、エラーを含むドキュメントのファイル名です。括弧内のファイル名は、メモリーから解析された XML ドキュメントを表現する象徴的な名前で、ディスク上のファイルに直接対応するものではありません。括弧内に含まれていないファイル名は、接続先に配置されているローカルファイルです。
6
これは、XML ファイル内でのエラーを含む行数です。
StartTag: invalid element name
これは libxml2 パーサーからのエラーメッセージで、特定の XML エラーを記述するものです。

B.17.2.1. ドキュメント内の不要な <

現象
以下のエラーが発生する。
error: (name_of_guest.xml):6: StartTag: invalid element name
<vcpu>2</vcpu><
-----------------^
調査
このエラーメッセージは、ゲストの XML ファイルの 6 行目にある < 記号の後で、パーサーが新たな要素名を予測していることを示しています。
テキストエディターの行数表示が有効になっていることを確認します。XML ファイルを開いて、6 行目のテキストを見つけます。
<domain type='kvm'>
   <name>name_of_guest</name>
<memory>524288</memory>
<vcpu>2</vcpu><
ゲストの XML ファイルのこのスニペットには、ドキュメントの余分な < が含まれています。
解決法
余分な < を削除するか、または新たな要素を終了させます。

B.17.2.2. 未終了の属性

現象
以下のエラーが発生する。
error: (name_of_guest.xml):2: Unescaped '<' not allowed in attributes values
<name>name_of_guest</name>
--^
調査
ゲストの XML ファイルのこのスニペットには、未終了要素の属性値が含まれています。
<domain type='kvm>
<name>name_of_guest</name>
このケースでは、'kvm' を閉じる引用符が足りません。XML の開始および終了タグと同様に、引用符やアポストロフィーなどの属性値のストリングは開いてから閉じる必要があります。
解決法
すべての属性値ストリングを正しく開いてから閉じます。

B.17.2.3. 開始および終了タグのミスマッチ

現象
以下のエラーが発生する。
error: (name_of_guest.xml):61: Opening and ending tag mismatch: clock line 16 and domain
</domain>
---------^
調査
上記のエラーメッセージには、問題となっているタグを特定する 3 つのヒントがあります。
最後のコロンの後のメッセージである clock line 16 and domain は、ドキュメントの 16 行目の <clock> にタグのミスマッチがあることを示しています。最後のヒントはメッセージのコンテキスト部分にあるポインターで、問題となっている 2 つ目のタグを特定しています。
ペアになっていないタグは /> で閉じる必要があります。以下のスニペットはこのルールを守っていないので、上記のエラーメッセージが表示されました。
<domain type='kvm'>
  ...
    <clock offset='utc'>
このエラーはファイル内の XML タグのミスマッチが原因で発生します。すべての XML タグは、開始および終了タグでマッチする必要があります。
XML タグの他のミスマッチ例
以下の例では同様のエラーメッセージが生成され、XML タグのミスマッチの例が示されています。
このスニペットには、閉じられていない <features> があります。
<domain type='kvm'>
 ...
 <features>
   <acpi/>
   <pae/>
 ...
 </domain>
このスニペットには、対応する開始タグのない </name> が含まれます。
<domain type='kvm'>
  </name>
  ...
</domain>
解決法
すべての XML タグが正しく開始し、終了していることを確認します。

B.17.2.4. よくあるタグのエラー

現象
以下のエラーメッセージが表示されます。
error: (name_of_guest.xml):1: Specification mandate value for attribute ty
<domain ty pe='kvm'>
-----------^
調査
XML エラーは、簡単な誤字脱字で発生します。このエラーメッセージは、XML エラー (このケースでは type という単語の中に余分な空白) をポインターで示しています。
<domain ty pe='kvm'>
以下の XML のサンプルは、特殊文字が足りなかったり余分な文字があったりするエラーが理由で正確に解析されません。
<domain type 'kvm'>
<dom#ain type='kvm'>
解決法
問題のあるタグを特定するには、ファイルのコンテキストのエラーメッセージを読んで、ポインターでエラーを見つけます。XML を修正し、変更を保存します。

B.17.3. 論理および設定エラー

適切にフォーマットされた XML ドキュメントには、構文が正しくても、libvirt が解析できないエラーが含まれる場合があります。これらのエラーの多くは、以下で説明する 2 つのケースに当てはまります。

B.17.3.1. 部分的な消滅

現象
ドメインの編集または定義後に、変更箇所が表示されず、その効果も見られない。define コマンドや edit コマンドは機能するが、XML を再度ダンプすると変更が消えてしまう。
調査
このエラーの原因となり得るのは、構築または構文が破損していて、libvirt が解析できないという場合です。libvirt ツールは通常、理解できるコンストラクトのみを探し、それ以外はすべて無視するので、libvirt が入力を解析した後に XML 変更が消滅する場合があります。
解決法
XML 入力を edit コマンドや define コマンドに渡す前に確認します。libvirt 開発者は、libvirt とバンドルされている XML スキーマ一式を維持します。これは、libvirt が使用する XML ドキュメントで許可されるコンストラクトの大半を定義するものです。
以下のコマンドを使って、libvirt XML ファイルを検証します。
# virt-xml-validate libvirt.xml
このコマンドが渡されると、多くの場合は libvirt が XML からのすべてのコンストラクトを理解します。ただし、特定のハイパーバイザーにのみ有効なオプションをスキーマが検出できない場合は、例外です。たとえば、virsh dump コマンドの結果として libvirt が生成した XML は、エラーなしで有効になります。

B.17.3.2. ドライブデバイスの種類の誤り

現象
CD-ROM 仮想ドライブ用のソースイメージの定義を追加したにもかかわらず、見当たらない。
# virsh dumpxml domain
<domain type='kvm'>
  ...
  <disk type='block' device='cdrom'>
    <driver name='qemu' type='raw'/>
    <target dev='hdc' bus='ide'/>
    <readonly/>
  </disk>
  ...
</domain>
解決法
以下のように、欠けている <source> パラメーターを追加して XML を訂正します。
<disk type='block' device='cdrom'>
  <driver name='qemu' type='raw'/>
  <source file='/path/to/image.iso'/>
  <target dev='hdc' bus='ide'/>
  <readonly/>
</disk>
type='block' ディスクイメージは、ソースが物理デバイスであることを期待します。イメージファイルのディスクを使用するには、代わりに type='file' を使用します。

付録C 改訂履歴

改訂履歴
改訂 0.5-31.3Wed Nov 19 2014Aiko Sasaki
校閲完了
改訂 0.5-31.2Thu Nov 13 2014Aiko Sasaki
翻訳完了
改訂 0.5-31.1Sun Nov 9 2014Aiko Sasaki
翻訳ファイルを XML ソースバージョン 0.5-31 と同期
改訂 0.5-31Fri Oct 10 2014Scott Radvan
6.6 GA リリース向けバージョン
改訂 0.5-30Thu Oct 09 2014Scott Radvan
Windows ゲスト移行用の古い NetKVM ドライバーについての警告を追加 (BZ#983321)。
改訂 0.5-28Thu Oct 09 2014Scott Radvan
ゲストエージェントに関する詳細および詳細情報の参照先となる管理ガイドを追加 (BZ#1149654)。
改訂 0.5-27Tue Sep 23 2014Scott Radvan
CPU モデルと CPUID フラグサポートを表示するために qemu-kvm コマンドを拡張 (BZ#1094116)。
KVM virtio ドライバーをインストールするためのエントリーを修正 (BZ#1107954)。
改訂 0.5-26Mon Sep 15 2014Scott Radvan
ベンダー ID と製品 ID エントリーを交換 (BZ#1123934)。
改訂 0.5-25Mon August 25 2014Jodi Biddle
vCPU 制限エラーを修正 (BZ#1092238)。
改訂 0.5-24Thurs August 7 2014Jodi Biddle
古くなった CPU モデルの内容を削除 (BZ#1094116)。
改訂 0.5-23Wed August 6 2014Jodi Biddle
対応 CPU モデルを更新 (BZ#1094116)。
改訂 0.5-22Tue August 5 2014Jodi Biddle
SR-IOV の章のベンダーおよび製品 ID のエラーを修正 (BZ#1123934)。
改訂 0.5-21Tue August 5 2014Tahlia Richardson
Windows 2008 は USEPLATFORMCLOCK パラメーターをサポートしないが、デフォルトで RTC を使用すると記載した行を追加 (BZ#907269)。
改訂 0.5-20Tue August 5 2014Jodi Biddle
QEMU の互換性の問題を防ぐために virtio ドライバーを最新の状態に保つことをユーザーに勧める注記を追加 (BZ#983321)。
改訂 0.5-19Fri August 1 2014Tahlia Richardson
「ゲスト上の PXE ブート (または DHCP) が失敗」にある最初のソリューションについて、1 つのオプションまたはどちらか一方を使用する必要があることから「or both」を削除するように変更 (BZ#913793)。
改訂 0.5-18Fri August 1 2014Jodi Biddle
「仮想化パッケージのインストール」および「KVM 準仮想化 (virtio) ドライバー」を RHN のサポート終了日を反映するように変更 (BZ#1107954)。
改訂 0.5-17Fri July 18 2014Tahlia Richardson
「KVM virtio ドライバーを使用した新規デバイスの作成」の手順を修正および再編成 (BZ#1101859)。
改訂 0.5-16Wed 18 June 2014Tahlia Richardson
--live オプションと注記を SR-IOV の章から削除。
改訂 0.5-15Thurs 5 June 2014Tahlia Richardson
不要なスクリーンショットを削除。
改訂 0.5-14Mon 2 June 2014Tahlia Richardson
virt の制限に関する章で vCPU の最大数を 240 に修正。
改訂 0.5-13Thurs 29 May 2014Tahlia Richardson
管理ガイドの Hyper-V 情報を本書の Hyper-V セクションに移行。
改訂 0.5-12Thurs 29 May 2014Tahlia Richardson
Hyper-V セクションのリンクを更新、および LIS バージョン番号の言及を削除 (LIS は組み込まれることになったため、バージョン番号とダウンロードリンクの関連性がなくなる)。
改訂 0.5-11Wed 21 May 2014Tahlia Richardson
SME フィードバックに基づき KVM 準仮想化ドライバーの章を編集 (BZ#1094107)。
改訂 0.5-10Thurs 15 May 2014Tahlia Richardson
「準仮想化デバイス」と「PCI デバイス割り当て制限」を「PCI デバイス」セクションの制限リストに統合 (BZ#891154)。
デフォルトデバイス設定を明確化 (BZ#918341)。
改訂 0.5-09Tues May 13 2014Tahlia Richardson
virt-install 手順に対する若干の修正 (BZ#831157)。
重複テキストを削除 (BZ#1096501)。
改訂 0.5-08Tues Nov 19 2013Tahlia Richardson
6.5 GA リリース向けのバージョン
改訂 0.5-07Friday Sept 27 2013Tahlia Richardson
誤字の修正、更新リンクその他の全般的なメンテナンス。
改訂 0.5-06Thursday Sept 19 2013Tahlia Richardson
対応 CPU モデル (BZ#1008992) および -cpu ? コマンドについての注記を追加。
BZ#1009186 からの情報を追加。
改訂 0.5-04Wednesday Sept 18 2013Tahlia Richardson
手順 7.1 のステップ 6a に最大ディスクサイズに関する注記を追加。
改訂 0.5-03Monday Sept 16 2013Tahlia Richardson
第 3.1 章 Red Hat Enterprise Linux 6 サポート制限に対応メモリーに関する注記を追加。
改訂 0.5-02Fri Sept 13 2013Tahlia Richardson
第 8.1 章の VMware ESX で誤字を修正。
改訂 0.5-01Wed July 31 2013Tahlia Richardson
BZ#909030 を基に VMWare ドライバーの情報を追加。
改訂 0.4-54Tues Feb 19 2013Tahlia Richardson
6.4 GA リリース向けバージョン
改訂 0.4-52Fri Feb 15 2013Tahlia Richardson
エラー修正のため著者タグを変更
改訂 0.4-50Thu Nov 22 2012Laura Bailey
サポートされているストレージ方法のリストを訂正し、FCoE を含めて未検査のSRP を削除 (BZ#846800)
本ガイド全体でサポートされている PCI デバイスの説明を訂正 (BZ#846800)
改訂 0.4-49Mon Nov 05 2012Laura Bailey
reboot-timeout パラメーターの使用法を明確化 (BZ#853318)
改訂 0.4-47Mon Oct 29 2012Laura Bailey
SME のフィードバックを反映 BZ#840924
改訂 0.4-46Thurs Oct 25 2012Dayle Parker
QE および SME のフィードバックを反映 (BZ#813621, BZ#813605, BZ#753999)
改訂 0.4-42Tue Oct 23 2012Laura Bailey
QE フィードバックを反映 (BZ#840924)
改訂 0.4-41Mon Oct 22 2012Dayle Parker
第 12 章に SME フィードバックを反映 (BZ#832023)
改訂 0.4-40Fri Oct 19 2012Dayle Parker
virsh の手順を編集、virt-manage の手順を追加 (BZ#831605)
スクリーンショットを訂正し撮り直し (BZ#734650)
スクリーンショットを編集 (BZ#753995)
第 12 章に SME フィードバックを反映 (BZ#832023)
改訂 0.4-39Thu Oct 18 2012Dayle Parker
スクリーンショットを訂正し撮り直し (BZ#753998)
スクリーンショットを訂正し撮り直し (BZ#734650)
スクリーンショットを撮り直し (BZ#753993)
QE フィードバックを反映 (BZ#866898)
改訂 0.4-38Thu Oct 18 2012Laura Bailey
PCI デバイスをアタッチ後に削除する方法のセクションを追加 (BZ#813605)
改訂 0.4-37Thu Oct 18 2012Dayle Parker
本ガイド全体で仮想マシン用語の一貫性を図る (BZ#813621)
仮想化パッケージグループに virt-what パッケージを追加 (BZ#831972)
最新のカーネルを更新 (BZ#753990)
「はじめに」を拡大 (BZ#831965)
改訂 0.4-36Wed Oct 17 2012Laura Bailey
準仮想化ドライバーの章でサポートされる Windows オペレーティングシステムのリストを訂正 (BZ#832043)
改訂 0.4-35Tue Oct 16 2012Laura Bailey
virsh nodedev-list の使用法とマイナーな誤字を訂正 (BZ#830097)
新たなブートパラメーターの記述を追加 (BZ#853318)
提供される VMWare ドライバーの記述を訂正 (BZ#840924)
提供される Microsoft ドライバーの記述を訂正 (BZ#840925)
改訂 0.4-34Fri Oct 12 2012Laura Bailey
ネットワークブリッジ作成に関する SME のフィードバックを反映、--vnc オプションの廃止、他のコンテンツの一般的な更新 (BZ#853854)
改訂 0.4-33Wed Oct 10 2012Laura Bailey
トラブルシューティングの付録からサポート外のセクションを削除 (BZ#838410)
Hyper-V 上での RHEL VM 実行に関する詳細を追加 (BZ#840925)
PXE virt-install コマンド例を訂正 (BZ#853850)
改訂 0.4-32Wed Oct 10 2012Dayle Parker
SR-IOV の章と PCI デバイス割り当てに関する章の関連部分を編集 (BZ#832023)
改訂 0.4-31Wed Oct 10 2012Laura Bailey
Windows Vista に関する記述をすべて削除 (BZ#840939)
ゲストエージェントのインストールおよび設定の詳細を追加 (BZ#801269)
改訂 0.4-30Mon Oct 8 2012Dayle Parker
スクリーンショットを置き換え、第 5 章のテキストを訂正 (BZ#753990)
改訂 0.4-29Mon Oct 8 2012Dayle Parker
注記 re: no SR-IOV implementation for AMD を削除 (BZ#832023)
qemu-img 注記を訂正、5.3 のスクリーンショットを置き換え (BZ#831483)
改訂 0.4-28Thu Oct 4 2012Dayle Parker
仮想化スタートガイドからの設定特定詳細を 3.2.1. に移動 (BZ#842971)
改訂 0.4-27Wed Oct 3 2012Dayle Parker
SME レビューの SR-IOV セクションを訂正 (BZ#832023)
改訂 0.4-26Wed Oct 3 2012Dayle Parker
クロックオフセットに関する警告を訂正 (BZ#800748)
PCI デバイス割り当てに関する注記を訂正 (第 10 章および 12 章) (BZ#848992)
改訂 0.4-24Fri Sep 28 2012Dayle Parker
クロックスキューに関する警告を訂正 (BZ#800748)
改訂 0.4-23Thu Sep 27 2012Dayle Parker
付録のセクションを削除 (B.2.1. No connection driver available)、SME フィードバックにしたがって編集 (BZ#838419)
第 10 章 を訂正 (BZ#831902)
改訂 0.4-22Thu Sep 27 2012Laura Bailey
Offload.Rx.Checksum および Offload.Tx.Checksum パラメーターの記述を更新 (BZ#796667)
改訂 0.4-21Fri Sep 21 2012Dayle Parker
第 14 章にスチールタイムアカウンティングの箇所を追加 (BZ#800748)
以下を付録に追加。ESXi ゲストの作成 - B.7: VMWare ESXi ゲスト作成に失敗... (BZ#838415)
libvirt 付録の B.13: Guest is unable to start with error... の SELinux ガイドへの参照を追加
改訂 0.4-20Thu Sep 20 2012Laura Bailey
NetKVM ドライバーの設定可能なパラメーターを追加 (BZ#796667)
改訂 0.4-19Wed Sep 19 2012Dayle Parker
SME レビューにしたがって「ジェネリックイーサネット」の付録を編集し追加 (BZ#838415)
libvirt「XML エラー」の付録を明確化 (BZ#838755)
改訂 0.4-18Monday September 17 2012Laura Bailey
Windows ゲストマシンおよび TSC に関するアドバイスを修正 (BZ#840939)
改訂 0.4-16Mon Sep 17 2012Dayle Parker
第 5 章の仮想化パッケージグループを更新 (BZ#831972)
付録 A.4 を更新 (BZ#836891)
付録 A.1 の問題を明確化 (BZ#838429)
改訂 0.4-15Thursday September 13 2012Laura Bailey
SME フィードバックをネットワーク設定の章に反映 (BZ#560535)
改訂 0.4-14Friday August 31 2012Dayle Parker
手順 13.1. SR-IOV ネットワークデバイスをアタッチ のステップを訂正 (BZ#819649)
改訂 0.4-11Monday June 18 2012Laura Bailey
Red Hat Enterprise Linux 6.3 リリースの最後の QE フィードバックを反映
Red Hat Enterprise Linux 6.3 GA 用に再構築
改訂 0.4-07Monday June 18 2012Laura Bailey
Red Hat Enterprise Linux 6.3 リリースの最後の QE フィードバックを反映
改訂 0.4-06Friday June 15 2012Dayle Parker
訂正 (BZ#831932)
改訂 0.4-05Thursday June 14 2012Laura Bailey
QE のフィードバックを反映
改訂 0.4-04Thursday May 31 2012Dayle Parker
libvirt の付録を表に再編成
改訂 0.4-03Tuesday May 29 2012Dayle Parker
libvirt のトラブルシューティングの付録を編集
改訂 0.4-02Tuesday May 08 2012Laura Bailey
Intel ハードウェア上の PCI デバイス割り当てに関して、BZ#819693BZ#747857 の競合を解決
改訂 0.4-01Wednesday May 02 2012Dayle Parker
libvirt エラーのトラブルシューティング」の付録を本ガイドに追加 (BZ#738250)
改訂 0.3-33Monday May 2 2012Laura Bailey
QE のフィードバックを反映
改訂 0.3-28Monday April 02 2012Laura Bailey
Windows VM インストールでの PV ドライバーのインストール手順を更新 (BZ#804470)
改訂 0.3-26Wednesday March 26 2012Laura Bailey
SR-IOV 関連の手順で誤解を招いたり、不明瞭なものを多数訂正
デバイス割り当て関連の制限を多数更新 (BZ#738141)
Windows ドライバーインストール手順を更新 (BZ#804468)
virtio デバイスの作成に必要なコマンドのマイナーエラーを多数訂正 (BZ#804470)
改訂 0.3-20Thursday March 22 2012Laura Bailey
14章KVM ゲストのタイミング管理 の divider パラメーターについての警告を更新 (BZ#801630)
改訂 0.3-18Monday March 19 2012Dayle Parker
開発者のフィードバックにしたがい、数式に関する推奨システム要件を明確化 (BZ#753988)
改訂 0.3-17Monday March 19 2012Laura Bailey
divider パラメーターの記述と使用法を明確化 (BZ#801630)
改訂 0.3-16Monday March 12 2012Laura Bailey
お客様および開発者のフィードバックにしたがいストレージ制限の詳細を調整 (BZ#773532)
divider パラメーターが特定の仮想ゲストに推奨されるという間違った表示を訂正 (BZ#801630)
改訂 0.3-15Tuesday March 06 2012Laura Bailey
開発者のフィードバックにしたがい調整 (BZ#752738)
ドライバーインストールスクリーンショットを更新 (BZ#753706)
改訂 0.3-13Monday March 05 2012Laura Bailey
SCSI 動作の変更についての詳細を追加 (BZ#790688)
改訂 0.3-12Thursday March 01 2012Dayle Parker
PDF フォーマットのスクリーンショットサイズを調整 (BZ#772984)
改訂 0.3-11Wednesday February 29 2012Dayle Parker
手順 5.1 のステップタイトルを追加、誤字およびスタイルの問題を訂正 (BZ#773292)
手順 6.2 でスクリーンショットを表としてラベル付け (BZ#726268)
改訂 0.3-10Tuesday February 28 2012Dayle Parker
表および手順にラベル付け。本ガイド全体で警告の一貫性を図る (BZ#726268)
リンクの更新 (BZ#753997)
システム要件の計算に関する詳細を追加 (raw および qcow イメージ) (BZ#753988)
改訂 0.3-9Friday February 24 2012Dayle Parker
仮想化管理ガイドへの相互参照リンクを削除 (BZ#753997)
改訂 0.3-8Thursday February 16 2012Dayle Parker
誤字を訂正、ゲストの命名規則を明確化、欠けていた表のキャプションおよびテキストオブジェクトを追加 (BZ#753706)
準仮想化のスペリングを確認、誤字を訂正、Red Hat ドキュメントのハイパーリンクを更新 (BZ#753997)
改訂 0.3-7Tuesday February 07 2012Laura Bailey
サポートされている PCI デバイスの数を訂正 (BZ#752738)
インストール手順を明確化 (BZ#649644)
手順10.2「Windows 7 仮想マシン上への Windows インストール」 の誤解を招く指示やスクリーンショット、スタイルおよび誤字を訂正 (BZ#736526)
Xen 仮想化手順を変更して完全仮想化ゲストを含める。テキストのみのインストールについての注意を追加。フォーマットを若干調整 (BZ#629767)
改訂 0.2-78Friday December 02 2011Laura Bailey
Red Hat Enterprise Linux 6.2 の GA リリース
改訂 0.2-66Wed Sep 14 2011Scott Radvan
BZ#734639
改訂 0.2-62Wed Sep 14 2011Scott Radvan
BZ#736497
改訂 0.2-60Thu Sep 01 2011Scott Radvan
SME レビューからの変更を追加 (BZ#734651)
改訂 0.2-59Thu Sep 01 2011Scott Radvan
SME レビューからの変更を追加 (BZ#734647 および BZ#734653)
改訂 0.2-03Mon May 30 2011Scott Radvan
SR-IOV、準仮想化ドライバー、Red Hat Enterprise Linux 6 ホスト上での Red Hat Enterprise Linux 6 ゲスト仮想マシンのインストールを追加
改訂 0.2-02Mon May 30 2011Scott Radvan
内部プレビューサイトへの最初のプッシュ
改訂 0.2-01Sat May 28 2011Scott Radvan
レイアウト設定、導入部テキストをインポート
改訂 0-1Mon Apr 4 2011Scott Radvan
Publican による初版作成

法律上の通知

Copyright © 2013 Red Hat, Inc.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.