Product SiteDocumentation Site

Red Hat Enterprise Linux 5

仮想化ガイド

Virtualization Documentation

エディッション 5.8

[FAMILY Given]

Red Hat Engineering Content Services

法律上の通知

Copyright © 2008, 2009, 2010, 2011, 2012 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
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, MetaMatrix, 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.
All other trademarks are the property of their respective owners.


1801 Varsity Drive
 RaleighNC 27606-2072 USA
 Phone: +1 919 754 3700
 Phone: 888 733 4281
 Fax: +1 919 754 3701

概要
The Red Hat Enterprise Linux Virtualization Guide contains information on installation, configuring, administering, and troubleshooting virtualization technologies included with Red Hat Enterprise Linux.

序文
1. このマニュアルについて
2. 表記方法
2.1. 印刷における表記方法
2.2. 引用における表記方法
2.3. 注記および警告
3. We need your feedback
3.1. Technical review requests
4. What is Virtualization?
5. Types of Virtualization
5.1. Full Virtualization
5.2. Para-Virtualization
5.3. Para-virtualized drivers
6. How CIOs should think about virtualization
I. Red Hat Enterprise Linux での仮想化に於ける要件と制限
1. システム要件
2. Xen の制約とサポート
3. KVM の制約とサポート
4. Hyper-V restrictions and support
5. 仮想化の制限
5.1. 仮想化に於ける一般的制限
5.2. KVM の制限
5.3. Xen の制限
5.4. アプリケーションの制限
II. インストール
6. 仮想化パッケージをインストール
6.1. Red Hat Enterprise Linux の新規インストールで Xen を インストール
6.2. 既存の Red Hat Enterprise Linux システムに Xen パッケージをインストール
6.3. Red Hat Enterprise Linux の新規インストールで KVM をインストール
6.4. 既存の Red Hat Enterprise Linux システムに KVM パッケージをインストール
7. 仮想化ゲストインストールの概要
7.1. virt-install を使用してゲストを作成
7.2. virt-manager を使用してゲストを作成
7.3. PXE を使用してゲストのインストール
8. ゲストオペレーティングシステムのインストール手順
8.1. Red Hat Enterprise Linux 5.0 を para-virtualized ゲストとしてインストール
8.2. Red Hat Enterprise Linux を完全仮想化ゲストとしてインストール
8.3. Windows XP を完全仮想化ゲストとしてインストール
8.4. 完全仮想化ゲストとして Windows Server 2003 をインストール
8.5. Windows Server 2008 を完全仮想化ゲストとしてインストール
III. 設定
9. Virtualized storage devices
9.1. 仮想化フロッピィディスクコントローラの作成
9.2. ストレージデバイスをゲストに追加
9.3. Red Hat Enterprise Linux 5 内に永続的ストレージを構成
9.4. 仮想化した CD-ROM 又は DVD デバイスをゲストに追加
10. ネットワークの設定
10.1. libvirt を持つ NAT(Network address translation)
10.2. libvirt を使用したブリッジネットワーキング
11. Red Hat Enterprise Linux 5.4 以前の Xen ネットワーキング
11.1. 複数のゲストネットワークブリッジを設定して複数のイーサネットカードを使用
11.2. Red Hat Enterprise Linux 5.0 ラップトップネットワークの設定
12. Xen Para-virtualized ドライバー
12.1. システム要件
12.2. Para-virtualization の制約とサポート
12.3. Para-virtualized ドライバーのインストール
12.3.1. 共通のインストール手順
12.3.2. Red Hat Enterprise Linux 3 で Para-virtualized ドライバーのインストールと 設定
12.3.3. Red Hat Enterprise Linux 4 上で Para-virtualized ドライバーのインストールと 設定
12.3.4. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 5
12.3.5. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 6
12.4. Para-virtualized ネットワークドライバーの設定
12.5. 追加の Para-virtualized ハードウェア設定
12.5.1. 仮想化ネットワークインターフェイス
12.5.2. 仮想ストレージデバイス
13. KVM Para-virtualized ドライバー
13.1. KVM Windows para-virtualized ドライバーのインストール
13.2. Installing drivers with a virtualized floppy disk
13.3. 既存のデバイスに KVM para-virtualized ドライバーを使用する
13.4. 新規デバイス用に KVM para-virtualized ドライバーを使用する
14. PCI passthrough
14.1. Adding a PCI device with virsh
14.2. Adding a PCI device with virt-manager
14.3. PCI passthrough with virt-install
14.4. PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux
15. SR-IOV
15.1. Introduction
15.2. Using SR-IOV
15.3. Troubleshooting SR-IOV
16. KVM ゲストのタイミング管理
IV. 管理
17. サーバーの最善使用法
18. 仮想化のセキュリティ
18.1. Storage security issues
18.2. SELinux と仮想化
18.3. SELinux
18.4. Virtualization firewall information
19. xend を使用したゲストの管理
20. Xen ライブ移行
20.1. ライブ移行の例
20.2. ゲストライブ移行の設定
21. KVM ライブ移行
21.1. ライブ移行の要件
21.2. 共有ストレージサンプル: 簡単な移行のための NFS
21.3. virsh を使用した ライブ KVM 移行
21.4. virt-manager での移行
22. 仮想化ゲストのリモート管理
22.1. SSH を使用したリモート管理
22.2. TLS と SSL を使用したリモート管理
22.3. トランスポートモード
V. Virtualization Storage Topics
23. Using shared storage with virtual disk images
23.1. Using iSCSI for storing virtual disk images
23.1.1. How to set up an iSCSI target on Red Hat Enterprise Linux
23.1.2. How to configure iSCSI on a libvirt KVM host and provision a guest using virt-install
VI. 仮想化リファレンスガイド
24. 仮想化のツール
25. virsh でゲストを管理
26. 仮想マシンマネージャ(virt-manager) でゲストを管理する
26.1. The Add Connection window
26.2. 仮想マシンマネージャの主要ウィンドウ
26.3. The guest Overview tab
26.4. 仮想マシングラフィカルコンソール
26.5. virt-manager の開始
26.6. 保存したマシンの復元
26.7. ゲストの詳細表示
26.8. ステータスの監視
26.9. ゲスト識別子の表示
26.10. Displaying a guest's status
26.11. 仮想 CPU の表示
26.12. CPU 使用量の表示
26.13. メモリー使用量の表示
26.14. 仮想ネットワークの管理
26.15. 仮想ネットワークの作成
27. xm コマンドのクイックリファレンス
28. Xen カーネルブートパラメータの設定
29. ELILO の設定
30. libvirt configuration reference
31. Xen 設定ファイル
VII. ヒントと裏技
32. ヒントと裏技
32.1. 自動的にゲストを開始
32.2. KVM と Xen hypervisor との間での切り替え
32.2.1. Xen から KVM へ
32.2.2. KVM から Xen へ
32.3. qemu-img の使用
32.4. Overcommitting Resources
32.5. /etc/grub.conf の修正
32.6. 仮想化拡張を確認
32.7. Accessing data from a guest disk image
32.8. Setting KVM processor affinities
32.9. 新規の特有 MAC アドレスを生成
32.10. Xen ゲスト用のネットワークバンド幅を制限
32.11. Xen プロセッサ類似物の設定
32.12. Xen hypervisor の修正
32.13. 非常にセキュアな ftpd
32.14. LUN 永続化の設定
32.15. ゲスト用の SMART ディスク監視を無効化
32.16. 古い Xen 設定ファイルを整理
32.17. VNC サーバーの設定
32.18. ゲスト設定ファイルのクローン
32.19. 既存ゲストとその設定ファイルを複製
33. カスタムの libvirt スクリプト作成
33.1. virsh を用いた XML 設定ファイルの使用
VIII. トラブルシューティング
34. Xen のトラブルシューティング
34.1. Xen でのデバッギングとトラブルシューティング
34.2. ログファイルの概要
34.3. ログファイルの説明
34.4. 重要ディレクトリの場所
34.5. ログを使用したトラブルシューティング
34.6. シリアルコンソールを使用したトラブルシューティング
34.7. Para-virtualized ゲストコンソールのアクセス
34.8. 完全仮想化ゲストコンソールのアクセス
34.9. 一般的な Xen の問題
34.10. ゲスト作成のエラー
34.11. シリアルコンソールを使用したトラブルシューティング
34.11.1. Xen 用のシリアルコンソール出力
34.11.2. para-virtualized ゲストからの Xen シリアルコンソール出力
34.11.3. 完全仮想化ゲストからのシリアルコンソール出力
34.12. Xen 設定ファイル
34.13. Xen エラーメッセージの解釈
34.14. ログディレクトリのレイアウト
35. トラブルシューティング
35.1. 利用可能なストレージとパーティションを判別する
35.2. Xen ベースのゲストを再起動した後にコンソールはフリーズ
35.3. 仮想化イーサネットデバイスはネットワーキングツールでは見付からない。
35.4. ループデバイスエラー
35.5. メモリー不足によるドメイン作成の失敗
35.6. 間違えたカーネルイメージのエラー
35.7. 間違えたカーネルイメージのエラー:PAE プラットフォーム上に非 PAE カーネル
35.8. 完全仮想化 64 bit ゲストが起動失敗
35.9. ローカルホストエントリの欠如が virt-manager の失敗原因
35.10. ゲスト起動時の Microcode エラー
35.11. 仮想マシン開始時での Python 低評価警告メッセージ
35.12. BIOS 内で、Intel VT と AMD-V の仮想化ハードウェア拡張を有効にする
35.13. KVM ネットワーキングパフォーマンス
36. Xen para-virtualized ドライバーのトラブルシューティング
36.1. Red Hat Enterprise Linux 5 仮想化のログファイルとディレクトリ
36.2. Para-virtualized ゲストは、Red Hat Enterprise Linux 3 のゲストオペレーティング システム上ではロードに失敗。
36.3. Red Hat Enterprise Linux 3 に para-virtualized ドライバーをインストールする時点に 警告メッセージ。
36.4. para-virtualized ドライバーを手動でロードする
36.5. para-virtualized ドライバーが正常にロードされたことを確認
36.6. システムは、para-virtualized ドライバーではスループットに制限があります
Glossary
A. その他のリソース
A.1. オンラインリソース
A.2. インストール済みドキュメント
B. Colophon

序文

The Red Hat Enterprise Linux Virtualization Guide covers all aspects of using and managing virtualization products included with Red Hat Enterprise Linux.

1. このマニュアルについて

This book is divided into 8 parts:
  • システムの要件
  • インストール
  • 設定
  • 管理
  • Storage
  • 参照事項
  • ヒントと裏技
  • トラブルシューティング
Key terms and concepts used throughout this book are covered in the Glossary.
This book covers virtualization topics for Red Hat Enterprise Linux 5. The KVM and Xen hypervisors are provided with Red Hat Enterprise Linux 5. Both the KVM and Xen hypervisors support Full virtualization. The Xen hypervisor also supports Para-virtualization. Refer to 「What is Virtualization?」 and the Glossary for more details on these terms.

2. 表記方法

本ガイドは特定の単語や語句を強調したり、 記載内容の特定部分に注意を引かせる目的で次のような表記方法を使用しています。
PDF版 および印刷版では、 Liberation Fonts セットから採用した書体を使用しています。 ご使用のシステムに Liberation Fonts セットがインストールされている場合、 HTML 版でもこのセットが使用されます。 インストールされていない場合は代替として同等の書体が表示されます。 注記: Red Hat Enterprise Linux 5 およびそれ以降のバージョンにはデフォルトで Liberation Fonts セットが収納されます。

2.1. 印刷における表記方法

特定の単語や語句に注意を引く目的で 4 種類の表記方法を使用しています。 その表記方法および適用される状況は以下の通りです。
等幅の太字
シェルコマンド、ファイル名、パスなどシステムへの入力を強調するために使用しています。またキー配列やキーの組み合わせを強調するのにも使用しています。 例えば、
現在作業中のディレクトリ内のファイル my_next_bestselling_novel の内容を表示させるには、 シェルプロンプトで cat my_next_bestselling_novel コマンドを入力してから Enter を押してそのコマンドを実行します。
上記にはファイル名、シェルコマンド、キーが含まれています。 すべて等幅の太字で表されているため文中内で見分けやすくなっています。
キーが 1 つの場合と複数のキーの組み合わせになる場合を区別するため、 その組み合わせを構成するキー同士をハイフンでつないでいます。 例えば、
Enter を押してコマンドを実行します。
1 番目の仮想ターミナルに切り替えるは、 Ctrl+Alt+F2 を押します。 X-Windows セッションに戻るには、 Ctrl+Alt+F1 を押します。
最初の段落では押すべき 1 つのキーを特定して強調しています。 次の段落では同時に押すべき 3 つのキーの組み合わせが 2 種類ありそれぞれ強調されています。
ソースコードの説明では 1 段落内で提示されるクラス名、 メソッド、 関数、 変数名、 戻り値を上記のように 等幅の太字 で表示します。 例えば、
ファイル関連のクラス群はファイルシステムに対しては filesystem、 ファイルには file、 ディレクトリには dir をそれぞれ含みます。 各クラスは個別に関連する権限セットを持っています。
プロポーショナルの太字
アプリケーション名、 ダイアログボックスのテキスト、ラベル付きボタン、 チェックボックスとラジオボタンのラベル、 メニュータイトルとサブメニュータイトルなどシステム上で見られる単語や語句を表します。 例えば、
メインメニューバーから システム > 個人設定 > マウス の順で選択し マウスの個人設定 を起動します。 ボタン タブ内で 左ききのマウス チェックボックスをクリックしてから 閉じる をクリックしマウスの主要ボタンを左から右に切り替えます (マウスを左ききの人が使用するのに適した設定にする)。
gedit ファイルに特殊な文字を挿入する場合は、 メインメニューバーから アプリケーション > アクセサリ > 文字マップ の順で選択します。 次に 文字マップ メニューバーから 検索 > 検索… と選択して 検索 フィールド内にその文字名を入力し をクリックします。 探している文字が 文字表 内で強調表示されます。 この強調表示された文字をダブルクリックすると コピーするテキスト フィールド内に置かれるので次に コピー ボタンをクリックします。 ここでドキュメントに戻り gedit メニューバーから 編集 > 貼り付け を選択します。
上記には、 アプリケーション名、 システム全体のメニュー名と項目、 アプリケーション固有のメニュー名、 GUI インタフェースで見られるボタンやテキストがあります。 すべてプロポーショナルの太字で表示されているため文中内で見分けやすくなっています。
等幅の太字で且つ斜体 または プロポーショナルの太字で且つ斜体
等幅の太字やプロポーショナルの太字はいずれであっても斜体の場合は置換可能なテキストか変化するテキストを示します。 斜体は記載されている通りには入力しないテキスト、あるいは状況に応じて変化する出力テキストを表します。 例えば、
ssh を使用してリモートマシンに接続するには、 シェルプロンプトで ssh username@domain.name と入力します。 リモートマシンが example.com であり、 そのマシンで使用しているユーザー名が john なら ssh john@example.com と入力します。
mount -o remount file-system コマンドは指定したファイルシステムを再マウントします。 例えば、 /home ファイルシステムを再マウントするコマンドは mount -o remount /home になります。
現在インストールされているパッケージのバージョンを表示するには、 rpm -q package コマンドを使用します。 結果として次を返してきます、 package-version-release
上記の太字斜体の単語 — username、 domain.name、 file-system、 package、 version、 release に注目してください。 いずれもコマンドを発行するときに入力するテキスト用のプレースホルダーかシステムにより出力されるテキスト用のプレースホルダーになっています。
タイトル表示のような標準的な使用の他、 斜体は新しい重要な用語が初めて出現する場合にも使用されます。 例えば、
Publican は DocBook の発行システムです。

2.2. 引用における表記方法

端末の出力とソースコード一覧は、視覚的に周囲の文から区別されています。
端末に送信される出力は mono-spaced roman (等幅の Roman) にセットされるので以下のように表示されます。
books        Desktop   documentation  drafts  mss    photos   stuff  svn
books_tests  Desktop1  downloads      images  notes  scripts  svgs
ソースコードの一覧も mono-spaced roman (等幅の Roman) でセットされますが、以下のように強調表示されます。
package org.jboss.book.jca.ex1;

import javax.naming.InitialContext;

public class ExClient
{
   public static void main(String args[]) 
       throws Exception
   {
      InitialContext iniCtx = new InitialContext();
      Object         ref    = iniCtx.lookup("EchoBean");
      EchoHome       home   = (EchoHome) ref;
      Echo           echo   = home.create();

      System.out.println("Created Echo");

      System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
   }
}

2.3. 注記および警告

情報が見過ごされないよう 3 種類の視覚的なスタイルを使用して注意を引いています。

注記

注記は説明している部分に対するヒントや近道あるいは代替となる手段などになります。注記を無視しても悪影響はありませんが知っておくと便利なコツを見逃すことになるかもしれません。

重要

重要ボックスは見逃しやすい事項を詳細に説明しています。現在のセッションにのみ適用される設定上の変更点、 更新を適用する前に再起動が必要なサービスなどがあります。重要ボックスを無視してもデータを喪失するような結果にはなりませんがイライラ感やフラストレーションが生じる可能性があります。

警告

警告は無視しないでください。警告を無視するとデータを喪失する可能性が非常に高くなります。

3. We need your feedback

If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you. Submit a report in Bugzilla: http://bugzilla.redhat.com/ against Red Hat Enterprise Linux with the Virtualization_Guide component.
When submitting a bug report, be sure to mention the manual's identifier: Virtualization_Guide and version number: 5.
If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, include the section number and some of the surrounding text so we can find it easily.

3.1. Technical review requests

All review requests are classified into one of the following five categories:
New content
content documented for the first time — an entirely new feature, procedure, or concept. For example: "Section now describes the new procedure for creating bootable USB devices."
Correction
a factual error previously present in the text has been corrected. For example: "Section previously stated (incorrectly) that IPv4 and IPv6 were both supported; section now states that IPv6 has never been supported."
Clarification
material that was already factually correct but is now better explained. Clarifications are usually in response to reader feedback that the previous content was confusing or misleading in some way. For example: "Paths described in Example 1.2.3 now better reflect the directory structure of an actual installed system."
Obsoletion
a description of a feature or a procedure has been dropped. Material might be obsolete because of a feature that is no longer supported, a known issue that has been corrected, or hardware that is now obsolete. For example, "Section no longer describes how to update kernel modules using a floppy disk."
Verification
a request to check a fact, procedure, or whether material should be obsoleted. For example, "Section describes how to connect to a generic iSCSI storage device. Please verify this on your hardware" or "Section still describes how to update kernel modules using a LS-120 SuperDisk; please verify that we still need to tell readers about this obsolete hardware."

4. What is Virtualization?

Virtualization is a broad computing term for running software, usually operating systems, concurrently and isolated from other programs on one system. Most existing implementations of virtualization use a hypervisor, a software layer that controls hardware and provides guest operating systems with access to underlying hardware devices. The hypervisor allows multiple operating systems to run on the same physical system by offering virtualized hardware to the guest operating system.

5. Types of Virtualization

5.1. Full Virtualization

Red Hat Enterprise Linux contains virtualization packages and tools which provide system administrators with the means to run fully virtualized, unmodified, operating system guests on Red Hat Enterprise Linux. This provides companies with the ability to consolidate older systems onto newer, more efficient hardware. This reduces physical space and operating costs involved with powering and cooling older, less efficient systems. Full virtualization incurs worse I/O performance than native, also known as bare-metal, installations of operating systems.

5.2. Para-Virtualization

Para-virtualization is a virtualization technique which involves running modified versions of operating systems. The para-virtualized operating system is modified to be aware that it is being virtualized, offering an increased ability for optimization as the guest is more aware of its environment. Performance is generally very close to running bare-metal, non-virtualized operating systems.

5.3. Para-virtualized drivers

These two techniques, para-virtualization and full virtualization, can be combined to allow unmodified operating systems to receive near native I/O performance by using para-virtualized drivers on fully virtualized operating systems. This guide covers installation and configuration of the Red Hat Enterprise Linux para-virtualized drivers package for fully virtualized Microsoft Windows® guests.
The para-virtualized drivers package contains storage and network device drivers for fully virtualized Microsoft Windows® guests. The drivers provide Microsoft Windows® guests running on Red Hat Enterprise Linux with enhanced disk and network I/O performance.

6. How CIOs should think about virtualization

by Lee Congdon, Chief Information Officer, Red Hat, Inc.
急速に進展する仮想化技術にすでに大規模な投資をされているかも知れません。その場合は、 以下に示してある提案の一部を考慮してこの技術の更なる活用をしてみて下さい。まだそのような投資をされていない場合は、今が開始するのに最適な時期です。
仮想化は柔軟性の増大とコスト低減の為のツールセットです。これらはどの企業や 情報技術でも重要な項目です。仮想化ソリューションは日増しに利用量が増えており、その機能も豊富になってきています。
仮想化は複数の分野で企業に重要な利便性を与えることが出来るため、パイロット企画を作り、専門家を育成することにより、仮想化技術をすぐに実践できるようにする ことをお薦めします。
改革のための仮想化
基本的に、仮想化はシステムでサポートされているオペレーティングシステムとサービスとアプリケーションを、特定のハードウェアから分離することにより柔軟性を増大します。これにより、共有のハードウェアプラットフォーム上で複数の仮想環境を確立することができるようになります。
改革を検討している企業は、追加のハードウェアを設置することなく(そして必要でなくなった時にはそれらのシステムとサービスを素早く廃止できる)新規のシステムとサービスを構築できる能力が改革への重要な原動力となることがお判りに なるはずです。
実行可能なアプローチとして、カスタムソフトウェアの作成の為の開発システムの迅速な確立、テスト環境を素早くセットアップする能力、大幅なハードウェア投資が不要な 代替ソフトウェアソリューションの装備とそれらの機能比較、迅速なプロトタイプ化と開発環境へのサポート、オンデマンドで対応できる新規プロダクションサービスの迅速な確立能力などが挙げられます。
これらの環境は、企業内部で、又は Amazon の EC2 のように外注で構築できます。 新規の仮想環境を構築するコストはかなり低くなる可能性があり、既存のハードウェアを 活用できるため、改革は最小限の投資で実践できて加速することができます。
仮想化は、また訓練と学習用の仮想環境の使用を通じて改革をサポートする点に於いても優れています。これらのサービスは仮想化技術の理想的な応用となります。学習者は 既知の標準的なシステム環境でコース学習を始めることができます。クラスでの操作は 実稼働ネットワークから隔離することが可能です。このようにして学習者は独占的な ハードウェアリソースの使用を要求することなく、独特なソフトウェア環境を確立 することができます。
仮想化環境の能力は発達を続けるため、特定ユーザーのニーズに適合するような ポータブル環境を有効にできる仮想化活用の日を迎える可能性があります。これらの環境は、ユーザーの存在位置に関係なくアクセス可能な又はローカルの、プロセス環境を動的に移動できるものです。ユーザーの環境はネットワーク上に保存されるか、あるいはポータブルメモリーデバイスに保存されます。
これに関連した概念として、仮想環境内で稼働するように設計されている アプリケーションパッケージ指向のオペレーティングシステムである Appliance Operating System があります。パッケージアプローチは、より低い開発とサポートのコストを維持し、アプリケーションが既知の安全な環境で稼働することを確実にします。Appliance Operating System ソリューションは これらのアプリケーションの開発者と消費者の両方に利便性を提供します。
仮想化技術のこれらのアプリケーションが企業で応用できる手段は各種あります。この技術をすでに上記に示してある分野の複数箇所で使用している場合は、迅速な開発を必要とするソリューションへ追加の投資を考慮してみて下さい。仮想化をまだ始めていない場合は、訓練と学習の実施によって技能を開発し、それからアプリケーションの開発とテストに進んで下さい。仮想化における幅広い経験を有する企業では、ポータブル仮想環境やアプリケーションアプライアンスをの実施を考慮してみて下さい。
コスト削減のための仮想化
仮想化はコスト削減にも利用できます。複数サーバーを統合することにより、仮想化環境の 集合を稼働する小規模でより強力なハードウェアプラットフォームのセットにする点で、 明確な利便性を得ることができます。ハードウェアの規模を減少し、未使用設備を 削減することでコストを低減するだけでなく、より強力なハードウェア上で仮想ゲストを実行することでアプリケーションのパフォーマンスは実際に向上します。
更なる利便性として、稼働を妨害しない方法でハードウェア能力を追加すること、作業負荷を利用可能なリソースに動的に移行できることなどが含まれます。
企業のニーズに応じて、災害からの復元の為の仮想環境を構築することも可能です。 仮想化の導入は同一ハードウェア環境複製の必要性を確実に低減し、そして低コストで災害シナリオのテスト設定も可能にすることができます。
仮想化は、ピーク時の作業負荷やシーズン変化の作業負荷への対応に優秀な ソリューションとなります。組織内に補完の作業能力がある場合、現在最大の作業需要を受けているアプリケーションにリソースを動的に割り当てることができます。組織内で現在供給している作業能力がピーク状態にある場合、オンディマンド式に外部からその余裕能力を仕入れて、仮想化技術を使用してそれを効率良く実装することができます。
サーバー統合によるコスト削減は効率的です。この目的で仮想化を活用されていない 場合は、 今すぐ、この計画を始めるべきです。仮想化の経験が増えるに従って作業負荷の均一化と 仮想化した災害復元環境からの利便性を追求できるようになります。
標準ソリューションとしての仮想化
企業の特定ニーズに関係なく、この技術は間違いなく普及していくことになりますから、 仮想化をシステムとアプリケーションのポートフォリオとして研究してみるべきです。 今後はオペレーティングシステムのベンダーが仮想化を標準のコンポーネントとして含み、 ハードウェアのベンダーがそのプラットフォームに仮想化機能を組込み、仮想化のベンダーがその提供物の範囲を拡張していくと予想されます。
ソリューションアーキテクチャの中にまだ仮想化を統合する計画をお持ちでない場合は、 パイロットプロジェクトを立ち上げて、あまり使用していない一部のハードウェアプラットフォームを割り当てて、この柔軟なコスト削減の技術で専門知識を開発するのには今が最適な時期です。その後は仮想ソリューションを統合するターゲットアーキテクチャを拡張していきます。既存のサービスを仮想化するだけでもかなりの 利便性を得ますが、統合化した仮想化戦略による新規のアプリケーション構築は 管理と可用性の両方で更なる利便性を与えてくれます。
Red Hat の仮想化ソリューションについては、http://www.redhat.com/products/ でもっと知ることが出来ます。

パート I. Red Hat Enterprise Linux での仮想化に於ける要件と制限

システムの要件、サポートの制約及び制限

この章では、Red Hat Enterprise Linux 上の仮想化に於けるシステムの要件とサポートの制約、 及び制限の概要を提供します。

第1章 システム要件

This chapter lists system requirements for successfully running virtualization with Red Hat Enterprise Linux. Virtualization is available for Red Hat Enterprise Linux 5 Server.
The requirements for virtualization vary depending on the type of hypervisor. The Kernel-based Virtual Machine (KVM) and Xen hypervisors are provided with Red Hat Enterprise Linux 5. Both the KVM and Xen hypervisors support Full virtualization. The Xen hypervisor also supports Para-virtualization.
For information on installing the virtualization packages, read 6章仮想化パッケージをインストール.
最低限のシステム要件
  • 6 GB の空きディスク領域
  • 2GB の RAM.

KVM オーバーコミット

KVM can overcommit physical resources for virtualized guests. Overcommiting resources means the total virtualized RAM and processor cores used by the guests can exceed the physical RAM and processor cores on the host. For information on safely overcommitting resources with KVM refer to 「Overcommitting Resources」.
Xen para-virtualization の要件
Para-virtualized ゲストは Red Hat Enterprise Linux 5 のインストールツリーを 必要とします。これは、NFS か、FTP か、 HTTP のプロトコルを使用して 入手できます。
Xen 完全仮想化の要件
Xen Hypervisor を持つ完全仮想化は以下を必要とします:
  • an Intel processor with the Intel VT extensions, or
  • AMD-V 拡張を持つ AMD プロセッサ 1つ、又は
  • Intel Itanium プロセッサ 1つ
Refer to 「仮想化拡張を確認」 to determine if your processor has the virtualization extensions.
KVM の要件
KVM hypervisor は以下を必要とします:
  • Intel VT 及び Intel 64 拡張を持つ Intel プロセッサ 1つ、又は
  • AMD-V と AMD64 拡張を持つ AMD プロセッサ 1つ
Refer to 「仮想化拡張を確認」 to determine if your processor has the virtualization extensions.
ストレージのサポート
サポートのあるゲストストレージの方法は以下のようになります:
  • Files on local storage
  • Physical disk partitions
  • Locally connected physical LUNs
  • LVM partitions
  • iSCSI and Fibre Channel based LUNs

ファイルベースゲストストレージ

File-based guest images are stored in the /var/lib/libvirt/images/ directory by default. If you use a different directory you must label the new directory according to SELinux policy. Refer to 「SELinux と仮想化」 for details.

第2章 Xen の制約とサポート

Red Hat Enterprise Linux 5 supports various architecture combinations for hosts and virtualized guests. All architectures have processor and memory limitations. Refer to the following URLs for the processor and memory amount limitations for Red Hat Enterprise Linux:
The following URL shows a complete chart of supported operating systems and host and guest combinations:

注記

To utilize para-virtualization on Red Hat Enterprise Linux 5, your processor must have the Physical Address Extension (PAE) instruction set.

Itanium® サポート

Virtualization with the Xen hypervisor on the Intel Itanium architecture requires the guest firmware image package, refer to yum を使用して Xen hypervisor をインストール for more information.

第3章 KVM の制約とサポート

The KVM hypervisor requires a processor with the Intel-VT or AMD-V virtualization extensions.
To verify whether your processor supports the virtualization extensions and for information on enabling the virtualization extensions if they are disabled, refer to 「仮想化拡張を確認」.
The following URLs explain the processor and memory amount limitations for Red Hat Enterprise Linux:
The following URL shows a complete chart of supported operating systems and host and guest combinations:

第4章 Hyper-V restrictions and support

Certification of guests running under the Microsoft Hyper-V server is conducted by Microsoft. Red Hat Enterprise Linux 5 is fully certified to run under the Microsoft Hyper-V server.

注記

To avoid timing errors when running Red Hat Enterprise Linux 5 under the Microsoft Hyper-V server, use the divider=10 option in the grub.conf file.

第5章 仮想化の制限

この章では、Red Hat Enterprise Linux の仮想化パッケージに於けるその他の 制限を説明しています。

5.1. 仮想化に於ける一般的制限

Converting between hypervisors
Presently, there is no support for converting Xen-based guests to KVM or KVM-based guests to Xen. Guests can only be supported on the hypervisor type on which they were created. However, at the time of writing, a tool is in development which may be released with future versions of Red Hat Enterprise Linux.
他の制限
For other details affecting virtualization, refer to the Red Hat Enterprise Linux Release Notes at http://docs.redhat.com for your version. The Release Notes cover the present new features, known issues and limitations as they are updated or discovered.
導入前のテスト
You should test for the maximum anticipated system and virtualized network load before deploying heavy I/O applications. Load testing and planning are important as virtualization performance can suffer due to high I/O usage.

5.2. KVM の制限

以下の制限が KVM hypervisor に適用されます:
不変 TSC ビット
Systems without a Constant Time Stamp Counter require additional configuration. Refer to 16章KVM ゲストのタイミング管理 for details on determining whether you have a Constant Time Stamp Counter and configuration steps for fixing any related issues.
メモリーオーバーコミット
KVM supports memory overcommit and can store the memory of guests in swap. A guest will run slower if it is swapped frequently. When Kernel SamePage Merging (KSM) is used, make sure that the swap size is equivalent to the size of the overcommit ratio.
CPU オーバーコミット
物理プロセッサコア毎に10以上の仮想 CPU を持つことはサポートされていません。 そして物理プロセッサコアの数を越えたオーバーコミットの仮想 CPU の数は 特定の仮想化ゲストで問題になる可能性があります。
Overcommitting CPUs has some risk and can lead to instability. Refer to 「Overcommitting Resources」 for tips and recommendations on overcommitting CPUs.
仮想化 SCSI デバイス
SCSI emulation is presently not supported. Virtualized SCSI devices are disabled in KVM.
仮想化 IDE デバイス
KVM はゲスト毎に最大6つの仮想化(模倣)IDE デバイスに制限されています。
Para-virtualized デバイス
Para-virtualized デバイスは virtio ドライバーと PCI デバイスを使用します。現時点では、ゲストは最大 32 PCI デバイスまでに 制限されています。一部の PCI デバイスはゲストの実行に重要なものであり、これらの デバイスは削除できません。デフォルトで以下のようなデバイスが必須です:
  • ホストブリッジ
  • ISA ブリッジと usb ブリッジ(usb と isa のブリッジは同じデバイスです)
  • グラフィックカード(Cirrus か qxl のドライバーを使用)
  • メモリーバルーンデバイス
ゲスト用に最大利用可能な32 の PCI デバイスの内、4つは削除できません。このことは、 ゲスト毎に、28 PCI スロットのみが追加デバイス用に利用できると言うことです。それぞれの para-virtualized ネットワーク、又はブロックデバイスが1つのスロットを使用します。 そのため、各ゲストは para-virtualized ネットワークと para-virtualized ディスクデバイスと VT-d を使用している他の PCI デバイスの組合せから 28 までの追加デバイスを使用できることになります。
移行の制限
ライブ移行は同じベンダー(即ち、Intel と Intel、あるいは AMD と AMD)のみからの CPU 群で 可能になります。
ライブ移行には、No eXecution (NX) ビットは 両方の CPU 用にオンでもオフでもセット しなければなりません。
Storage limitations
The host should not use disk labels to identify file systems in the fstab file, the initrd file or used by the kernel command line. If less privileged users, especially virtualized guests, have write access to whole partitions or LVM volumes the host system could be compromised.
Guests should not be given write access to whole disks or block devices (for example, /dev/sdb). Virtualized guests with access to block devices may be able to access other block devices on the system or modify volume labels which can be used to compromise the host system. Use partitions (for example, /dev/sdb1) or LVM volumes to prevent this issue.

5.3. Xen の制限

注記

All limitations in this chapter are limitations for Red Hat Enterprise Linux 5.8 except where noted. Older versions may have fewer limitations.
Xen ホスト (dom0) の制限
  • A limit of 254 para-virtualized block devices per host. The total number of block devices (using the tap:aio driver) attached to virtualized guests cannot exceed 254 devices.

para-virtualized デバイス制限問題の回避

There are two methods for working around the para-virtualized device limit: using phy devices (devices using the physical access mode) or using LVM on the guest.
ホストが十分なリソースを持っていれば、それが所有できる phy デバイスの数には制限がありません。
LVM、又は同様な論理パーティション設定ツールは、ブロックデバイス上で使用して 単独の para-virtualized ブロックデバイスに追加の論理パーティションを作成する ことができます。
Xen Para-virtualization の制限
  • For x86 guests, a maximum of 16GB memory per guest.
  • For x86_64 guests, a maximum of 168GB memory per guest.
  • A maximum of 254 devices per virtualized guest.
  • 仮想化ゲスト毎に最大 15 のネットワークデバイス
Xen 完全仮想化の制限
  • For x86 guests, a maximum of 16GB memory per guest.
  • ゲスト毎に最大 4つの仮想化(模倣)IDE デバイス
    完全仮想化ゲスト用に para-virtualized ドライバーを使用するデバイスは この制限を受けません。
  • Virtualized (emulated) IDE devices are limited by the total number of loopback devices supported by the system. The default number of available loopback devices on Red Hat Enterprise Linux 5.8 is 8. That is, by default, all virtualized guests on the system can each have no more than 8 virtualized (emulated) IDE devices.
    For more information on loopback devices, refer to the Red Hat KnowledgeBase, article DOC-1722.

    8つ以上のループバックデバイスの使用

    デフォルトでは、Red Hat Enterprise Linux は利用可能なループバックデバイスの 数を制限しています。この数はカーネルの制限を解除することにより増加することが できます。
    /etc/modprobe.conf 内で、以下の行を追加します:
    options loop max_loop=64
    
    Reboot the machine or run the following commands to update the kernel with this new limit:
    # rmmod loop
    # modprobe loop
    
  • A limit of 254 para-virtualized block devices per host. The total number of block devices (using the tap:aio driver) attached to virtualized guests cannot exceed 254 devices.
  • A maximum of 254 block devices using the para-virtualized drivers per virtualized guest.
  • 仮想化ゲスト毎に最大 15 のネットワークデバイス
  • 仮想化ゲスト毎に最大 15 仮想化 SCSI デバイスです。
PCI passthrough limitations
  • PCI passthrough (attaching PCI devices to guests) is presently only supported on the following architectures:
    • 32 bit (x86) systems.
    • Intel 64 systems.
    • Intel Itanium 2 systems.

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

特定タイプのアプリケーションに対して仮想化が不適切になるような 仮想化の側面がいくつか存在します。
高い I/O スループットの要求を持つアプリケーションは、完全仮想化用の para-virtualized ドライバーを使用すべきです。para-virtualized ドライバーが無いと、 特定のアプリケーションは高い I/O 負荷では不安定になります。
以下のアプリケーションはそれらの高度な I/O 要求の為に回避すべきです:
  • kdump サーバー
  • netdump サーバー
You should carefully evaluate database applications before running them on a virtualized guest. Databases generally use network and storage I/O devices intensively. These applications may not be suitable for a fully virtualized environment. Consider para-virtualization or para-virtualized drivers in these cases for increased I/O performance.
Other applications and tools which heavily utilize I/O or require real-time performance should be evaluated carefully. Using full virtualization with the para-virtualized drivers or para-virtualization results in better performance with I/O intensive applications. Applications still suffer a small performance loss from running in virtualized environments. The performance benefits of virtualization through consolidating to newer and faster hardware should be evaluated against the potential application performance issues associated with using fully virtualized hardware.

パート II. インストール

第6章 仮想化パッケージをインストール

仮想化を使用できるようにするためには、仮想化パッケージが Red Hat Enterprise Linux 上に インストールされている必要があります。仮想化パッケージはインストールシーケンスの 途中か、又は yum コマンドと Red Hat Network (RHN) を 使用してインストールの後にインストールすることが出来ます。
単一のシステムに KVM hypervisor と Xen hypervisor の両方をインストールすることが できます。Xen hypervisor は kernel-xen パッケージを使用し、 KVM hypervisor は kvm カーネルモジュールを持つデフォルトの Red Hat Enterprise Linux カーネルを使用します。Xen と KVM はそれぞれ異なるカーネルを 使用し、任意の時点にどちらかの hypervisor の1つのみがアクティブになることができます。 Red Hat では、ユーザーが仮想化に使用する予定の hypervisor の一方だけをインストールする ことを推奨します。
To change hypervisor from Xen to KVM or KVM to Xen refer to 「KVM と Xen hypervisor との間での切り替え」.

6.1. Red Hat Enterprise Linux の新規インストールで Xen を インストール

このセクションは、Red Hat Enterprise Linux の新規インストールの一部として、 仮想化ツールと Xen パッケージのインストールを説明しています。

インストールに援助が必要ですか?

The Installation Guide (available from redhat.com) covers installing Red Hat Enterprise Linux in detail.
  1. Red Hat Enterprise Linux のインストール CD-ROM、DVD、あるいは PXE から 対話式の Red Hat Enterprise Linux インストールを開始します。
  2. You must enter a valid installation number when prompted to receive access to the virtualization and other Advanced Platform packages. Installation numbers can be obtained from Red Hat Customer Service.
  3. Complete all steps until you see the package selection step.
    仮想化(Virtualization) パッケージグループを選択して、 今、カスタマイズする(Customize Now) ラジオボタンを選択します。
  4. Virtualization パッケージグループを選択します。 Virtualization パッケージグループは Xen hypervisor、virt-managerlibvirt、及び virt-viewer、それにインストール用のすべての依存関係を選択します。
  5. パッケージをカスタマイズ(必要な場合)

    他の仮想化パッケージが必要な場合は、Virtualization グループを カスタマイズします。
    Press the Close button then the Forward button to continue the installation.

注記

仮想化パッケージに更新を受け取るには、有効な RHN 仮想化のエンタイトルメントが 必要です。
キックスタートファイルで Xen パッケージをインストール
このセクションでは、Xen hypervisor パッケージを用いた Red Hat Enterprise Linux のインストールに於けるキックスタートファイルの使用法を 説明します。キックスタートファイルは各システムにユーザーの手動インストール無しで 大規模な自動化したインストールを可能にします。このセクション内のステップは、仮想化パッケージを持つ Red Hat Enterprise Linux のインストールの為にユーザーが キックスタートファイルの作成とその使用をするためのお手伝いをします。
使用するキックスタートファイルの %packages セクションで、以下のパッケージグループを追記します:
%packages
@xen

Intel Itanium システム用

Fully virtualized guests on the Itanium® architecture require the guest firmware image package (xen-ia64-guest-firmware). Append the following package to your kickstart file:
xen-ia64-guest-firmware
More information on Kickstart files can be found on Red Hat's website, redhat.com, in the Installation Guide.

6.2. 既存の Red Hat Enterprise Linux システムに Xen パッケージをインストール

このセクションは、稼働可能な Red Hat Enterprise Linux システムに仮想化パッケージを インストールするのに必要なステップを説明しています。
Red Hat Network エンタイトルメントの一覧にパッケージを追加
このセクションでは、仮想化パッケージ用の Red Hat Network (RHN) エンタイトルメントを 有効にする方法を説明します。Red Hat Enterprise Linux 上に仮想化パッケージをインストールして それを更新するのにこれらのエンタイトルメントが必要になります。Red Hat Enterprise Linux に 仮想化パッケージをインストールするためには、有効な Red Hat Network アカウントが要求されます。
更に、ご使用のマシンが RHN で登録される必要があります。未登録の Red Hat Enterprise Linux インストールを 登録するには、rhn_register コマンドを実行して、プロンプトに従います。
有効な Red Hat サブスクリプション(購読)をお持ちでない場合は、 Red Hat オンラインストア をご覧ください。
手順6.1 RHN を使用して仮想化エンタイトルメントを追加
  1. お持ちの RHN ユーザー名とパスワードを使用して RHN に ログインします。
  2. 仮想化のインストール先となるシステムを選択します。
  3. システムのプロパティ セクションでは、現在のシステム用の エンタイトルメントが エンタイトルメント のヘッディングの 横に一覧表示してあります。このプロパティを編集 リンクを 使用するとエンタイトルメントを変更することが出来ます。
  4. Virtualization チェックボックスを選択します。
ご使用のシステムはこれで、仮想化パッケージを受け取るエンタイトルメントを 持つようになりました。次のセクションでは、これらのパッケージのインストール法を説明しています。
yum を使用して Xen hypervisor をインストール
Red Hat Enterprise Linux 上で仮想化を使用するには、xenkernel-xen のパッケージが必要になります。xen パッケージには 、 Xen hypervisor と 基本的仮想化の ツールが含まれています。kernel-xen パッケージには、 Xen hypervisor 上で仮想マシンゲストとして稼働する修正した linux カーネルが含まれています。
xenkernel-xen のパッケージを インストールするには、以下を実行します:
# yum install xen kernel-xen
Itanium® アーキテクチャ上の 完全仮想化ゲストには、補足のインストール DVD からゲストファームウェアイメージ パッケージ (xen-ia64-guest-firmware) が必要になります。 このパッケージは yum コマンドを使用して RHN から インストールすることもできます:
# yum install xen-ia64-guest-firmware
It is advised to install additional virtualization packages for management and configuration. 推奨される仮想化パッケージ: lists the recommended packages.
推奨されるその他の仮想化パッケージをインストールします:
# yum install virt-manager libvirt libvirt-python python-virtinst

6.3. Red Hat Enterprise Linux の新規インストールで KVM をインストール

このセクションは Red Hat Enterprise Linux の新規インストールの一部として仮想化ツールと KVM の インストールを説明しています。

インストールに援助が必要ですか?

The Installation Guide (available from redhat.com) covers installing Red Hat Enterprise Linux in detail.

有効なインストール番号が必要です。

有効なインストール番号が無いとインストール中に仮想化パッケージを選択できません。
  1. Red Hat Enterprise Linux のインストール CD-ROM、DVD、あるいは PXE から 対話式の Red Hat Enterprise Linux インストールを開始します。
  2. プロンプトが出たら、有効なインストール番号を入力して、仮想化と他の高度なプラットフォーム パッケージへのアクセス権を受理するようにします。
  3. Complete all steps up to the package selection step.
    仮想化(Virtualization) パッケージグループを選択して、 今、カスタマイズする(Customize Now) ラジオボタンを選択します。
  4. KVM パッケージグループを選択します。Virtualization パッケージグループを選択解除します。これでインストールのために KVM hypervisor、virt-managerlibvirt、及び virt-viewer を選ぶことになります。
  5. パッケージをカスタマイズ(必要な場合)

    他の仮想化パッケージが必要な場合は、Virtualization グループを カスタマイズします。
    Press the Close button then the Forward button to continue the installation.

注記

仮想化パッケージに更新を受け取るには、有効な RHN 仮想化のエンタイトルメントが 必要です。
キックスタートファイルで KVM パッケージをインストール
このセクションは KVM hypervisor パッケージを用いた Red Hat Enterprise Linux をインストールをするためのキックスタートファイルの使用法を説明します。 キックスタートファイルは、各個別のシステム用にユーザーの手動インストール無しで大規模な 自動化インストールを可能にします。このセクション内のステップは、仮想化パッケージを持つ Red Hat Enterprise Linux のインストールの為にユーザーが キックスタートファイルの作成とその使用をするためのお手伝いをします。
使用するキックスタートファイルの %packages セクションで、以下のパッケージグループを追記します:
%packages
@kvm
More information on Kickstart files can be found on Red Hat's website, redhat.com, in the Installation Guide.

6.4. 既存の Red Hat Enterprise Linux システムに KVM パッケージをインストール

このセクションでは、稼働可能な Red Hat Enterprise Linux 5.4 又はそれ以降のシステムに KVM hypervisor をインストールするためのステップを説明しています。
Red Hat Network エンタイトルメントの一覧にパッケージを追加
このセクションでは、仮想化パッケージ用の Red Hat Network (RHN) エンタイトルメントを 有効にする方法を説明します。Red Hat Enterprise Linux 上に仮想化パッケージをインストールして それを更新するのにこれらのエンタイトルメントが必要になります。Red Hat Enterprise Linux に 仮想化パッケージをインストールするためには、有効な Red Hat Network アカウントが要求されます。
更に、ご使用のマシンが RHN で登録される必要があります。未登録の Red Hat Enterprise Linux インストールを 登録するには、rhn_register コマンドを実行して、プロンプトに従います。
有効な Red Hat サブスクリプション(購読)をお持ちでない場合は、 Red Hat オンラインストア をご覧ください。
手順6.2 RHN を使用して仮想化エンタイトルメントを追加
  1. お持ちの RHN ユーザー名とパスワードを使用して RHN に ログインします。
  2. 仮想化のインストール先となるシステムを選択します。
  3. システムのプロパティ セクションでは、現在のシステム用の エンタイトルメントが エンタイトルメント のヘッディングの 横に一覧表示してあります。このプロパティを編集 リンクを 使用するとエンタイトルメントを変更することが出来ます。
  4. Virtualization チェックボックスを選択します。
ご使用のシステムはこれで、仮想化パッケージを受け取るエンタイトルメントを 持つようになりました。次のセクションでは、これらのパッケージのインストール法を説明しています。
yum を使用して KVM hypervisor をインストール
Red Hat Enterprise Linux 上で仮想化を使用するには、kvm パッケージが必要になります。kvm パッケージには 、KVM カーネルモジュールが含まれており、 デフォルトの Red Hat Enterprise Linux カーネル上に KVM hypervisor を提供します。
kvm パッケージをインストールするには、以下を実行します:
# yum install kvm
ここで、追加の仮想化管理パッケージをインストールします。
推奨されるその他の仮想化パッケージをインストールします:
# yum install virt-manager libvirt libvirt-python python-virtinst

第7章 仮想化ゲストインストールの概要

仮想化パッケージをホストシステム上にインストールした後は、ゲスト オペレーティングシステムの作成が可能になります。この章では、仮想マシン上に ゲストオペレーティングシステムをインストールする為の手順を説明します。 ゲストを作成するには、virt-manager 内の 新規ボタンをクリックするか、又はコマンドライン インターフェイス virt-install を使用します。 これらの両方の方法はこの章で説明されています。
Detailed installation instructions are available for specific versions of Red Hat Enterprise Linux, other Linux distributions and Windows. Refer to 8章ゲストオペレーティングシステムのインストール手順 for those procedures.

7.1. virt-install を使用してゲストを作成

コマンドラインから virt-install コマンドを使用して、 仮想化ゲストを作成することができます。virt-install は 対話式か、あるいはスクリプトによる自動化で仮想マシンを作成することが できます。キックスタートファイルで virt-install を使用すると 仮想化マシンの無人インストールが可能になります。
virt-install ツールは、コマンドラインで渡すことのできる 多くのオプションを提供します。それらのオプションの完全一覧を見るには、次を実行します:
$ virt-install --help
virt-install man ページはコマンドオプションと重要な変数を それぞれドキュメント化しています。
qemu-img は関連したコマンドであり、ストレージオプションを 設定する為に virt-install の前に使用することができます。
An important option is the --vnc option which opens a graphical window for the guest's installation.
例7.1 KVM を使用した virt-install で Red Hat Enterprise Linux 3 のゲストを作成
この例では、仮想ネットワーキングと 5 GB のファイルベースブロックデバイスイメージを 使用して、CD-ROM から rhel3support と言う名前の Red Hat Enterprise Linux 3 ゲストを作成します。この例は KVM hypervisor を使用します。
# virt-install --accelerate --hvm --connect qemu:///system \
   --network network:default \
   --name rhel3support --ram=756\
   --file=/var/lib/libvirt/images/rhel3support.img \
   --file-size=6 --vnc --cdrom=/dev/sr0

例7.2 virt-install を使用して fedora 11 ゲストを作成
# virt-install --name fedora11 --ram 512 --file=/var/lib/libvirt/images/fedora11.img \
	--file-size=3 --vnc --cdrom=/var/lib/libvirt/images/fedora11.iso

7.2. virt-manager を使用してゲストを作成

仮想マシンマネージャとして知られる virt-manager は 仮想化ゲストの作成と管理の為のグラフィカルツールです。
手順7.1 virt-manager を使用して仮想化ゲストを作成
  1. Open virt-manager

    Start virt-manager. Launch the Virtual Machine Manager application from the Applications menu and System Tools submenu. Alternatively, run the virt-manager command as root.
  2. Optional: Open a remote hypervisor

    Open the File -> Add Connection. The dialog box below appears. Select a hypervisor and click the Connect button:
  3. Create a new guest

    virt-manager ウィンドウでは、新しい 仮想マシンの作成ができます。新規 ボタンを使用して 新しいゲストを作成します。これによりスクリーンショットで示してあるウィザードが 開きます。
  4. New guest wizard

    The Create a new virtual machine window provides a summary of the information you must provide in order to create a virtual machine:
    使用するインストールの情報を再確認して、進む ボタンを クリックします。
  5. Name the virtual machine

    Provide a name for your virtualized guest. Punctuation and whitespace characters are not permitted in versions before Red Hat Enterprise Linux 5.5. Red Hat Enterprise Linux 5.5 adds support for '_', '.' and '-' characters.
    Press Forward to continue.
  6. Choose virtualization method

    仮想化の方法を選択 ウィンドウが出てきます。 Para-virtualized完全仮想化 の どちらかを選択して下さい。
    完全仮想化には、Intel® VT、又は AMD-V プロセッサが必要になります。仮想化の拡張が 存在しない場合は、完全仮想化 ラジオボタン、あるいは カーネル/ハードウェアアクセラレーションを有効にする は選択 出来ません。 Para-virtualized オプションは、kernel-xen が その時点のカーネルとして稼働していない場合は、灰色になって使用不可になっています。
    KVM hypervisor に接続すると、完全仮想化のみが利用可能になります。
    Choose the virtualization type and click the Forward button.
  7. Select the installation method

    The Installation Method window asks for the type of installation you selected.
    Guests can be installed using one of the following methods:
    Local media installation
    This method uses a CD-ROM or DVD or an image of an installation CD-ROM or DVD (an .iso file).
    Network installation tree
    This method uses a mirrored Red Hat Enterprise Linux installation tree to install guests. The installation tree must be accessible using one of the following network protocols: HTTP, FTP or NFS.
    The network services and files can be hosted using network services on the host or another mirror.
    Network boot
    This method uses a Preboot eXecution Environment (PXE) server to install the guest. Setting up a PXE server is covered in the Red Hat Enterprise Linux Deployment Guide. Using this method requires a guest with a routable IP address or shared network device. Refer to 10章ネットワークの設定 for information on the required networking configuration for PXE installation.
    Set the OS type and OS variant.
    Choose the installation method and click Forward to proceed.

    Para-virtualized guest installation

    Para-virtualized installation must be installed with a network installation tree. The installation tree must be accessible using one of the following network protocols: HTTP, FTP or NFS. The installation media URL must contain a Red Hat Enterprise Linux installation tree. This tree is hosted using NFS, FTP or HTTP.
  8. Installation media selection

    This window is dependent on what was selected in the previous step.
    1. ISO image or physical media installation

      If Local install media was selected in the previous step this screen is called Install Media.
      Select the location of an ISO image or select a DVD or CD-ROM from the dropdown list.
      Click the Forward button to proceed.
    2. Network install tree installation

      If Network install tree was selected in the previous step this screen is called Installation Source.
      Network installation requires the address of a mirror of a Linux installation tree using NFS, FTP or HTTP. Optionally, a kickstart file can be specified to automated the installation. Kernel parameters can also be specified if required.
      Click the Forward button to proceed.
    3. Network boot (PXE)

      PXE installation does not have an additional step.
  9. Storage setup

    The Storage window displays. Choose a disk partition, LUN or create a file-based image for the guest storage.
    All image files are stored in the /var/lib/libvirt/images/ directory by default. In the default configuration, other directory locations for file-based images are prohibited by SELinux. If you use a different directory you must label the new directory according to SELinux policy. Refer to 「SELinux と仮想化」 for details.
    Your guest storage image should be larger than the size of the installation, any additional packages and applications, and the size of the guests swap file. The installation process will choose the size of the guest's swap based on size of the RAM allocated to the guest.
    アプリケーションや他のデータの為にゲストが追加のスペースを必要とする場合には、 余分のスペースを割り当てます。例えば、ウェブサービスはログファイルの為に追加の スペースを必要とします。
    選択したストレージタイプでゲスト用に適切なサイズを選びます。それから 進む ボタンをクリックします。

    注記

    It is recommend that you use the default directory for virtual machine images, /var/lib/libvirt/images/. If you are using a different location (such as /images/ in this example) make sure it is added to your SELinux policy and relabeled before you continue with the installation (later in the document you will find information on how to modify your SELinux policy).
  10. Network setup

    Select either Virtual network or Shared physical device.
    The virtual network option uses Network Address Translation (NAT) to share the default network device with the virtualized guest. Use the virtual network option for wireless networks.
    The shared physical device option uses a network bond to give the virtualized guest full access to a network device.
    Press Forward to continue.
  11. Memory and CPU allocation

    The Memory and CPU Allocation window displays. Choose appropriate values for the virtualized CPUs and RAM allocation. These values affect the host's and guest's performance.
    ゲストは効率的にそして効果的に稼働するために十分な物理メモリー(RAM) を必要とします。 ゲストオペレーティングシステムとアプリケーションの要件に適したメモリーの値を選択します。 ほとんどのオペレーティングシステムは反応良く機能するのに少なくとも 512MB の RAM を 必要とします。ゲストは物理 RAM を使用することを忘れないで下さい。稼働ゲストが多すぎたり、 ホストシステム用に十分なメモリーを残さなかったりすると仮想メモリーをかなり消費してしまいます。 仮想メモリーは比較的に遅いため、システムパフォーマンスと反応性に悪影響を与えます。全ての ゲストとホストが効率的に稼働できるように十分なメモリーを割り当てることを確認して下さい。
    十分な仮想 CPU を仮想ゲストに割り当てます。ゲストがマルチスレッドのアプリケーションを 実行している場合は、ゲストが効率的に稼働できるのに必要な数の仮想化 CPU を割り当てます。 しかし、ホストシステム上で利用できる物理プロセッサ(又はハイパースレッド)以上の 仮想 CPU を割り当てないで下さい。仮想プロセッサを超過して割り当てることは可能ですが、 超過割り当てでは、プロセッサコンテキストがオーバーヘッドを切り替えるため、ゲストとホストに 深刻な悪影響を与えます。
    Press Forward to continue.
  12. Verify and start guest installation

    The Finish Virtual Machine Creation window presents a summary of all configuration information you entered. Review the information presented and use the Back button to make changes, if necessary. Once you are satisfied click the Finish button and to start the installation process.
    VNC ウィンドウが開いて、ゲストオペレーティングシステムのインストールプロセスの 開始を示します。
This concludes the general process for creating guests with virt-manager. 8章ゲストオペレーティングシステムのインストール手順 contains step-by-step instructions to installing a variety of common operating systems.

7.3. PXE を使用してゲストのインストール

このセクションでは、PXE を使用したゲストのインストールに必要な手順を説明します。 PXE のゲストインストールには、ネットワークブリッジとして知られる共有ネットワーク デバイスが必要になります。以下の手順はブリッジの作成法と PXE インストール用の ブリッジの活用に必要なステップを扱っています。
  1. 新規ブリッジの作成

    1. /etc/sysconfig/network-scripts/ ディレクトリ内に新規の ネットワークスクリプトファイルを作成します。ここの例では、ifcfg-installation と 言う名前のファイルを作成し、それが installation と言う名前のブリッジを 作ります。
      # cd /etc/sysconfig/network-scripts/
      # vim ifcfg-installation
      DEVICE=installation
      TYPE=Bridge
      BOOTPROTO=dhcp
      ONBOOT=yes
      

      警告

      The line, TYPE=Bridge, is case-sensitive. It must have uppercase 'B' and lower case 'ridge'.
    2. Start the new bridge by restarting the network service. The ifup installation command can start the individual bridge but it is safer to test the entire network restarts properly.
      # service network restart
      
    3. この時点では、まだブリッジにインターフェイスが追加されていません。brctl show コマンドを使用してシステム上のネットワークブリッジの詳細を見ることが できます。
      # brctl show
      bridge name     bridge id               STP enabled     interfaces
      installation    8000.000000000000       no
      virbr0          8000.000000000000       yes
      
      virbr0 ブリッジとは、デフォルトのイーサネットデバイス上の NAT (Network Address Translation) のための libvirt で使用される デフォルトのブリッジです。
  2. 新規ブリッジにインターフェイスを追加

    インターフェイス用の設定ファイルを編集します。先の手順で作成されたブリッジの 名前を持つ設定ファイルへ BRIDGE パラメータを追加 します。
    # Intel Corporation Gigabit Network Connection
    DEVICE=eth1
    BRIDGE=installation
    BOOTPROTO=dhcp
    HWADDR=00:13:20:F7:6E:8E
    ONBOOT=yes
    
    設定ファイルの編集の後に、ネットワークを再スタートするか又はリブートします。
    # service network restart
    
    brctl show コマンドを使用してインターフェイスが添付 されていることを確認します:
    # brctl show
    bridge name     bridge id               STP enabled     interfaces
    installation    8000.001320f76e8e       no              eth1
    virbr0          8000.000000000000       yes
    
  3. セキュリティの設定

    iptables を設定して全てのトラフィックがブリッジまで 転送されるようにします。
    # iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
    # service iptables save
    # service iptables restart
    

    ブリッジ上の iptables を無効化

    別の方法として、ブリッジ化したトラフィックが iptables によって プロセスされるのを阻止します。/etc/sysctl.conf 内で以下の行を 追加します:
    net.bridge.bridge-nf-call-ip6tables = 0
    net.bridge.bridge-nf-call-iptables = 0
    net.bridge.bridge-nf-call-arptables = 0
    
    設定されたカーネルパラメータを sysctl で再ロードします。
    # sysctl -p /etc/sysctl.conf
    
  4. インストールの前に libvirt を再スタート

    libvirt デーモンの再スタート
    # service libvirtd reload
    
ブリッジは設定終了です。これでインストールを開始できます。
virt-install を使用した PXE インストール
virt-install--network=bridge:installation インストールパラメータを追記します。ここで installation とは、該当ブリッジの名前です。PXE インストールには、--pxe パラメータを使用します。
例7.3 virt-install を使用した PXE インストール
# virt-install --accelerate --hvm --connect qemu:///system \
    --network=bridge:installation --pxe\
    --name EL10 --ram=756 \
    --vcpus=4
    --os-type=linux --os-variant=rhel5
    --file=/var/lib/libvirt/images/EL10.img \

virt-manager を使用した PXE インストール
The steps below are the steps that vary from the standard virt-manager installation procedures. For the standard installations refer to 8章ゲストオペレーティングシステムのインストール手順.
  1. PXE を選択

    インストールメソッドとして PXE を選択。
  2. ブリッジの選択

    物理デバイスを共有 を選択して、先の手順で作成してある ブリッジを選択します。
  3. インストールの開始

    インストールの開始準備が出来ています。
DHCP 要求が送信されて、有効な PXE サーバーが見付かるとゲストインストールの プロセスが始まります。

第8章 ゲストオペレーティングシステムのインストール手順

This chapter covers how to install various guest operating systems in a virtualized environment on Red Hat Enterprise Linux. To understand the basic processes, refer to 7章仮想化ゲストインストールの概要.

重要

When installing a Red Hat Enterprise Linux guest, the installer will ask to perform an integrity check on your installation source (CD/DVD media, or ISO file). If you select to perform the check, once the media is tested and the installation continues, you may encounter a message that states: The Red Hat Enterprise Linux Server CD was not found in any of your CDROM drives. Please insert the Red Hat Enterprise Linux Server CD and press OK to retry.
This behavior is intentional, provided as a convenience to make sure media is ejected in case a CD install (requiring multiple discs/images) is being performed as opposed to a DVD install.
To proceed past this message, make sure you either insert the next CD, or edit the guest's XML file specifying the next ISO file (or re-insert the DVD media). Next, run virsh update-device Guest1 ~/Guest1.xml (substituting your guest's name and XML file), and select OK to continue past this step.

8.1. Red Hat Enterprise Linux 5.0 を para-virtualized ゲストとしてインストール

このセクションでは、Red Hat Enterprise Linux 5 を para-virtualized ゲストとしてインストール する方法を説明します。Para-virtualization は完全仮想化よりも迅速であり、完全仮想化の 全ての利便性をサポートしています。Para-virtualization は特別なサポートのある kernel-xen カーネルを必要とします。

para-virtualization に関する重要な注記

Para-virtualization は Xen hypervisor とでのみ機能します。Para-virtualization は KVM hypervisor とでは機能しません。
インストールを開始する前に root アクセスがあることを確認して下さい。
この方法は Red Hat Enterprise Linux をリモートサーバーからインストールします。 このセクションに示されているインストール案内は、最低限インストールのライブ CD-ROM からのインストールに似ています。
Create para-virtualized Red Hat Enterprise Linux 5 guests using virt-manager or virt-install. For instructions on virt-manager, refer to the procedure in 「virt-manager を使用してゲストを作成」.
コマンドラインベースの virt-install ツールを使用して para-virtualized ゲストを作成します。--vnc オプションは、 グラフィックインストールを表示します。この例中のゲストの名前は rhel5PV であり、 ディスクイメージファイルは rhel5PV.dsk となり、Red Hat Enterprise Linux 5 のインストールツリーのローカルミラーは ftp://10.1.1.1/trees/RHEL5-B2-Server-i386/ となります。これらの値をご使用のシステムとネットワーク用に 的確なものに変更して下さい。
# virt-install -n rhel5PV -r 500 \
-f /var/lib/libvirt/images/rhel5PV.dsk -s 3 --vnc -p \
-l ftp://10.1.1.1/trees/RHEL5-B2-Server-i386/

インストールの自動化

Red Hat Enterprise Linux はグラフィカルインターフェイスや、手動入力を 使用せずにインストールできます。Kickstart ファイルの使用でインストール プロセスを自動化することができます。
いずれの方法でもこのウィンドウを開き、使用するゲストの初期ブート段階を表示します:
使用しているゲストが初期ブートを完了したら、Red Hat Enterprise Linux の 標準インストールプロセスが開始されます。ほとんどのシステムにはデフォルトの 回答が受け付けられます。
手順8.1 Para-virtualized Red Hat Enterprise Linux ゲストのインストール手順
  1. 言語を選択して、OK をクリックします。
  2. キーボードレイアウトを選択して、OK をクリックします。
  3. Assign the guest's network address. Choose to use DHCP (as shown below) or a static IP address:
  4. DHCP を選択すると、インストールプロセスは、ここで IP アドレスの取得を 試みます:
  5. If you chose a static IP address for your guest this prompt appears. Enter the details on the guest's networking configuration:
    1. 有効な IP アドレスを入力します。入力する IP アドレスがインストールツリーを持つ サーバーに到達するように確認して下さい。
    2. 有効なサブネットマスク、デフォルトのゲートウェイ、及びネームサーバーのアドレスを 入力します。
    言語を選択して、OK をクリックします。
  6. 以下に静的 IP アドレス設定の例を示します:
  7. インストールプロセスはここで、必要とするファイルをサーバーから取り込みます:
初期のステップが終了すると、グラフィカルプロセスが開始されます。
Beta バージョンや早期のリリースディストリビューションをインストールしている 場合は、オペレーティングシステムをインストールしたいことを確定して下さい。 とにかくインストールする をクリックして、OK を クリックします:
手順8.2 グラフィカルインストールプロセス
  1. 有効な登録コードを入力します。有効な RHN サブスクリプションキーがある場合は、 Installation Number フィールド内に それを入力します:

    注記

    登録ステップを飛ばす場合、インストールの後で rhn_register コマンドを使用して、Red Hat Network アカウントの詳細を 確定することができます。rhn_register コマンドには root アクセスが必要です。
  2. インストールプロセスがインストールに選択した場所に格納されている全てのデータの 抹消を是認するように催促します:
    はい をクリックして継続します。
  3. Review the storage configuration and partition layout. You can chose to select the advanced storage configuration if you want to use iSCSI for the guest's storage.
    Make your selections then click Forward.
  4. インストール用に選択したストレージを確定します。
    はい をクリックして継続します。
  5. ネットワーキングとホスト名のセッティングを構成します。これらのセッティングは 先にインストールプロセスで入力したデータで充填されます。必要であればそれを 変更して下さい。
    OK をクリックして継続します。
  6. 現在地の適切なタイムゾーンを選択します。
  7. ゲスト用の root パスワードを入力します。
    進む をクリックして継続します。
  8. インストールするソフトウェアパッケージを選択します。今すぐ カスタマイズ ボタンを選択します。kernel-xen パッケージを System ディレクトリにインストールする必要が あります。para-virtualization には kernel-xen パッケージが 必要です。
    Click Forward.
  9. 依存関係と領域の要件が算出されます。
  10. After the installation dependencies and space requirements have been verified click Forward to start the actual installation.
  11. 選択したソフトウェアパッケージが全て自動的にインストールされます。
  12. インストールが完了したら、ゲストを再起動します:
  13. ゲストは再起動しません。代わりにシャットダウンします...
  14. Boot the guest. The guest's name was chosen when you used the virt-install in 「Red Hat Enterprise Linux 5.0 を para-virtualized ゲストとしてインストール」. If you used the default example the name is rhel5PV.
    virsh の使用でゲストの再起動ができます:
    # virsh reboot rhel5PV
    別の方法として、virt-manager を開いて、ゲスト用の 名前を選択し、開く をクリックします。それから 実行 をクリックします。
    A VNC window displaying the guest's boot processes now opens.
  15. ゲストをブートすると First Boot 設定の画面がスタートします。 このウィザードは使用するゲスト用にいくつかの基本的な設定選択を催促してきます。
  16. ライセンス同意書を読んで同意して下さい。
    ライセンス同意のウィンドウで 進む をクリックします。
  17. ファイアウォールを設定します。
    進む をクリックして継続します。
    1. ファイアウォールを無効にすると、その選択を確定するように催促されます。 はい をクリックして確定し、継続します。但し、 ご自分のファイアウォールを無効にすることは推奨できません。
  18. SELinux を設定します。SELinux を 強制モード で実行する ことが強く推奨されます。SELinux は許容モードで実行するか、無効にすることも 選択できます。
    進む をクリックして継続します。
    1. SELinux を無効にする選択をすると、この警告が表示されます。 はい をクリックすると SELinux が 無効になります。
  19. Disable kdump. The use of kdump is unsupported on para-virtualized guests.
    進む をクリックして継続します。
  20. Confirm time and date are set correctly for your guest. If you install a para-virtualized guest time and date should synchronize with the hypervisor.
    If the users sets the time or date during the installation it is ignored and the hypervisor's time is used.
    進む をクリックして継続します。
  21. ソフトウェア更新をセットアップします。Red Hat Network サブスクリプションを持っている場合、 あるいは、そのお試し版を欲しい場合は、以下の画面を使用して新規にインストールしたゲストを RHN に登録します。
    進む をクリックして継続します。
    1. RHN 用の選択を確定します。
    2. RHN アクセスを設定していない場合は、もう1つの画面が出てくるでしょう。 RHN アクセスが有効になっていなければ、ソフトウェア更新は受け取れません。
      進む ボタンをクリックします。
  22. root 以外のユーザーアカウントを作成します。通常の使用と強化セキュリティの為には root 以外のユーザーアカウントの作成が推奨されます。ユーザー名、氏名、及びパスワードを 入力します。
    進む ボタンをクリックします。
  23. サウンドデバイスが検出されて、サウンドが必要であれば、それを調節します。 プロセスを完了して、進む をクリックします。
  24. You can install additional packages from a CD or another repository using this screen. It is often more efficient to not install any additional software at this point but add packages later using the yum command or RHN. Click Finish.
  25. ゲストはここで、ユーザーが変更したセッティングを設定し、ブートプロセスを 継続します。
  26. Red Hat Enterprise Linux 5 のログイン画面が表示されます。先のステップで 作成したユーザー名を使用してログインします。
  27. これで、 para-virtualized Red Hat Enterprise Linux ゲストが正常にインストールされました。

8.2. Red Hat Enterprise Linux を完全仮想化ゲストとしてインストール

This section covers installing a fully virtualized Red Hat Enterprise Linux 5 guest. This procedure covers both the KVM and the Xen hypervisors; the steps are interchangeable and different steps are noted.
The KVM hypervisor requires Red Hat Enterprise Linux 5.4 or newer.
手順8.3 virt-manager を使用して完全仮想化 Red Hat Enterprise Linux 5 ゲストを作成
  1. virt-manager を開く

    virt-manager を開始します。アプリケーション メニューと システムツール サブメニューから 仮想マシン マネージャ のアプリケーションを起動します。別の方法として、root になって virt-manager コマンドを実行することもできます。
  2. Hypervisor を選択

    hypervisor を選択します。Xen か KVM がインストールされている場合は、そのいずれかを 選択します。例えば、KVM を選択する場合、現在、KVM は qemu と命名されていることに注意して下さい。
    Connect to a hypervisor if you have not already done so. Open the File menu and select the Add Connection... option. Refer to 「The Add Connection window」.
    hypervisor 接続が選択されると、新規 ボタンが 利用可能になります。新規 ボタンをクリックします。
  3. 新規仮想マシンウィザードを開始

    Pressing the New button starts the virtual machine creation wizard.
    Press Forward to continue.
  4. 仮想マシンの命名

    Provide a name for your virtualized guest. Punctuation and whitespace characters are not permitted in versions before Red Hat Enterprise Linux 5.5. Red Hat Enterprise Linux 5.5 adds support for '_', '.' and '-' characters.
    Press Forward to continue.
  5. 仮想化のメソッドを選択

    Choose the virtualization method for the virtualized guest. Note you can only select an installed virtualization method. If you selected KVM or Xen earlier (ステップ 4) you must use the hypervisor you selected. This example uses the KVM hypervisor.
    Press Forward to continue.
  6. インストールメソッドの選択

    Red Hat Enterprise Linux は以下の方法の1つを使用してインストールできます:
    • ローカルインストールメディア:ISO イメージか、又は 物理光学メディア
    • Red Hat Enterprise Linux のインストールツリーが、HTTP、 FTP 、又は NFS を介して ホストされている場合は、「ネットワークインストールツリー」 を 選択します。
    • Red Hat Enterprise Linux インストールメディアのブート用に PXE サーバーを設定している場合は、 PXE を使用することができます。Red Hat Enterprise Linux インストールを PXE ブートするように サーバー設定する方法はこのガイドでは言及しません。しかし、メディアブートの後はほとんどの インストール手順は同じです。
    Set OS Type to Linux and OS Variant to Red Hat Enterprise Linux 5 as shown in the screenshot.
    Press Forward to continue.
  7. インストールメディアの場所を指定

    ISO イメージの位置、又は CD-ROM か DVD のデバイスを選択します。ここの例では、 Red Hat Enterprise Linux installation DVD の ISO ファイルイメージを使用します。
    1. 閲覧 ボタンをクリック
    2. ISO ファイルの位置を検出して ISO イメージを選択します。開く を クリックして選択を確定します。
    3. The file is selected and ready to install.
      Press Forward to continue.

    イメージファイルと SELinux

    For ISO image files and guest storage images the recommended to use the /var/lib/libvirt/images/ directory. Any other location may require additional configuration for SELinux, refer to 「SELinux と仮想化」 for details.
  8. ストレージセットアップ

    Assign a physical storage device (Block device) or a file-based image (File). File-based images must be stored in the /var/lib/libvirt/images/ directory. Assign sufficient space for your virtualized guest and any applications the guest requires.
    Press Forward to continue.

    移行

    Live and offline migrations require guests to be installed on shared network storage. For information on setting up shared storage for guests refer to パートV「Virtualization Storage Topics」.
  9. ネットワーク設定

    仮想ネットワーク 又は 共有の 物理デバイス のどちらかを選択します。
    仮想ネットワークオプションは、NAT(Network Address Translation)を 使用してデフォルトのネットワークデバイスを仮想化ゲストと共有します。 ワイヤレスネットワークには仮想ネットワークオプションを使用します。
    The shared physical device option uses a network bond to give the virtualized guest full access to a network device.
    Press Forward to continue.
  10. メモリーと CPU の割り当て

    The Memory and CPU Allocation window displays. Choose appropriate values for the virtualized CPUs and RAM allocation. These values affect the host's and guest's performance.
    仮想化ゲストは、効率的にそして効果的に稼働するために十分な物理メモリー (RAM) を必要とします。使用するゲストオペレーティングシステムとアプリケーションの 必要性に適合するメモリーの値を選択します。ゲストは物理 RAM を使用することを忘れないで下さい。ホストシステムに対し、過度の数のゲストを稼働したり、不十分なメモリーを設定していると、仮想メモリーとスワップをかなり使用することになります。仮想メモリーは 確実に低速であり、システムパフォーマンスと反応性の低下の原因となります。 全てのゲストとホストが効率的に稼働できるように十分なメモリーを割り当てることを確認して下さい。
    十分な仮想 CPU を仮想ゲストに割り当てます。ゲストがマルチスレッドのアプリケーションを実行する場合は、ゲストが効率良く実行するのに必要な仮想化 CPU の数を割り当てます。ホストシステム上で利用できる物理プロセッサ (又はハイパースレッド)の数量以上の仮想 CPU を割り当てないで下さい。仮想プロセッサの超過割り当ては可能ですが、超過割り当ては、プロセッサのコンテキストがオーバーヘッドを切り替えるため、ゲストとホストのパフォーマンスに重大な否定的影響を与えます。
    Press Forward to continue.
  11. 確認してゲストインストールを開始

    Verify the configuration.
    Press Finish to start the guest installation procedure.
  12. Red Hat Enterprise Linux のインストール

    Red Hat Enterprise Linux 5 のインストールシーケンスを完了します。この インストールシーケンスは、インストールガイド で 説明してあります。Red Hat ドキュメント で Red Hat Enterprise Linux インストールガイド を参照して下さい。
これで、完全仮想化 Red Hat Enterprise Linux 5 ゲストはインストールできました。

8.3. Windows XP を完全仮想化ゲストとしてインストール

Windows XP は完全仮想化ゲストとしてインストールできます。このセクションでは、 Windows XP を Red Hat Enterprise Linux 上に完全仮想化ゲストとしてインストール する方法を説明しています。
This procedure covers both the KVM and the Xen hypervisors; the steps are interchangeable and different steps are noted.
The KVM hypervisor requires Red Hat Enterprise Linux 5.4 or newer.
この工程を始める前に root アクセスを確定する必要があります。

Itanium® のサポート

現時点では、Itanium® アーキテクチャ 上の Red Hat Enterprise Linux ホストは完全仮想化の Windows XP ゲストをサポートして いません。Itanium システムには、Itanium ベースシステム対応の Windows Server 2003 のみがサポートされています。
  1. virt-manager の開始

    Open Applications > System Tools > Virtual Machine Manager. Open a connection to a host (click File > Add Connection). Click the New button to create a new virtual machine.
  2. 仮想システムの命名

    システムの名前 を入力して、それから 進む ボタンを クリックします。
  3. 仮想化メソッドの選択

    If you selected KVM or Xen earlier (step ステップ 1 ) you must use the hypervisor you selected. This example uses the KVM hypervisor.
    Windows は完全仮想化を使用してのみインストールが可能です。
  4. インストールメソッドの選択

    この画面は、ユーザーがインストールのメソッドとオペレーティング システムのタイプを指定できるようにしてくれます。
    OS タイプ のリストから Windows を 選択して、OS 変種 のリストから Microsoft Windows XP を 選択します。
    PXE でのゲストのインストールは Red Hat Enterprise Linux 5.2 でサポートが あります。ただし PXE インストールはこの章では取り扱いません。

    イメージファイルと SELinux

    For ISO image files and guest storage images the recommended to use the /var/lib/libvirt/images/ directory. Any other location may require additional configuration for SELinux, refer to 「SELinux と仮想化」 for details.
    進む をクリックして継続します。
  5. Choose installation image

    Choose the installation image or CD-ROM. For CD-ROM or DVD installation select the device with the Windows installation disc in it. If you chose ISO Image Location enter the path to a Windows installation .iso image.
    進む をクリックして継続します。
  6. The Storage window displays. Choose a disk partition, LUN or create a file-based image for the guest's storage.
    All image files are stored in the /var/lib/libvirt/images/ directory by default. In the default configuration, other directory locations for file-based images are prohibited by SELinux. If you use a different directory you must label the new directory according to SELinux policy. Refer to 「SELinux と仮想化」 for details.
    アプリケーションや他のデータの為にゲストが追加のスペースを必要とする場合、 余分のスペースを割り当てます。例えば、ウェブサーバーはログファイル用に 追加のスペースを必要とします。
    選択したストレージタイプでゲスト用に適切なサイズを選びます。それから 進む ボタンをクリックします。

    注記

    仮想マシンにはデフォルトのディレクトリ、/var/lib/libvirt/images/ の 使用が推奨されます。別の場所(この例では、/images/)を使用している 場合は、インストールを継続する前に確実にそれが SELinux ポリシーに追加されるように して下さい(このドキュメントの後で SELinux ポリシーの変更の仕方が案内してあります)。
  7. ネットワークのセットアップ

    仮想ネットワーク 又は 共有物理デバイスを選択します。
    仮想ネットワークオプションは NAT(Network Address Translation)を使用して 仮想化ゲストを持つデフォルトのネットワークデバイスを共有します。ワイヤレス ネットワークには仮想ネットワークオプションを使用して下さい。
    The shared physical device option uses a network bond to give the virtualized guest full access to a network device.
    Press Forward to continue.
  8. The Memory and CPU Allocation window displays. Choose appropriate values for the virtualized CPUs and RAM allocation. These values affect the host's and guest's performance.
    仮想化ゲストは、効率的にそして効果的に稼働するために十分な物理メモリー (RAM) を必要とします。使用するゲストオペレーティングシステムとアプリケーションの 必要性に適合するメモリーの値を選択します。ほとんどのオペレーティングシステムは 正常に機能するために最低でも 512MB の RAM を必要とします。ゲストは物理 RAM を 使用することを忘れないで下さい。過度の数のゲストを稼働したり、ホストシステム用に不十分なメモリーを設定 していると、仮想メモリーとスワップをかなり使用することになります。仮想メモリーは 確実に低速であり、システムパフォーマンスと反応性の低下の原因となります。 全てのゲストとホストが効率的に稼働できるように十分なメモリーを割り当てる ことを確認して下さい。
    十分な仮想 CPU を仮想ゲストに割り当てます。ゲストがマルチスレッドの アプリケーションを実行する場合は、最も効率良く実行するのにゲストが必要な仮想化 CPU の数を割り当てます。ホストシステム上で利用できる物理プロセッサ (又はハイパースレッド)の数量以上の仮想 CPU を割り当てないで下さい。 仮想プロセッサの超過割り当ては可能ですが、超過割り当ては、プロセッサの コンテキストがオーバーヘッドを切り替えるため、ゲストとホストのパフォーマンスに重大な悪影響を与えます。
  9. インストールが継続される前に、要約の画面が表示されます。完了 をクリックしてゲストインストールへと進みます。
  10. You must make a hardware selection so open a console window quickly after the installation starts. Click Finish then switch to the virt-manager summary window and select your newly started Windows guest. Double click on the system name and the console window opens. Quickly and repeatedly press F5 to select a new HAL, once you get the dialog box in the Windows install select the 'Generic i486 Platform' tab. Scroll through selections with the Up and Down arrows.
  11. インストールは標準の Windows インストールと同様に進みます。
  12. プロンプト時にハードドライブのパーティション設定
  13. ドライブがフォーマットされた後に、Windows はハードドライブへファイルのコピーを開始します。
  14. ファイルはストレージデバイスにコピーされて、Windows がここで再起動します。
  15. Windows ゲストを再起動:
    # virsh start WindowsGuest
    ここで、WindowsGuest とは、ご使用の仮想マシンの 名前です。
  16. コンソールウィンドウが開くと、Windows インストールのセットアップ段階が出てきます。
  17. ユーザーのインストールがセットアップ段階で止まったように見える場合、 virsh reboot WindowsGuestName を使用してゲストを再起動して下さい。仮想マシンを再起動すると、 Setup is being restarted のメッセージが出てきます:
  18. セットアップが終了したら、Windows のブート画面が出てきます:
  19. この時点で Windows インストールの標準のセットアップを継続できます:
  20. これでセットアッププロセスは完了です。

8.4. 完全仮想化ゲストとして Windows Server 2003 をインストール

This chapter describes installing a fully virtualized Windows Server 2003 guest with the virt-install command. virt-install can be used instead of virt-manager This process is similar to the Windows XP installation covered in 「Windows XP を完全仮想化ゲストとしてインストール」.

Itanium® サポート

現在、Itanium® アーキテクチャ上の Red Hat Enterprise Linux ホストは完全仮想化した Windows のゲストをサポートして いません。このセクションは x86 と x86-64 のホストにのみ適用されます。
  1. Using virt-install for installing Windows Server 2003 as the console for the Windows guest opens the virt-viewer window promptly. The examples below installs a Windows Server 2003 guest with the virt-install command.
    1. Xen virt-install

      # virt-install --virt-type=xen -hvm  \
         --name windows2003sp1 
         --file=/var/lib/libvirt/images/windows2003sp2.img \
         --file-size=6 \
         --cdrom=/var/lib/libvirt/images/ISOs/WIN/en_windows_server_2003_sp1.iso \
         --vnc --ram=1024
      
    2. KVM virt-install

      # virt-install --accelerate --hvm --connect qemu:///system \
         --name rhel3support  \
         --network network:default \
         --file=/var/lib/libvirt/images/windows2003sp2.img \
         --file-size=6 \
         --cdrom=/var/lib/libvirt/images/ISOs/WIN/en_windows_server_2003_sp1.iso \
         --vnc --ram=1024
      
  2. ゲストがインストール時点まで起動すると、すぐに F5 を押す必要が あります。適切なタイミングで F5 を押さないと、インストールを再開始することになります。F5 を押すことにより、異なる HAL 又は、Computer Type を選択できるようになります。Computer Type として Standard PC を選択します。Windows Server 2003 の仮想化ゲストには Computer Type の 変更が必要になります。
  3. インストールの残りを完了する
  4. これで Windows Server 2003 が完全仮想化ゲストとしてインストールされました。

8.5. Windows Server 2008 を完全仮想化ゲストとしてインストール

This section covers installing a fully virtualized Windows Server 2008 guest. This procedure covers both the KVM and the Xen hypervisors; the steps are interchangeable and different steps are noted.
The KVM hypervisor requires Red Hat Enterprise Linux 5.4 or newer.
手順8.4 virt-manager を使用した Windows Server 2008 のインストール
  1. virt-manager を開く

    virt-manager を開始します。アプリケーション メニュー内の システムツール サブメニューから 仮想マシン マネージャ アプリケーションを起動します。別の方法としては、root として virt-manager コマンドを実行します。
  2. Hypervisor を選択

    Hypervisor を選択します。Xen か KVM がインストールされている場合は、そのいずれかを 選択します。ここでの例として KVM を選択しましょう。現在、KVM には qemu と言う呼称があることに注意して下さい。
    オプションが選択されると、新規 ボタンが使用可能に なります。そこで 新規 ボタンを押します。
  3. 新規仮想マシンウィザードを開始

    Pressing the New button starts the virtual machine creation wizard.
    Press Forward to continue.
  4. 仮想マシンの命名

    Provide a name for your virtualized guest. Punctuation and whitespace characters are not permitted in versions before Red Hat Enterprise Linux 5.5. Red Hat Enterprise Linux 5.5 adds support for '_', '.' and '-' characters.
    Press Forward to continue.
  5. 仮想化メソッドを選択

    Choose the virtualization method for the virtualized guest. Note you can only select an installed virtualization method. If you selected KVM or Xen earlier (step 2) you must use the hypervisor you selected. This example uses the KVM hypervisor.
    Press Forward to continue.
  6. インストールメソッドを選択

    Windows の全てのバージョンには、ISO イメージか、又は物理光学メディアの いずれかの ローカルインストールメディア を使用する必要があります。
    Windows のネットワークインストールの為に PXE サーバーが設定されて いる場合は、PXE を使用できます。しかし、このガイドでは、PXE Windows インストールは説明していません。
    Set OS Type to Windows and OS Variant to Microsoft Windows 2008 as shown in the screenshot.
    Press Forward to continue.
  7. インストールメディアの位置を指定

    ISO イメージの位置、又は CD-ROM か DVD のデバイスを選択します。この例では、 Windows Server 2008 のインストール CD 用の ISO ファイルイメージを使用します。
    1. 閲覧 ボタンを押します。
    2. Search to the location of the ISO file and select it.
      Press Open to confirm your selection.
    3. The file is selected and ready to install.
      Press Forward to continue.

    イメージファイルと SELinux

    For ISO image files and guest storage images, the recommended directory to use is the /var/lib/libvirt/images/ directory. Any other location may require additional configuration for SELinux, refer to 「SELinux と仮想化」 for details.
  8. ストレージセットアップ

    Assign a physical storage device (Block device) or a file-based image (File). File-based images must be stored in the /var/lib/libvirt/images/ directory. Assign sufficient space for your virtualized guest and any applications the guest requires.
    Press Forward to continue.
  9. ネットワークセットアップ

    仮想ネットワーク 又は 共有物理デバイス のいずれかを選択します。
    仮想ネットワークオプションは NAT (Network Address Translation) を使用して、 デフォルトのネットワークデバイスを仮想ゲストと共有します。仮想ネットワーク オプションをワイヤレスネットワークに使用して下さい。
    The shared physical device option uses a network bond to give the virtualized guest full access to a network device.
    Press Forward to continue.
  10. メモリーと CPU の割り当て

    The Memory and CPU Allocation window displays. Choose appropriate values for the virtualized CPUs and RAM allocation. These values affect the host's and guest's performance.
    仮想化ゲストは、効率的にそして効果的に稼働するために十分な物理メモリー (RAM) を必要とします。使用するゲストオペレーティングシステムとアプリケーションの必要性に適合するメモリーの値を選択します。ゲストは物理 RAM を使用することを忘れないで下さい。過度の数のゲストを稼働したり、ホストシステム用に不十分なメモリーを設定していると、仮想メモリーとスワップをかなり消費することになります。仮想メモリーは 確実に低速であり、システムパフォーマンスと反応性の低下の原因となります。 全てのゲストとホストが効率的に稼働できるように十分なメモリーを割り当てることを確認して下さい。
    十分な仮想 CPU を仮想ゲストに割り当てます。ゲストがマルチスレッドの アプリケーションを実行する場合は、ゲストが効率良く実行するのに必要な仮想化 CPU の数を割り当てます。ホストシステム上で利用できる物理プロセッサ (又はハイパースレッド)の数量以上の仮想 CPU を割り当てないで下さい。 仮想プロセッサの超過割り当ては可能ですが、超過割り当ては、プロセッサのコンテキストがオーバーヘッドを切り替えるため、ゲストとホストのパフォーマンスに重大な悪影響を与えます。
    Press Forward to continue.
  11. ゲストのインストールを確認してからスタートします。

    Verify the configuration.
    Press Finish to start the guest installation procedure.
  12. Windows のインストール

    Complete the Windows Server 2008 installation sequence. The installation sequence is not covered by this guide, refer to Microsoft's documentation for information on installing Windows.

パート III. 設定

Red Hat Enterprise Linux 内で仮想化を設定

These chapters cover configuration procedures for various advanced virtualization tasks. These tasks include adding network and storage devices, enhancing security, improving performance, and using the Para-virtualized drivers on fully virtualized guests.

目次

9. Virtualized storage devices
9.1. 仮想化フロッピィディスクコントローラの作成
9.2. ストレージデバイスをゲストに追加
9.3. Red Hat Enterprise Linux 5 内に永続的ストレージを構成
9.4. 仮想化した CD-ROM 又は DVD デバイスをゲストに追加
10. ネットワークの設定
10.1. libvirt を持つ NAT(Network address translation)
10.2. libvirt を使用したブリッジネットワーキング
11. Red Hat Enterprise Linux 5.4 以前の Xen ネットワーキング
11.1. 複数のゲストネットワークブリッジを設定して複数のイーサネットカードを使用
11.2. Red Hat Enterprise Linux 5.0 ラップトップネットワークの設定
12. Xen Para-virtualized ドライバー
12.1. システム要件
12.2. Para-virtualization の制約とサポート
12.3. Para-virtualized ドライバーのインストール
12.3.1. 共通のインストール手順
12.3.2. Red Hat Enterprise Linux 3 で Para-virtualized ドライバーのインストールと 設定
12.3.3. Red Hat Enterprise Linux 4 上で Para-virtualized ドライバーのインストールと 設定
12.3.4. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 5
12.3.5. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 6
12.4. Para-virtualized ネットワークドライバーの設定
12.5. 追加の Para-virtualized ハードウェア設定
12.5.1. 仮想化ネットワークインターフェイス
12.5.2. 仮想ストレージデバイス
13. KVM Para-virtualized ドライバー
13.1. KVM Windows para-virtualized ドライバーのインストール
13.2. Installing drivers with a virtualized floppy disk
13.3. 既存のデバイスに KVM para-virtualized ドライバーを使用する
13.4. 新規デバイス用に KVM para-virtualized ドライバーを使用する
14. PCI passthrough
14.1. Adding a PCI device with virsh
14.2. Adding a PCI device with virt-manager
14.3. PCI passthrough with virt-install
14.4. PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux
15. SR-IOV
15.1. Introduction
15.2. Using SR-IOV
15.3. Troubleshooting SR-IOV
16. KVM ゲストのタイミング管理

第9章 Virtualized storage devices

This chapter covers installing and configuring storage devices in virtualized guests. The term block devices refers to various forms of storage devices. All the procedures in this chapter work with both Xen and KVM hypervisors.

Valid disk targets

The target variable in libvirt configuration files accepts only the following device names:
  • /dev/xvd[a to z][1 to 15]
    Example: /dev/xvdb13
  • /dev/xvd[a to i][a to z][1 to 15]
    Example: /dev/xvdbz13
  • /dev/sd[a to p][1 to 15]
    Example: /dev/sda1
  • /dev/hd[a to t][1 to 63]
    Example: /dev/hdd3

9.1. 仮想化フロッピィディスクコントローラの作成

フロッピィディスクコントローラは、多くの旧来のオペレーティングシステムで必要になります。特にドライバーのインストールで必要です。現時点では、物理的な フロッピィディスクデバイスは仮想ゲストからアクセスできません。しかし、フロッピィ ディスクイメージの作成と仮想化フロッピィドライブからのアクセスはサポートされて います。このセクションでは、仮想化フロッピィデバイスを取り扱います。
An image file of a floppy disk is required. Create floppy disk image files with the dd command. Replace /dev/fd0 with the name of a floppy device and name the disk appropriately.
# dd if=/dev/fd0 of=~/legacydrivers.img

Para-virtualized ドライバーの注記

The para-virtualized drivers can map physical floppy devices to fully virtualized guests. For more information on using para-virtualized drivers read 13章KVM Para-virtualized ドライバー.
この例は、/var/lib/libvirt/images/rhel5FV.img にイメージを 配置した完全仮想化 Red Hat Enterprise Linux のインストールを実行している virt-manager で 作成されたゲストを使用します。Xen hypervisor がこの例で使用されています。
  1. 実行中のゲストで virsh を使用して ゲストイメージ用に XML 設定ファイルを作成します。
    # virsh dumpxml rhel5FV > rhel5FV.xml
    
    This saves the configuration settings as an XML file which can be edited to customize the operations and devices used by the guest. For more information on using the virsh XML configuration files, refer to 33章カスタムの libvirt スクリプト作成.
  2. ゲスト用にフロッピィディスクイメージを作成
    # dd if=/dev/zero of=/var/lib/libvirt/images/rhel5FV-floppy.img bs=512 count=2880
    
  3. Add the content below, changing where appropriate, to your guest's configuration XML file. This example is an emulated floppy device using a file-based image.
    <disk type='file' device='floppy'>
    	<source file='/var/lib/libvirt/images/rhel5FV-floppy.img'/>
    	<target dev='fda'/>
    </disk>
    
  4. Force the guest to stop. To shut down the guest gracefully, use the virsh shutdown command instead.
    # virsh destroy rhel5FV
  5. XML 設定ファイルを使用してゲストを再スタートします。
    # virsh create rhel5FV.xml
    
フロッピィデバイスはこの時点で、ゲスト内で利用可能となりホスト上に イメージファイルとして保存されます。

9.2. ストレージデバイスをゲストに追加

このセクションでは、ストレージデバイスを仮想ゲストマシンに追加する方法を説明します。 追加のストレージはゲストが作成された後にのみ追加できます。サポートされているストレージデバイスとプロトコルを以下に示します:
  • ローカルハードドライブのパーティション
  • ローカルボリューム
  • ファイバーチャンネル、又は ホストに直結の iSCSI
  • ホストのファイルシステムに存在するファイルコンテナ
  • 仮想マシンによって直接マウントされている NFS ファイルシステム
  • ゲストにより直接アクセスされる iSCSI ストレージ
  • クラスタファイルシステム (GFS).
ファイルベースストレージをゲストに追加
ファイルベースストレージ、又はファイルベースコンテナはホストファイルシステム上の ファイルであり、仮想化ゲストの為の仮想化ハードドライブとして動作します。ファイル ベースコンテナを追加するには、以下の手順を実行します:
  1. 空のコンテナファイルを作成するか、又は、既存のファイルコンテナ(ISO ファイルなど)を使用。
    1. dd コマンドを使用して Sparse ファイルを作成します。 Sparse ファイルは、データの整合性とパフォーマンス問題のために推奨できませんが、 Sparse ファイルは より速く作成できてテストに使用できます。但し実稼働環境では使用できません。
      # dd if=/dev/zero of=/var/lib/libvirt/images/FileName.img bs=1M seek=4096 count=0
      
    2. 非 sparse の 事前割り当て済みのファイルがファイルベースストレージイメージ用に推奨されます。非 sparse ファイルを作成して、以下を実行します:
      # dd if=/dev/zero of=/var/lib/libvirt/images/FileName.img bs=1M count=4096
      
    Both commands create a 4GB file which can be used as additional storage for a virtualized guest.
  2. ゲスト用の設定をダンプします。この例では、ゲストは Guest1 と 言う名前であり、ファイルはユーザーのホームディレクトリに保存されます。
    # virsh dumpxml Guest1 > ~/Guest1.xml
    
  3. テキストエディタで設定ファイル (この例では、Guest1.xml) を開きます。 <disk> エレメントを見つけて下さい。 このエレメントはストレージデバイスを記述するものです。以下にディスクエレメントの 例を示します:
    <disk type='file' device='disk'>
        <driver name='tap' type='aio'/>
        <source file='/var/lib/libvirt/images/Guest1.img'/>
        <target dev='xvda'/>
    </disk>
    
  4. <disk> エレメントの複製により、又は 新規の書き込みにより追加のストレージを追加します。仮想ブロックデバイス属性用のデバイス名を 指定することを確認して下さい。この属性はそれぞれのゲスト設定ファイルのために独自のもので なければなりません。以下の例では、FileName.img と呼ばれる 追加のファイルベースストレージコンテナを含んでいる設定ファイルセクションを示しています。
    <disk type='file' device='disk'>
        <driver name='tap' type='aio'/>
        <source file='/var/lib/libvirt/images/Guest1.img'/>
        <target dev='xvda'/>
    </disk>
    <disk type='file' device='disk'>
        <driver name='tap' type='aio'/>
        <source file='/var/lib/libvirt/images/FileName.img'/>
        <target dev='hda'/>
    </disk>
    
  5. 更新された設定ファイルからゲストを再起動します。
    # virsh create Guest1.xml
    
  6. The following steps are Linux guest specific. Other operating systems handle new storage devices in different ways. For other systems, refer to that operating system's documentation
    The guest now uses the file FileName.img as the device called /dev/sdb. This device requires formatting from the guest. On the guest, partition the device into one primary partition for the entire device then format the device.
    1. 新規パーティション 用に n を押します。
      # fdisk /dev/sdb
      Command (m for help):
      
    2. プライマリパーティション用に p を押します。
      Command action
         e   extended
         p   primary partition (1-4)
      
    3. 利用可能なパーティションを1つ選択します。この例では、1 を 入力することにより、最初のパーティションが選択されます。
      Partition number (1-4): 1
      
    4. Enter を押すことでデフォルトの最初の シリンダを入力します。
      First cylinder (1-400, default 1):
      
    5. パーティションのサイズを選択します。この例では Enter を 押すことによりディスク全体が割り当てられます。
      Last cylinder or +size or +sizeM or +sizeK (2-400, default 400):
      
    6. t を押すことにより パーティションのタイプをセットします。
      Command (m for help): t
      
    7. 先のステップで作成したパーティションを選択します。この例では、 パーティション番号は 1 です。
      Partition number (1-4): 1
      
    8. linux パーティションとして 83 を入力します。
      Hex code (type L to list codes): 83
      
    9. 変更をディスクに書き込んで退出します。
      Command (m for help): w 
      Command (m for help): q
      
    10. ext3 ファイルシステムを 使用して新規パーティションをフォーマットします。
      # mke2fs -j /dev/sdb1
      
  7. ゲストにディスクをマウントします。
    # mount /dev/sdb1 /myfiles
    
これでゲストは追加の仮想化ファイルベースストレージデバイスを持つことになります。
ゲストへハードドライブと他のブロックデバイスを追加
System administrators use additional hard drives for to provide more storage space or to separate system data from user data. This procedure, 手順9.1「物理ブロックデバイスを仮想化ゲストに追加」, describes how to add a hard drive on the host to a virtualized guest.
この手順は、全ての物理ブロックデバイスに適用できます。それには、 CD-ROM、DVD 及び フロッピィディスクも含まれます。

Block device security

The host should not use disk labels to identify file systems in the fstab file, the initrd file or used by the kernel command line. If less privileged users, especially virtualized guests, have write access to whole partitions or LVM volumes the host system could be compromised.
Guest should not be given write access to whole disks or block devices (for example, /dev/sdb). Virtualized guests with access to block devices may be able to access other block devices on the system or modify volume labels which can be used to compromise the host system. Use partitions (for example, /dev/sdb1) or LVM volumes to prevent this issue.
手順9.1 物理ブロックデバイスを仮想化ゲストに追加
  1. ハードディスクデバイスを物理的にホストに取り付けます。デフォルトでドライブが アクセス不可の場合は、ホストを設定します。
  2. multipath の使用でデバイスを設定して、必要であれば ホスト上で永続化します。
  3. Use the virsh attach command. Replace: myguest with your guest's name, /dev/sdb1 with the device to add, and sdc with the location for the device on the guest. The sdc must be an unused device name. Use the sd* notation for Windows guests as well, the guest will recognize the device correctly.
    Append the --type cdrom parameter to the command for CD-ROM or DVD devices.
    --type floppy パラメータを フロッピィデバイス用のコマンドに追記します。
    # virsh attach-disk myguest
    					/dev/sdb1
    					sdc --driver tap --mode readonly
    
  4. The guest now has a new hard disk device called /dev/sdb on Linux or D: drive, or similar, on Windows. This device may require formatting.

9.3. Red Hat Enterprise Linux 5 内に永続的ストレージを構成

このセクションは、ファイバーチャンネル、又は iSCSI ベースのストレージデバイスなどの 外部、あるいはネットワーク化したストレージを持つシステムについて説明しています。 これらのシステムでは永続的な名前が使用ホスト用に設定してあることが推奨されます。 これが移行を助けると共に、複数の仮想化システム用に不変のデバイス名とストレージを 提供することになります。
UUID (Universally Unique Identifiers) は分散型コンピューティング環境で コンピュータとデバイスの識別のための標準化した手法です。このセクションでは、 UUID を使用して iSCSI あるいはファイバーチャンネル LUN を識別します。UUID は 再始動、切断、そしてデバイススワップの後でも永続的に残ります。UUID はデバイス上の ラベルに似ています。
Systems which are not running multipath must use 単独パスの設定. Systems running multipath can use マルチパスの設定.
単独パスの設定
This procedure implements LUN device persistence using udev. Only use this procedure for hosts which are not using multipath.
  1. /etc/scsi_id.config ファイルを編集します。
    1. options=-b の行がコメントアウトしてあることを確認します。
      # options=-b
      
    2. 以下の行を追加します:
      options=-g
      
      このオプションは、udev を設定して全ての付帯 SCSI デバイスが UUID を返すことを想定します。
  2. 任意のデバイスの UUID を表示するには、 scsi_id -g -s /block/sd* コマンドを使用します。以下のようにします:
    # scsi_id -g -s /block/sd*
    3600a0b800013275100000015427b625e
    
    実際の出力は上記の例と異なるでしょう。この出力は デバイス /dev/sdc の UUID を表示しています。
  3. デバイスにアクセスするコンピュータから scsi_id -g -s /block/sd* コマンドで UUID 出力が 同一かどうか確認します。
  4. デバイスを命名するルールを作成します。/etc/udev/rules.d ディレクトリ内に 20-names.rules と言う名のファイルを作成します。このファイルに新規のルールを 追加します。全てのルールは同じ形式を使用して同じファイルに追加されます。ルールは以下の形式に 従います:
    KERNEL=="sd[a-z]", BUS=="scsi", PROGRAM="/sbin/scsi_id -g -s /block/%k", RESULT="UUID", NAME="devicename"
    
    UUIDdevicename を上記で取り込んだ UUID とそのデバイス名で入れ替えます。 以下が上記の例のためのルールです:
    KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id -g -s", RESULT="3600a0b800013275100000015427b625e", NAME="rack4row16"
    
    udev デーモンはここで、ルール内で UUID 用の /dev/sd* と言う名の全てのデバイスを検索します。マッチするデバイスが、 システムに接続されると、デバイスはルールから名前が割り当てられます。3600a0b800013275100000015427b625e の UUID を持つデバイス内では、/dev/rack4row16 として表示されます。
  5. /etc/rc.local に以下の行を追記します:
    /sbin/start_udev
    
  6. /etc/scsi_id.config/etc/udev/rules.d/20-names.rules、及び /etc/rc.local のファイル内の変化をそれぞれ全ての関連ホストにコピーします。
    /sbin/start_udev
    
設定済のルールを持つネットワークストレージデバイスはここで、 ファイルが更新された全てのホスト上で永続化した名前を取ります。このことは、 共有ストレージを使用してホスト間でゲストを移行できて、ゲストはそれらの 設定ファイル内のストレージデバイスにアクセスできるようになると言う意味です。
マルチパスの設定
multipath パッケージはコンピュータからストレージデバイスへ 複数のパスを持つシステム用に使用されます。multipath は障害 許容、フェイルオーバー、及びパフォーマンス強化を Red Hat Enterprise Linux システムに 付帯しているネットワークストレージデバイスに提供するものです。
Implementing LUN persistence in a multipath environment requires defined alias names for your multipath devices. Each storage device has a UUID which acts as a key for the aliased names. Identify a device's UUID using the scsi_id command.
# scsi_id -g -s /block/sdc
multipath デバイスは /dev/mpath ディレクトリ内で 作成されます。以下の例では、4つのデバイスが /etc/multipath.conf 内で定義されています:
multipaths { 
	multipath { 
	wwid		3600805f30015987000000000768a0019 
	alias		oramp1 
	} 
	multipath { 
	wwid		3600805f30015987000000000d643001a 
	alias		oramp2 
	} 
	mulitpath { 
	wwid		3600805f3001598700000000086fc001b 
	alias		oramp3 
	} 
	mulitpath { 
	wwid		3600805f300159870000000000984001c 
	alias		oramp4 
	} 
}
This configuration will create 4 LUNs named /dev/mpath/oramp1, /dev/mpath/oramp2, /dev/mpath/oramp3 and /dev/mpath/oramp4. Once entered, the mapping of the devices' WWID to their new names are now persistent after rebooting.

9.4. 仮想化した CD-ROM 又は DVD デバイスをゲストに追加

To attach an ISO file to a guest while the guest is online use virsh with the attach-disk parameter.
# virsh attach-disk [domain-id] [source] [target] --driver file --type cdrom --mode readonly
The source and target parameters are paths for the files and devices, on the host and guest respectively. The source parameter can be a path to an ISO file or the device from the /dev directory.

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

このページは、libvirt ベースのアプリケーションで使用される一般的なネットワーキング 設定への導入を提供しています。この情報は Xen、KVM、その他の全ての hypervisor に 適用されます。追加の情報には、libvirt ネットワークアーキテクチャドキュメントをご覧 下さい。
2つの一般的なセットアップとして「仮想ネットワーク」と「共有物理デバイス」が あります。前者は全てのディストリビューションに渡って同一であり配付状態のままで 利用できます。後者はディストリビューション特有の手動設定が必要です。
Network services on virtualized guests are not accessible by default from external hosts. You must enable either Network address translation (NAT) ir a network Bridge to allow external hosts access to network services on virtualized guests.

10.1. libvirt を持つ NAT(Network address translation)

ネットワーク接続共有の為の最も一般的な方法の1つは、NAT (Network address translation) の 転送(別名、仮想ネットワーク)です。
ホストの設定
Every standard libvirt installation provides NAT based connectivity to virtual machines out of the box. This is the so called 'default virtual network'. Verify that it is available with the virsh net-list --all command.
# 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
libvirt は、ゲストとのトラフィックを許可する iptables ルールを追加します。このゲストは INPUTFORWARDOUTPUT、及び POSTROUTING のチェーン内の virbr0 デバイスに付帯しています。libvirt はそれから、 ip_forward パラメータの有効化を試みます。他の一部のアプリケーションが ip_forward を無効にする可能性があるため、最善の選択肢は/etc/sysctl.conf に以下を追加することです。
 net.ipv4.ip_forward = 1
ゲストの設定
Once the host configuration is complete, a guest can be connected to the virtual network based on its name. To connect a guest to the 'default' virtual network, the following XML can be used in the guest:
<interface type='network'>
  <source network='default'/>
</interface>

注記

MAC アドレスの定義はオプションです。無視すると、MAC アドレスは自動的に 生成されます。MAC アドレスの手動セッティングは一部の状況で役に立ちます。
<interface type='network'>
  <source network='default'/>
  <mac address='00:16:3e:1a:b3:4a'/>
  </interface>

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

ブリッジネットワーキング(別名、物理デバイス共有)は、物理デバイスを仮想マシンに 専従させるために使用します。ブリッジングは多くの場合、高度なセットアップや複数の ネットワークインターフェイスを持つサーバー上で使用されます。
Xen ネットワークスクリプトを無効にする
システムが Xen ブリッジを使用している場合は、/etc/xen/xend-config.sxp への編集で以下の行を変更することにより、デフォルトの Xen ネットワーキングブリッジを 無効にすることが推奨されます:
 (network-script network-bridge)
To:
 (network-script /bin/true)
NetworkManager を無効にする
NetworkManager does not support bridging. Running NetworkManager will overwrite any manual bridge configuration. Because of this, NetworkManager should be disabled in order to use networking via the network scripts (located in the /etc/sysconfig/network-scripts/ directory):
# chkconfig NetworkManager off
# chkconfig network on
# service NetworkManager stop
# service network start

注記

As an alternative to turning off NetworkManager, add "NM_CONTROLLED=no" to the ifcfg-* scripts used in the examples. If you do not either set this parameter or disable NetworkManager entirely, any bridge configuration will be overwritten and lost when NetworkManager next starts.
network initscript を作成
次の2つのネットワーク設定ファイルを作成するか、 又は編集します。この手順を追加のネットワークブリッジで(別名で)繰り返します。
/etc/sysconfig/network-scripts ディレクトリへ移動します:
# cd /etc/sysconfig/network-scripts
ブリッジに追加するデバイス用のネットワークスクリプトを開きます。この例では、 ifcfg-eth0 は、ブリッジの一部としてセットされている 物理ネットワークインターフェイスを定義しています:
DEVICE=eth0
# change the hardware address to match the hardware address your NIC uses
HWADDR=00:16:76:D6:C9:45
ONBOOT=yes
BRIDGE=br0

Tip

You can configure the device's Maximum Transfer Unit (MTU) by appending an MTU variable to the end of the configuration file.
MTU=9000
ifcfg-br0、又はそれに似た名前のネットワークスクリプトを /etc/sysconfig/network-scripts ディレクトリ内に作成します。 br0 とは、ブリッジの名前です。これはファイル名が DEVICE パラメータと同じであれば、どんな名前でも結構です。
DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
DELAY=0

IP address configuration

IP address configuration, be it dynamic or static, should be configured on the bridge itself (for example, in the ifcfg-br0 file). Network access will not function as expected if IP address details are configured on the physical interface that the bridge is connected to.

警告

The line, TYPE=Bridge, is case-sensitive. It must have uppercase 'B' and lower case 'ridge'.
設定が終了したら、ネットワークを再開始するか、マシンをリブートします。
# service network restart
iptables を設定して、全てのトラフィックがブリッジを渡って 転送されるようにします。
# iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
# service iptables save
# service iptables restart

ブリッジ上で iptables を無効にします。

別の方法としては、iptables ルールを使って、ブリッジされた トラフィックがプロセスされることを阻止します。/etc/sysctl.conf 内で 以下の行を追記します:
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
sysctl の使用で設定されたカーネルパラメータを再ロードします。
# sysctl -p /etc/sysctl.conf
libvirt デーモンを再起動
# service libvirtd reload
この時点で、「共有物理デバイス」があるはずです。これはゲストを 付帯できるもので、全面的な LAN アクセスを持ちます。以下のようにして 新規ブリッジを確認します:
# brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.000000000000       yes
br0             8000.000e0cb30550       no              eth0
注記。このブリッジは完全に virbr0 ブリッジから独立しています。 物理デバイスを virbr0 に付帯する試行は しないで下さい。 virbr0 ブリッジは NAT (Network Address Translation) 接続機能だけのために あります。

第11章 Red Hat Enterprise Linux 5.4 以前の Xen ネットワーキング

この章では、Xen hypervisor を使用したネットワーキングとネットワーク設定の為の 特殊なトピックを扱います。
Most guest network configuration occurs during the guest initialization and installation process. To learn about configuring networking during the guest installation process, read the relevant sections of the installation process, 7章仮想化ゲストインストールの概要.
Network configuration is also covered in the tool specific reference chapters for virsh (25章virsh でゲストを管理) and virt-manager (26章仮想マシンマネージャ(virt-manager) でゲストを管理する). Those chapters provide a detailed description of the networking configuration tasks using both tools.

Tip

Using para-virtualized network drivers improves performance on fully virtualized Linux guests. 12章Xen Para-virtualized ドライバー explains how to utilize para-virtualized network drivers.

11.1. 複数のゲストネットワークブリッジを設定して複数のイーサネットカードを使用

ネットワークブリッジをセットアップするプロセス(Xen hypervisor 使用):
  1. system-config-network アプリケーションを使用して もう1つのネットワークインターフェイスを設定します。別の方法として、/etc/sysconfig/network-scripts/ ディレクトリ内に ifcfg-ethX と言う名の新しい 設定ファイルを作成します。ここで X とは、いずれかの未使用の番号です。 eth1 と言う名の2つめのネットワークインターフェイス用の サンプルの設定ファイルを以下に示します。
    $ cat /etc/sysconfig/network-scripts/ifcfg-eth1
    DEVICE=eth1
    BOOTPROTO=static
    ONBOOT=yes
    USERCTL=no
    IPV6INIT=no
    PEERDNS=yes
    TYPE=Ethernet
    NETMASK=255.255.255.0
    IPADDR=10.1.1.1
    GATEWAY=10.1.1.254
    ARP=yes
    
  2. ファイル /etc/xen/scripts/network-bridge を,/etc/xen/scripts/network-bridge.xen にコピーします。
  3. Comment out any existing network scripts in /etc/xen/xend-config.sxp and add the line (network-xen-multi-bridge). A typical xend-config.sxp file should have the following line. Comment this line out. Use the # symbol to comment out lines.
    network-script network-bridge
    
    Below is the commented out line and the new line, containing the network-xen-multi-bridge parameter to enable multiple network bridges.
    #network-script network-bridge
    network-script network-xen-multi-bridge
  4. Create a script to create multiple network bridges. This example creates a script called network-xen-multi-bridge.sh in the /etc/xen/scripts/ directory. A sample scripts is below, this example script will create two Xen network bridges (xenbr0 and xenbr1) one will be attached to eth1 and the other one to eth0. If you want to create additional bridges just follow the example in the script and copy nad paste the lines as required:
    #!/bin/sh
    # network-xen-multi-bridge
    # Exit if anything goes wrong.
    set -e
    # First arg is the operation.
    OP=$1
    shift
    script=/etc/xen/scripts/network-bridge.xen
    case ${OP} in
    start)
    	$script start vifnum=1 bridge=xenbr1 netdev=eth1
    	$script start vifnum=0 bridge=xenbr0 netdev=eth0
    	;;
    stop)
    	$script stop vifnum=1 bridge=xenbr1 netdev=eth1
    	$script stop vifnum=0 bridge=xenbr0 netdev=eth0
    	;;
    status)
    	$script status vifnum=1 bridge=xenbr1 netdev=eth1
    	$script status vifnum=0 bridge=xenbr0 netdev=eth0
    	;;
    *)
    	echo 'Unknown command: ' ${OP}
    	echo 'Valid commands are: start, stop, status'
    	exit 1
    esac
    
  5. Make the script executable.
    # chmod +x /etc/xen/scripts/network-xen-multi-bridge.sh
  6. Restart networking or restart the system to activate the bridges.
    # service network restart
Multiple bridges should now be configured for guests on the Xen hypervisor.

11.2. Red Hat Enterprise Linux 5.0 ラップトップネットワークの設定

Red Hat Enterprise Linux 5.1 又はそれ以降対応

このセクションでは、ネットワークブリッジを手動で追加する方法を説明します。この手順は、 Red Hat Enterprise Linux のバージョン 5.0 以降の全てのバージョンでは必要でもなく、また 推奨もされません。5.0 以降の新しいバージョンは、virt-manager でゲストを作成するときに "仮想ネットワーク" アダプタを使用します。NetworkManager は Red Hat Enterprise Linux 5.1 及び それ以降でデフォルトで仮想ネットワークデバイスを使用して作動します。
仮想ネットワークデバイス用の virsh XML 設定ファイルのサンプル:
<interface type='network'>
	<mac address='AA:AA:AA:AA:AA:AA'/>
	<source network='default'/>
	<target dev='vnet0'/>
	<model type='virtio'/>
</interface>
xm 設定ファイル内で、仮想ネットワークデバイスは "vif" のラベルを持ちます。
The challenge in running the Xen hypervisor on a laptop is that most laptops will connected to the network via wireless network or wired connections. Often these connections are switched multiple times a day. In such an environment, the system assumes it has access to the same interface all the time and it also can perform ifup or ifdown calls to the network interface it is using. In addition wireless network cards do not work well in a virtualization environment due to Xen's (default) bridged network usage.
このセットアップはユーザーがラップトップにアクティブなネットワーク接続を 持たない時にオフラインモードで Xen を実行できるようにします。ラップトップ上で Xen を実行する最も簡単な方法は、以下に概要のある手順に従うことです:
  • You will be configuring a 'dummy' network interface which will be used by Xen. In this example the interface is called dummy0. This will also allow you to use a hidden IP address space for your guests.
  • DHCP は DHCP 要求のためのダミーインターフェイスをリッスンしないため、静的 IPアドレスを 使用する必要があります。ユーザー自身のバージョンの DHCP をコンパイルしてダミーインターフェイスで リッスンするようにはできます。しかし、Xen 環境内で DNS、DHCP、及び tftpboot サービスの為の dnsmasq の使用を考慮してみましょう。セットアップと設定はこの章/セクションの後半で説明してあります。
  • NAT と IP マスカレーディングを設定することにより、ゲストからのネットワークへの アクセスを有効にできます。
ダミーネットワークインターフェイスの設定
使用するホスト上で以下の設定手順を実行します:
  1. dummy0 のネットワークインターフェイスを作成して、それに静的 IP アドレスを割り当てます。 ここでの例では、現在の環境でルーティング問題を防止するために 10.1.1.1 を選択しています。 ダミーデバイスサポートを有効にするには、以下の行を /etc/modprobe.conf に追加します。
    alias dummy0 dummy
    options dummy numdummies=1
    
  2. dummy0 用のネットワーキングを設定するには、/etc/sysconfig/network-scripts/ifcfg-dummy0 を編集/作成します:
    DEVICE=dummy0
    BOOTPROTO=none
    ONBOOT=yes
    USERCTL=no
    IPV6INIT=no
    PEERDNS=yes
    TYPE=Ethernet
    NETMASK=255.255.255.0
    IPADDR=10.1.1.1
    ARP=yes
    
  3. xenbr0dummy0 に バインドして、物理ネットワークに接続していない時でもネットワークを使用できるようにします。 /etc/xen/xend-config.sxp を編集して、netdev=dummy0 エントリを含むようにします:
    (network-script 'network-bridge bridge=xenbr0 netdev=dummy0')
    
  4. Open /etc/sysconfig/network in the guest and modify the default gateway to point to dummy0. If you are using a static IP, set the guest's IP address to exist on the same subnet as dummy0.
    NETWORKING=yes
    HOSTNAME=localhost.localdomain
    GATEWAY=10.1.1.1
    IPADDR=10.1.1.10
    NETMASK=255.255.255.0
    
  5. ホスト内に NAT をセットアップすると、ワイヤレスを含むインターネットアクセスがゲストで可能になります。 そして Xen とワイヤレスカードの問題を解決します。以下のスクリプトにより、現在ユーザーの ネットワーク接続で使用されているインターフェイスを基にした NAT を有効にします。
仮想化ゲスト用 NAT の設定
NAT (Network address translation) を使用すると、パケットの妨害をしてそれをプライベート IP アドレスに 渡すことにより複数のネットワークアドレスが 1つの IP アドレスを介して接続できるようになります。 以下のスクリプトを /etc/init.d/xenLaptopNAT にコピーして、/etc/rc3.d/S99xenLaptopNAT へのソフトリンクを作成することができます。これが自動的に ブート時に NAT を開始します。

NetworkManager とワイヤレス NAT

以下のスクリプトは、スタートアップ遅延のため、ワイヤレスネットワークや NetworkManager ではうまく機能しない可能性があります。 この場合、マシンがブートした後にスクリプトを手動で実行することになります。
#!/bin/bash
PATH=/usr/bin:/sbin:/bin:/usr/sbin
export PATH
GATEWAYDEV=`ip route | grep default | awk {'print $5'}`
iptables -F
case "$1" in
start)
	if test -z "$GATEWAYDEV"; then
	echo "No gateway device found"
    else
	echo  "Masquerading using $GATEWAYDEV"
	/sbin/iptables -t nat -A POSTROUTING -o $GATEWAYDEV -j MASQUERADE
fi
	echo "Enabling IP forwarding"
	echo 1 > /proc/sys/net/ipv4/ip_forward
	echo "IP forwarding set to `cat /proc/sys/net/ipv4/ip_forward`"
	echo "done."
	;;
*)
echo "Usage: $0 {start|restart|status}"
;;
esac
DNS、DHCP、及び tftpboot サービスのために dnsmasq を設定します。
ラップトップ(又は、単独の安定したネットワーク接続に継っていないいずれかのコンピュータ)上で 仮想化を実行することの挑戦課題の1つは、ネットワークインターフェイスの変化と可用性です。 ダミーネットワークインターフェイスを使用すると、より安定した環境を設立できますが、それはまた、 DHCP、DNS、及び tftpboot サービスなどをユーザーの仮想化マシン/ゲストに提供することに於いて新しい挑戦を 持ち込みます。Red Hat Enterprise Linux と Fedora Core で配付されているデフォルトの DHCP デーモンは ダミーインターフェイスでリッスンしません。ユーザーの DNS 転送された情報は、異なるネットワークや VPN に 接続すると変化する可能性があります。
上記の挑戦課題への1つの解決案は、1つのパッケージのみで上記のサービスの全てを 提供できて、ユーザーが自分のダミーインターフェイスからの要求のみに利用可能なサービスを 制御できるようにしてくれる dnsmasq の使用です。以下に、仮想化を実行しているラップトップで dnsmasq を設定する方法についての短い説明を示します:
  • ここ から最新バージョンの dnsmasq を取得します。
  • Documentation for dnsmasq can be found here.
  • Copy the other files referenced below from http://et.redhat.com/~jmh/tools/xen/ and grab the file dnsmasq.tgz. The tar archive includes the following files:
    • nm-dnsmasq は NetworkManager の為のディスパッチャスクリプトとして 使用できます。これは NetworkManager が接続に変化を検出する度に実行されて、dnsmasq の 再スタート/再ロードを強制します。これは /etc/NetworkManager/dispatcher.d/nm-dnsmasq に コピーする必要があります。
    • xenDNSmasq は、/etc/init.d/xenDNSmasq の 主要スタートアップ、又はシャットダウンのスクリプトとして使用できます。
    • dnsmasq.conf/etc/dnsmasq.conf の サンプルの設定ファイルです。
    • dnsmasq/usr/local/sbin/dnsmasq のバイナリイメージです。
  • dnsmasq (デフォルトインストールは /usr/local/sbin/dnsmasq への バイナリ)を展開してビルドした後は、dnsmasq 設定ファイルを編集する必要があります。このファイルは /etc/dnsmaqs.conf にあります。
  • 設定を編集してユーザーのローカルニーズと要件に合うようにします。以下の パラメータはたぶんユーザーが修正すべきものでしょう:
    • interface パラメータは dnsmasq が 指定したインターフェイスのみで DHCPDNS 要求をリッスンするようにします。それは ダミーインターフェイスでもありえますが、ユーザーの公共インターフェイスやローカルループバックインターフェイス ではありえません。複数インターフェイスの為にもう1つの interface 行を 追加します。interface=dummy0 は、dummy0 インターフェイスでリッスンする1つの例です。
    • 統合された DHCP サーバーを有効にする dhcp-range には、リース及びオプションのリース期間用に 利用できるアドレスの範囲を供給する必要があります。複数のネットワークを使用している場合は、 DHCP を適用したい各ネットワーク上でこれを繰り返す 必要があります。1つの例として、dhcp-range=10.1.1.10,10.1.1.50,255.255.255.0,12h が あります(ネットワーク 10.1.1.* 用であり、12時間のリース期間)。
    • dnsmasq により供給されたデフォルトのルートを上書きするための dhcp-option は ルーターが dnsmasq を実行しているマシンと同じだと想定します。例としては dhcp-option=3,10.1.1.1 があります。
  • dnsmasq を設定した後は、以下にあるスクリプトを xenDNSmasq として、 /etc/init.d にコピーできます。
  • システムブート中に自動的に dnsmasq を開始したい場合は、chkconfig(8) を使用して それを登録する必要があります:
    chkconfig --add xenDNSmasq
    
    自動スタートアップ用にそれを有効にします:
    chkconfig --levels 345 xenDNSmasq on
    
  • NetworkManager が接続の変化を検出する度に 再スタートするように dnsmasq を設定するには、 供給されているスクリプト nm-dnsmasq を使用すれば 達成できます。
    • nm-dnsmasq スクリプトを /etc/NetworkManager/dispatcher.d/ にコピーします。
    • NetworkManager ディスパッチャは、接続に 変化がある度にそのスクリプト(同じディレクトリ内に他のスクリプトがあるとアルファベット順)を 実行します。
  • dnsmasq もまた ユーザーの /etc/resolv.conf 内の変化を検出して自動的にそれらを再ロードします (例えば VPN セッションをスタートした場合など)。
  • ユーザーが隠れたネットワークに仮想化ゲストを持ち、それらに公共ネットワークへの アクセスを許可している場合、nm-dnsmasq スクリプトと xenDNSmasq スクリプトは両方共、NAT もセットアップします。

第12章 Xen Para-virtualized ドライバー

Para-virtualized drivers provide increased performance for fully virtualized Red Hat Enterprise Linux guests. Use these drivers if you are using fully virtualized Red Hat Enterprise Linux guests and require better performance.

その他の para-virtualized ドライバー

Windows 対応の Xen と KVM hypervisor 用には他の para-virtualized ドライバーが あります。
Xen ホスト上の Windows ゲスト用には、そのインストールと管理を案内している Windows Para-virtualized ドライバーガイド を参照して 下さい。
For Windows guests on KVM hosts, refer to 13章KVM Para-virtualized ドライバー.
para-virtualized ドライバー用の RPM パッケージには、サポートのある Red Hat Enterprise Linux ゲストオペレーティングシステムの為の ストレージとネットワーキング用の para-virtualized ドライバーモジュールが含まれています。これらのドライバーは Red Hat Enterprise Linux 5.1 (又はそれ以降)のホスト上で無修正の Red Hat Enterprise Linux ゲスト 内で I/O 処理能力のハイパフォーマンスを可能にします。
サポートされているゲストオペレーティングシステムを以下に示します:
  • Red Hat Enterprise Linux 3
  • Red Hat Enterprise Linux 4
  • Red Hat Enterprise Linux 5

para-virtualized ドライバーの為のアーキテクチャサポート

最低限のゲストオペレーティングシステム要件はアーキテクチャ依存です。 x86 と x86-64 のゲストのみがサポートされています。
Red Hat Enterprise Linux 3 以前の Red Hat Enterprise Linux ゲストオペレーティング システムではこのドライバーはサポートされていません。
仮想化のプラットフォームとして Red Hat Enterprise Linux 5 を使用すると、 システム管理者が Linux と Windows の作業負荷を、増加したパワーと冷却効率を持つ 新しくてより強力なハードウェアに統合できるようになります。Red Hat Enterprise Linux 4 (update 6 の時点)と Red Hat Enterprise Linux 5 の ゲスト オペレーティングシステムは背後にある仮想化技術を認識し、特定のインターフェイスと 能力を使用して効率的にその技術と交流します。このアプローチはベアメタルシステム上で 実行しているのと比較して同等レベルの処理能力とパフォーマンス特性を達成できます。
As para-virtualization requires a modified guest operating system, not all operating systems can use para-virtualization. For operating systems which can not be modified, full virtualization is required. Full virtualization, by default, uses emulated disk, network, video and other hardware devices. Emulated I/O devices can be very slow and are not suited for applications requiring high disk and/or network throughput. The majority of the performance loss with virtualization occurs through the use of emulated devices.
para-virtualized デバイスドライバーは Red Hat Enterprise Linux パッケージに 収納されています。para-virtualized デバイスドライバーのみが背後にある仮想プラット フォームを認識している(OS の他の部分は認識していない)ため、このドライバーは 無修正の OS に対して para-virtualized ゲスト OS の優越したパフォーマンスを提供 します。
para-virtualized デバイスドライバーをインストールした後は、ディスクデバイスや ネットワークカードは通常の物理ディスクやネットワークカードとしてオペレーティング システムに現れ続けます。しかし、その後デバイスドライバーは仮想化プラットフォーム (模倣無し)と直接交流して、効率的にディスクとネットワークアクセスを提供し、ディスクと ネットワークサブシステムが仮想化環境内でもネイティブに近いスピードで動作できるようにします。 そして既存のゲストオペレーティングシステムへの変更を必要としません。
para-virtualized ドライバーは特定のホスト要件を持っています。64 bit の ホストは以下を実行できます:
  • 32 bit ゲスト
  • 64 bit ゲスト
  • 32 bit ゲストと 64 bit ゲストの混合

12.1. システム要件

このセクションでは、Red Hat Enterprise Linux で使用する para-virtualized ドライバーの要件を提供します。
インストール
para-virtualized ドライバーをインストールする前に、以下の要件(一覧表内)が 満足されることを確認して下さい。

Red Hat Enterprise Linux 4.7 及び 5.3 及びそれ以降

Red Hat Enterprise Linux の 4.7 と 5.3 以降の 全ての バージョンは、para-virtualized ドライバー、pv-on-hvm モジュール用のカーネル モジュールをデフォルトのカーネルパッケージ内に持っています。このことは、 para-virtualized ドライバーが Red Hat Enterprise Linux 4.7 とそれ以降、又は 5.3 とそれ以降のゲスト用に利用可能だと言う意味になります。
それぞれのゲストオペレーティングシステムインストール毎に para-virtualized ドライバーのための以下の RPM パッケージが必要です。
Minimum host operating system version:
  • Red Hat Enterprise Linux 5.1 or newer.
Minimum guest operating system version:
  • Red Hat Enterprise Linux 5.1 or newer.
  • Red Hat Enterprise Linux 4 Update 6 or newer.
  • Red Hat Enterprise Linux 3 Update 9 or newer.
Red Hat Enterprise Linux 5 requires:
  • kmod-xenpv.
Red Hat Enterprise Linux 4 requires:
  • kmod-xenpv,
  • modules-init-tools (for versions prior to Red Hat Enterprise Linux 4.6z you require modules-init-tools-3.1-0.pre5.3.4.el4_6.1 or greater), and
  • modversions.
Red Hat Enterprise Linux 3 requires:
  • kmod-xenpv.
You require at least 50MB of free disk space in the /lib file system.

12.2. Para-virtualization の制約とサポート

このセクションでは、Red Hat Enterprise Linux 上での para-virtualized ドライバーの使用に於けるサポートの制約と必要事項に ついて概要を示します。サポートされる事項とサポートに課される 制約は以下のセクションでご覧になれます。
サポートされているゲストオペレーティングシステム
para-virtualized ドライバーへのサポートは、以下のオペレーティング システムとバージョンで利用可能です:
  • Red Hat Enterprise Linux 5.1 及びそれ以降
  • Red Hat Enterprise Linux 4 Update 6 及びそれ以降
  • Red Hat Enterprise Linux 3 Update 9 及びそれ以降
64 bit Red Hat Enterprise Linux 5 Virtualization 上での、para-virtualized ドライバーを持つ 32 bit ゲストオペレーティングシステムの 実行はサポートされています。
以下の表では、para-virtualized ドライバーでサポートされているカーネルの変種が 示してあります。以下のコマンドを使用すると、自分のホスト上に現在インストール されている正確なカーネル改訂版を識別することができます。 出力を表と比較してサポートされているかどうか判定して下さい。
# rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
Red Hat Enterprise Linux 5 i686 及び x86_64 のカーネル変種には、 SMP(Symmetric Multiprocessing)が含まれており、別途に SMP の カーネル RPM を必要としません。
以下の表で、Red Hat Enterprise Linux 3 ゲスト用のプロセッサ特有のカーネル 要件に注意を払って下さい。
表12.1 para-virtualized ドライバー用のサポートされているゲストカーネルアーキテクチャ
カーネルアーキテクチャ Red Hat Enterprise Linux 3 Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5
athlon サポート有り (AMD)   
athlon-SMP サポート有り (AMD)   
i32e サポート有り (Intel)   
i686 サポート有り (Intel) サポート有り サポート有り
i686-PAE サポート有り
i686-SMP サポート有り (Intel) サポート有り  
i686-HUGEMEM サポート有り (Intel) サポート有り  
x86_64 サポート有り (AMD) サポート有り サポート有り
x86_64-SMP サポート有り (AMD) サポート有り  
x86_64-LARGESMP サポート有り  
Itanium (IA64) サポート有り

重要

ホストシステムは Red Hat Enterprise Linux 5.1 又はそれ以降を必要とします。

使用中のカーネルを検出

以下のコマンドの出力を書き留めて記憶して置きます。この値が ダウンロードすべきパッケージとモジュールを決定する値です。
# rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
出力は以下に似ているはずです:
kernel-PAE-2.6.18-53.1.4.el5.i686
カーネルの名前は PAE (Physical Address Extensions の略)で、カーネル バージョンは 2.6.18 で、リリースが 53.1.4.el5 で、アーキテクチャが i686 となっています。カーネルの rpm は常に kernel-name-version-release.arch.rpm の 形式になっています。
重要な制約
Para-virtualized デバイスドライバーは、ゲストオペレーティングシステムの 正常なインストールの後で、インストールできます。これらのドライバーを インストールできるようになるには、稼働中のホストとゲストが必要です。

Para-virtualized ブロックデバイスと GRUB

GRUB は現時点では、para-virtualized の ブロックデバイスにアクセスできません。そのため、ゲストは、para-virtualized ブロックデバイスドライバーを使用するデバイスからはブート出来ません。 特に、MBR(Master Boot Record)を含むディスク、ブートローダー(GRUB) を 含むディスク、又はカーネルの initrd イメージを含むディスクでは出来ません。 /boot のディレクトリやパーティションを含んでいるディスクはいずれも、 para-virtualized ブロックデバイスドライバーを使用できないと言うことになります。
Red Hat Enterprise Linux 3 カーネル変種アーキテクチャの依存関係
Red Hat Enterprise Linux 3 ベースのゲストオペレーティングシステムには、 以下の表で見えるように、プロセッサ特有のカーネルと para-virtualized ドライバー RPM を 使用しなければなりません。適合する para-virtualized ドライバーパッケージをインストール できないと、xen-pci-platform モジュールのロードは失敗します。
以下の表は、ゲストが Intel プロセッサ用にコンパイルされている場合に Red Hat Enterprise Linux 3 ゲストを稼働するのに必要となるホストカーネルを 示しています。
表12.2 Intel プロセッサ用の Red Hat Enterprise Linux 3 上で para-virtualized ドライバーを使用するゲストの為の必須ホストカーネルアーキテクチャ
ゲストカーネルタイプ 必須のホストカーネルタイプ
ia32e (UP と SMP) x86_64
i686 i686
i686-SMP i686
i686-HUGEMEM i686

以下の表は ゲストが AMD プロセッサ用にコンパイルされている場合に Red Hat Enterprise Linux 3 ゲストを稼働するのに必要となるホストカーネルを 示しています。
表12.3 AMD プロセッサ用の Red Hat Enterprise Linux 3 上で para-virtualized ドライバーを使用するゲストの為の必須ホストカーネルアーキテクチャ
ゲストカーネルタイプ 必須のホストカーネルタイプ
athlon i686
athlon-SMP i686
x86_64 x86_64
x86_64-SMP x86_64

12.3. Para-virtualized ドライバーのインストール

以下の3つの章では、para-virtualized ドライバーを持つ Red Hat Enterprise Linux 5.1 か それ以降のバージョンで実行する完全仮想化ゲストのインストールと設定の方法を説明して います。

始める前に使用アーキテクチャがサポートされていることを確認して下さい。

Para-virtualized ドライバーは特定のハードウェアとバージョンの組み合わせでのみ サポートされています。para-virtualized ドライバーをインストールする前に、ご使用の ハートウェアとオペレーティングシステムの要件が満足されているかどうかを確認して下さい。

新規インストールの為の para-virtualized ドライバーの利便性を最大利用

新しくゲストシステムをインストールしている場合は、para-virtualized の ブロックデバイスドライバーから最大限の利便性を得るために、少なくとも 2つのディスクでゲストを作成すべきです。
MBR と ブートローダ(GRUB)を収納 しているディスクのため、及び /boot パーティションのために para-virtualized ドライバーを使用します。このパーティションは非常に小さいもので十分です。 その理由は、それが /boot パーティションを保持するだけの十分な 容量があればいいからです。
2つめのディスクとその他のディスクはすべて他のパーティション用(例えば、//usr)、又は論理ボリューム用に使用します。
このインストール方法を使用すると、ゲストのインストールが完了した後に para-virtualized のブロックデバイスドライバーがインストールされた場合に、 ゲストの起動と /boot パーティションへのアクセス のみが仮想化ブロックデバイスドライバーを使用することになります。

12.3.1. 共通のインストール手順

以下の一覧は、全てのゲストオペレーティングシステムバージョンに渡って共通の 高水準の手順を説明しています。
  1. Copy the RPMs for your hardware architecture to a suitable location in your guest operating system. Your home directory is sufficient. If you do not know which RPM you require verify against the table at 「Para-virtualization の制約とサポート」.
  2. rpm コマンド、又は yum コマンドを 使用して、パッケージをインストールします。rpm ユーティリティは 以下の 4つの新規カーネルモジュールを /lib/modules/[%kversion][%kvariant]/extra/xenpv/%release にインストールします:
    • the PCI infrastructure module, xen_platform_pci.ko,
    • the ballooning module, xen_balloon.ko,
    • the virtual block device module, xen_vbd.ko,
    • and the virtual network device module, xen_vnif.ko.
  3. ゲストオペレーティングシステムが para-virtualized ドライバーの自動ロードを サポートしていない場合(例えば、Red Hat Enterprise Linux 3)、必要な ポストインストールステップを実行して、そのドライバーをオペレーティングシステム 特有の場所にコピーします。
  4. ゲストオペレーティングシステムをシャットダウン
  5. Reconfigure the guest operating system's configuration file on the host to use the installed para-virtualized drivers.
  6. ネットワークデバイス用の “type=ioemu” エントリを削除します。
  7. Add any additional disk partitions, volumes or LUNs to the guest so that they can be accessed via the para-virtualized (xen-vbd) disk driver.
  8. For each physical device, LUN, partition or volume you want to use the para-virtualized drivers you must edit the disk entry for that device in the libvirt configuration file.
  9. A typical disk entry resembles the following:
    <disk type='file' device='disk'>
      <driver name='file'/>
      <source file='/dev/hda6'/>
      <target dev='hda'/>
    </disk>
    
    Modify each disk entry, as desired, to use the para-virtualized by changing the driver elements as shown below.
    <disk type='file' device='disk'>
      <driver name='tap' type='aio'/>
      <source file='/dev/hda6'/>
      <target dev='xvda'/>
    </disk>
    
  10. para-virtualized ブロックデバイスドライバー用に使用したい追加のストレージ エンティティを追加します。
  11. ゲストを再起動します:
    # xm start YourGuestName
    Where YourGuestName is the name of the configuration file or the guest operating system's name as defined in its configuration file in the name = "os_name" parameter.
  12. Reconfigure the guest network.

12.3.2. Red Hat Enterprise Linux 3 で Para-virtualized ドライバーのインストールと 設定

このセクションには、Red Hat Enterprise 3 ゲストオペレーティングシステム内での para-virtualized ドライバーに関する詳細案内が含まれています。

注記

これらのパッケージは para-virtualized ディスクからのブートをサポートしていません。 ゲストオペレーティングシステムカーネルのブートには、まだ模倣 IDE ドライバーが 必要です。他の(システム関連ではない)ユーザースペースアプリケーションとデータは para-virtualized ブロックデバイスドライバーを使用することができます。
ドライバーのインストール
para-virtualized ドライバーを使用した Red Hat Enterprise Linux 3 ゲストのインストールに必要な手順を以下に示します。
  1. Install the latest kernel version. The para-virtualized drivers require at least Red Hat Enterprise Linux 3.9 kernel version kernel-2.4.21-60.EL for all the required headers.
  2. 使用しているハードウェアアーキテクチャとカーネル変種用の kmod-xenpv rpm を ゲストオペレーティングシステムにコピーします。
  3. rpm ユーティリティを使用して RPM パッケージをインストール します。使用するゲストオペレーティングシステムの変種とアーキテクチャに必要なパッケージを 正しく識別していることを確認して下さい。
    [root@rhel3]# rpm -ivh kmod-xenpv*
    
  4. Use the commands below load the para-virtualized driver modules. %kvariant is the kernel variant the para-virtualized drivers have been build against and %release corresponds to the release version of the para-virtualized drivers.
    [root@rhel3]# mkdir -p /lib/modules/'uname -r'/extra/xenpv
    [root@rhel3]# cp -R /lib/modules/2.4.21-52.EL[%kvariant]/extra/xenpv/%release \
    /lib/modules/'uname -r'/extra/xenpv
    [root@rhel3]# depmod -ae
    [root@rhel3]# modprobe xen-vbd
    [root@rhel3]# modprobe xen-vnif
    

    注記

    Red Hat Enterprise Linux 3 が MODVERSIONS を 有効にしているため、バイナリドライバーモジュールをインストールする時点で、 insmod が警告を生成します。これらの警告は無視 できるものです。
  5. /etc/modules.conf を確証して、以下のような eth0 用のエイリアスがあることを 確認します。複数のインターフェイスを設定する予定の場合は、各インターフェイス毎に追加の 行を加えます。
    alias eth0 xen-vnif
    
    /etc/rc.local を編集して行を追加します:
    insmod /lib/modules/'uname -r'/extra/xenpv/%release/xen-vbd.o
    

    注記

    “%release” を 実際の para-virtualized ドライバーのリリースバージョン(例えば、0.1-5.el)で 入れ替えます。para-virtualized ドライバーRPM パッケージを更新する場合は、そのリリースバージョンを 適切なバージョンに更新することを確認して下さい。
  6. 仮想マシンをシャットダウンします(ゲスト内で “#shutdown -h now” を使用)。
  7. Edit the guest configuration file in /etc/xen/YourGuestName with a text editor, performing the following changes:
    • vif=” エントリから “type=ioemu” エントリを削除します。
    • 追加のディスクパーティション、ボリューム、又は LUN をゲストに追加して para-virtualized (xen-vbd) ゲストドライバー経由で それらにアクセスできるようにします。
    • For each physical device, LUN, partition or volume you want to use the para-virtualized drivers you must edit the disk entry for that device in the libvirt configuration file.
    • A typical disk entry resembles the following:
      <disk type='file' device='disk'>
        <driver name='file'/>
        <source file='/dev/hda6'/>
        <target dev='hda'/>
      </disk>
      
      Modify each disk entry, as desired, to use the para-virtualized by changing the driver elements as shown below.
      <disk type='file' device='disk'>
        <driver name='tap' type='aio'/>
        <source file='/dev/hda6'/>
        <target dev='xvda'/>
      </disk>
      
      
    • Once complete, save the modified configuration file and restart the guest.
  8. Boot the virtual machine:
    # xm start YourGuestName
    Where YourGuestName is the name of the configuration file or the guest operating system's name as defined in its configuration file in the name = "os_name" parameter.

注意して下さい

weak-modulesmodversions のサポートは Red Hat Enterprise Linux 3 で提供されていないため、 para-virtualized ドライバーはシステムへの自動的追加とロードはされません。 モジュールを挿入するには、以下のコマンドを実行します。
insmod xen_vbd.ko
Red Hat Enterprise Linux 3 では xen-vbd を使用するブロック デバイス用に特殊ファイルの手動作成が必要になります。以下の手順が、para-virtualized ブロックデバイスの作成法と登録の案内となります。
para-virtualized ブロックデバイスドライバーがロードされた後に、 以下のスクリプトを使用して特殊なファイルを作成します。
#!/bin/sh
module="xvd"
mode="664"
major=`awk "\\$2==\"$module\" {print \\$1}" /proc/devices`
# < mknod for as many or few partitions on xvd disk attached to FV guest >
# change/add xvda to xvdb, xvbd, etc. for 2nd, 3rd, etc., disk added in
# in xen config file, respectively.
mknod /dev/xvdb b $major 16
mknod /dev/xvdb1 b $major 17
mknod /dev/xvdb2 b $major 18
chgrp disk /dev/xvd*
chmod 0660 /dev/xvd*
各追加の仮想ディスクに、マイナー番号を 16 単位で増加します。以下の例では、追加デバイスマイナー番号 16 が作成されています。
# mknod /dev/xvdc b $major 16
# mknod /dev/xvdc1 b $major 17
これが、以下のコマンドで作成される次のデバイスを 32 にします:
# mknod /dev/xvdd b $major 32
# mknod /dev/xvdd1 b $major 33
ここで、作成したパーティションが使用できることを確認します。
[root@rhel3]# cat /proc/partitions
major   minor     #blocks   name

  3        0      10485760  hda
  3        1        104391  hda1
  3        2      10377990  hda2
202        16         64000  xvdb
202        17         32000  xvdb1
202        18        32000  xvdb2
253        0       8257536  dm-0
253        1       2031616  dm-1
上記の出力で、パーティション設定をしたデバイス “xvdb” がシステムに利用可能であることが判ります。
以下の手順はゲストに新しいデバイスを追加して、再起動後にそれを永続化します。 全てのこれらのコマンドはゲスト上で実行されるものです。
  1. ブロックデバイスイメージをマウントするディレクトリを作成します。
    [root@rhel3]# mkdir /mnt/pvdisk_p1
    [root@rhel3]# mkdir /mnt/pvdisk_p2
    
  2. デバイスを新しいフォルダにマウントします。
    [root@rhel3]# mount /dev/xvdb1 /mnt/pvdisk_p1
    [root@rhel3]# mount /dev/xvdb2 /mnt/pvdisk_p2
    
  3. デバイスが正常にマウントされたことを確認します。
    [root@rhel3]# df /mnt/pvdisk_p1
    Filesystem           1K-blocks      Used   Available Use%  Mounted on
    /dev/xvdb1               32000        15       31985   1%  /mnt/pvdisk_p1
    
  4. ブートシーケンス中にデバイスがマウントされるようにゲスト内で /etc/fstab ファイルを更新します。以下の行を追加して下さい:
    /dev/xvdb1   /mnt/pvdisk_p1   ext3    defaults        1 2
    /dev/xvdb2   /mnt/pvdisk_p2   ext3    defaults        1 2
    

パフォーマンスのヒント

Using a Red Hat Enterprise Linux 5.1 host (dom0), the "noapic" parameter should be added to the kernel boot line in your virtual guest's /boot/grub/grub.conf entry as seen below. Keep in mind your architecture and kernel version may be different.
kernel /vmlinuz-2.6.9-67.EL ro root=/dev/VolGroup00/rhel4_x86_64 rhgb noapic
Red Hat Enterprise Linux 5.2 dom0 はゲスト用にこのカーネルパラメータを 必要としません。

重要

Itanium (ia64) binary RPM パッケージとビルドは現在、使用できません。

12.3.3. Red Hat Enterprise Linux 4 上で Para-virtualized ドライバーのインストールと 設定

このセクションには、Red Hat Enterprise 4 ゲストオペレーティングシステム内での para-virtualized ドライバーに関する詳細案内が含まれています。

注記

これらのパッケージは para-virtualized ディスクからのブートをサポートしていません。 ゲストオペレーティングシステムカーネルのブートには、まだ模倣 IDE ドライバーが 必要です。他の(システム関連ではない)ユーザースペースアプリケーションとデータは para-virtualized ブロックデバイスドライバーを使用することができます。
ドライバーのインストール
para-virtualized ドライバーを使用した Red Hat Enterprise Linux 4 ゲストのインストールに必要な手順を以下に示します。
  1. 使用しているハードウェアアーキテクチャとカーネル変種用の kmod-xenpvmodules-init-tools、及び modversions の RPM 群を ゲストオペレーティングシステムにコピーします。
  2. rpm ユーティリティを使用して RPM パッケージ群を インストールします。使用するゲストオペレーティングシステムの変種とアーキテクチャに必要な パッケージを正しく識別していることを確認して下さい。このパッケージには、更新した module-init-tools が必要となり、これは Red Hat Enterprise Linux 4-6-z カーネル、又はそれ以降で利用できます。
    [root@rhel4]# rpm -ivh modversions
    [root@rhel4]# rpm -Uvh module-init-tools
    [root@rhel4]# rpm -ivh kmod-xenpv*
    

    注記

    UP、SMP、Hugemem、及びアーキテクチャ用に異なるパッケージがあります。 そのため、ご使用のカーネルに適した RPM を持っていることを確認して下さい。
  3. Execute cat /etc/modprobe.conf to verify you have an alias for eth0 like the one below. If you are planning to configure multiple interfaces add an additional line for each interface. If it does not look like the entry below change it.
    alias eth0 xen-vnif
    
  4. 仮想マシンをシャットダウンします(ゲスト内で “#shutdown -h now” を使用)。
  5. 以下のようにして /etc/xen/YourGuestsName 内の ゲスト設定ファイルを編集します:
    • vif=” エントリから “type=ioemu” エントリを削除します。
    • 追加のディスクパーティション、ボリューム、又は LUN をゲストに追加して para-virtualized (xen-vbd) ゲストドライバー経由で それらにアクセスできるようにします。
    • 各追加の物理デバイス、LUN、パーティション、又はボリューム用に、以下に示した ようなエントリを、ゲスト設定ファイル内の “disk=” セクションに追加します。オリジナルの “disk=” エントリも 以下のエントリに似ているかも知れません。
      disk = [ "file:/var/lib/libvirt/images/rhel4_64_fv.dsk,hda,w"]
      
    • 追加の物理デバイス、LUN、パーティション、又はボリュームを追加すると、 XML 設定ファイル内の para-virtualized ドライバーのエントリは以下にある エントリに似たものになります。
      disk = [ "file:/var/lib/libvirt/images/rhel3_64_fv.dsk,hda,w",
      "tap:aio:/var/lib/libvirt/images/UserStorage.dsk,xvda,w" ]
      

      注記

      ファイルベースのイメージが使用されている場合、para-virtualized デバイスに “tap:aio” を使用します。
  6. virsh コマンドを使用して仮想マシンをブートします:
    # virsh start YourGuestName
仮想ゲストの最初の再起動で、kudzu がユーザーに "Realtek ネットワークデバイスを維持するか、削除する" 、及び "xen-bridge デバイスを設定する" の選択を尋ねてきます。 xen-bridge は設定して、Realtek ネットワークデバイスは 削除すべきです。

パフォーマンスのヒント

Using a Red Hat Enterprise Linux 5.1 host (dom0), the "noapic" parameter should be added to the kernel boot line in your virtual guest's /boot/grub/grub.conf entry as seen below. Keep in mind your architecture and kernel version may be different.
kernel /vmlinuz-2.6.9-67.EL ro root=/dev/VolGroup00/rhel4_x86_64 rhgb noapic
Red Hat Enterprise Linux 5.2 dom0 はゲストの為にこのカーネルパラメータを 必要としません。
ここで、作成したパーティションが使用できることを確認します。
[root@rhel4]# cat /proc/partitions
major    minor   #blocks   name

   3        0    10485760  hda
   3        1      104391  hda1
   3        2    10377990  hda2
 202        0       64000  xvdb
 202        1       32000  xvdb1
 202        2       32000  xvdb2
 253        0     8257536  dm-0
 253        1     2031616  dm-1
上記の出力で、パーティション設定をしたデバイス “xvdb” がシステムに利用可能であることが判ります。
以下の手順は新しいデバイスをゲストに追加して、再起動後にそれを永続化します。 全てのこれらのコマンドはゲスト上で実行されるものです。
  1. ブロックデバイスイメージをマウントするディレクトリを作成します。
    [root@rhel4]# mkdir /mnt/pvdisk_p1
    [root@rhel4]# mkdir /mnt/pvdisk_p2
    
  2. デバイスを新しいフォルダにマウントします。
    [root@rhel4]# mount /dev/xvdb1 /mnt/pvdisk_p1
    [root@rhel4]# mount /dev/xvdb2 /mnt/pvdisk_p2
    
  3. デバイスが正常にマウントされたことを確認します。
    [root@rhel4]# df /mnt/pvdisk_p1
    Filesystem           1K-blocks      Used   Available Use%  Mounted on
    /dev/xvdb1               32000        15       31985   1%  /mnt/pvdisk_p1
    
  4. ブートシーケンス中にデバイスがマウントされるようにゲスト内で /etc/fstab ファイルを 更新します。以下の行を追加して下さい:
    /dev/xvdb1   /mnt/pvdisk_p1   ext3    defaults        1 2
    /dev/xvdb2   /mnt/pvdisk_p2   ext3    defaults        1 2
    

注記

このパッケージは Red Hat Enterprise Linux 4 update 2 のシステムとカーネルを 通じた Red Hat Enterprise Linux 4-GA 用にはサポートがありません。

重要な注記

IA64 binary RPM パッケージとビルドは現在、使用できません。

自動モジュールローディング

xen-vbd ドライバーは自動的にロードしない可能性が あります。以下のコマンドで %release を para-virtualized ドライバー の正しいリリースバージョンで入れ替えて、ゲスト上で実行して 下さい。
# insmod /lib/modules/'uname -r'/weak-updates/xenpv/%release/xen_vbd.ko

12.3.4. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 5

This section contains detailed instructions for the para-virtualized drivers in a Red Hat Enterprise Linux 5 guest operating system.

注記

これらのパッケージは para-virtualized ディスクからのブートをサポートしていません。 ゲストオペレーティングシステムカーネルのブートには、まだ模倣 IDE ドライバーが 必要です。他の(システム関連ではない)ユーザースペースアプリケーションとデータは para-virtualized ブロックデバイスドライバーを使用することができます。
The procedure below covers the steps to enable the para-virtualized drivers for a Red Hat Enterprise Linux 5 guest.
手順12.1 Enable para-virtualized drivers for a Red Hat Enterprise Linux Guest
  1. 仮想マシンをシャットダウンします(ゲスト内で “#shutdown -h now” を使用)。
  2. 以下のようにして、/etc/xen/<Your GuestsName> 内のゲスト設定ファイルを編集します。
    1. vif=” エントリから “type=ioemu” エントリを削除します。
    2. 追加のディスクパーティション、ボリューム、あるいは LUN をゲストに追加して、 para-virtualized (xen-vbd) ディスクドライバー経由で それらにアクセスできるようにします。
    3. 各追加の物理デバイス、LUN、パーティション、又はボリューム用に、以下に示した ようなエントリを、ゲスト設定ファイル内の “disk=” セクションに追加します。オリジナルの “disk=” エントリも 以下のエントリに似ているかも知れません。
      disk = [ "file:/var/lib/libvirt/images/rhel4_64_fv.dsk,hda,w"]
      
    4. 追加の物理デバイス、LUN、パーティション、又はボリュームを追加すると、 XML 設定ファイル内の para-virtualized ドライバーのエントリは以下にある エントリに似たものになります。
      disk = [ "file:/var/lib/libvirt/images/rhel3_64_fv.dsk,hda,w",
      "tap:aio:/var/lib/libvirt/images/UserStorage.dsk,xvda,w" ]
      

      注記

      ファイルベースのイメージが使用されている場合は、para-virtualized デバイス用に “tap:aio” を使用します。
  3. virsh コマンドを使用して仮想マシンをブートします:
    # virsh start YourGuestName
    
para-virtualized ドライバーをインストールした後に、ネットワークインターフェイスが 立ち上がっていることを確認するには、ゲスト上で以下のコマンドを発行します。 割り当て済みの IP アドレスを含んだインターフェイス情報が表示されるはずです。
[root@rhel5]# ifconfig eth0
ここで、作成したパーティションが利用可能であることを確認します。
[root@rhel5]# cat /proc/partitions
major minor  #blocks    name
   3     0   10485760   hda
   3     1     104391   hda1
   3     2   10377990   hda2
 202     0      64000   xvdb
 202     1      32000   xvdb1
 202     2      32000   xvdb2
 253     0    8257536   dm-0
 253     1    2031616   dm-1
上記の出力では、パーティション設定したデバイス “xvdb” がシステムに利用可能であることが判ります。
以下の手順は、新しいデバイスをゲストに追加して、それを再起動後に永続化します。 全てのこれらのコマンドはゲスト上で実行します。
  1. ディレクトリを作成してブロックデバイスイメージのマウント用とします。
    [root@rhel5]# mkdir /mnt/pvdisk_p1
    [root@rhel5]# mkdir /mnt/pvdisk_p2
    
  2. デバイスを新しいフォルダにマウントします。
    [root@rhel5]# mount /dev/xvdb1 /mnt/pvdisk_p1
    [root@rhel5]# mount /dev/xvdb2 /mnt/pvdisk_p2
    
  3. デバイスが正常にマウントされたことを確認します。
    [root@rhel5]# df /mnt/pvdisk_p1
    Filesystem           1K-blocks      Used   Available Use%  Mounted on
    /dev/xvdb1               32000        15       31985   1%  /mnt/pvdisk_p1
    
  4. ゲスト内で /etc/fstab ファイルを更新して、ブートシーケンス中に デバイスをマウントするようにします。以下の行を追加して下さい:
    /dev/xvdb1   /mnt/pvdisk_p1   ext3    defaults        1 2
    /dev/xvdb2   /mnt/pvdisk_p2   ext3    defaults        1 2
    

パフォーマンスのヒント

Using a Red Hat Enterprise Linux 5.1 host (dom0), the "noapic" parameter should be added to the kernel boot line in your virtual guest's /boot/grub/grub.conf entry as seen below. Keep in mind your architecture and kernel version may be different.
kernel /vmlinuz-2.6.9-67.EL ro root=/dev/VolGroup00/rhel4_x86_64 rhgb noapic
Red Hat Enterprise Linux 5.2 dom0 は、ゲスト用にこのカーネルパラメータを 必要としません。
Hiding fake interfaces
Sometimes, activating the para-virtualized drivers does not delete the old virtualized network interfaces. To remove these interfaces from guests use the following procedure.
  1. Add the following lines to the /etc/modprobe.d/blacklist file. Blacklist 8139cp and 8139too for the RealTek 8139 and e1000 for the virtualized Intel e1000 NIC.
    8139cp
    8139too
    e1000
    
  2. Remove the old network scripts from the /etc/sysconfig/network-scripts directory.
  3. Reboot the guest. The default network interface should now use the para-virtualized drivers.

12.3.5. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 6

This section describes the use of para-virtualized drivers in a Red Hat Enterprise Linux 6 guest.
The para-virtualized drivers are enabled by default for a Red Hat Enterprise Linux 6 guest. The guest will automatically unplug any emulated devices that are presented to it, and will use the para-virtualized drivers instead.
Although the para-virtualized drivers are enabled by default, they can be disabled. Add the following to the guest kernel command line upon boot to disable the para-virtualized drivers:
xen_emul_unplug=never

12.4. Para-virtualized ネットワークドライバーの設定

Once the para-virtualized network driver is loaded you may need to reconfigure the guest's network interface to reflect the driver and virtual Ethernet card change.
ゲスト内でネットワークインターフェイスの再設定をするには以下の手順に従います。
  1. virt-manager 内で、ゲスト用のコンソールウィンドウを開いて、 root としてログインします。
  2. Red Hat Enterprise Linux 4 では、ファイル /etc/modprobe.conf が “alias eth0 xen-vnif” を含んでいることを 確認します。
    # cat /etc/modprobe.conf
    alias eth0 xen-vnif
    
  3. To display the present settings for eth0 execute “# ifconfig eth0”. If you receive an error about the device not existing you should load the modules manually as outlined in 「para-virtualized ドライバーを手動でロードする」.
    ifconfig eth0
    eth0      Link encap:Ethernet  HWaddr 00:00:00:6A:27:3A  
              BROADCAST MULTICAST  MTU:1500  Metric:1
              RX packets:630150 errors:0 dropped:0 overruns:0 frame:0
              TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:109336431 (104.2 MiB)  TX bytes:846 (846.0 b)
    
  4. Start the network configuration utility(NetworkManager) with the command “# system-config-network”. Click on the “Forward” button to start the network card configuration.
  5. Select the 'Xen Virtual Ethernet Card (eth0)' entry and click 'Forward'.
    Configure the network settings as required.
  6. Complete the configuration by pressing the 'Apply' button.
  7. Press the 'Activate' button to apply the new settings and restart the network.
  8. そうすると、IP アドレスが割り当てられた新規のネットワークインターフェイスが 見えるはずです。
    ifconfig eth0
    eth0      Link encap:Ethernet  HWaddr 00:16:3E:49:E4:E0
              inet addr:192.168.78.180  Bcast:192.168.79.255  Mask:255.255.252.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:630150 errors:0 dropped:0 overruns:0 frame:0
              TX packets:501209 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:109336431 (104.2 MiB)  TX bytes:46265452 (44.1 MiB)
    

12.5. 追加の Para-virtualized ハードウェア設定

このセクションでは、追加の仮想ネットワーク、又はストレージをゲストオペレーティング システムに追加する方法を説明しています。Red Hat Enterprise Linux 5 Virtualization 上での ネットワークとストレージリソースの設定に関する詳細には、Emerging Technologies, Red Hat.com から入手できる ドキュメントをお読み下さい。

12.5.1. 仮想化ネットワークインターフェイス

以下の手順を実行して、使用するゲスト用の追加のネットワークデバイスを設定します。
/etc/xen/YourGuestName 内の YourGuestName を 使用するゲスト名で入れ替えることで、ゲスト設定ファイルを編集します。
オリジナルエントリは以下のように見えるでしょう。
vif = [ "mac=00:16:3e:2e:c5:a9,bridge=xenbr0" ]
追加エントリを設定ファイルの “vif=” セクションに追加します。 以下に似たものになります。
vif = [ "mac=00:16:3e:2e:c5:a9,bridge=xenbr0",
    "mac=00:16:3e:2f:d5:a9,bridge=xenbr0" ]
新規のインターフェイス用には独自の MAC アドレスを生成するようにします。以下のような コマンドを使用できます。
# echo 'import virtinst.util ; print virtinst.util.randomMAC()' | python
ゲストが再起動すると、ゲストオペレーティングシステムの中で以下の手順を実行します。 Red Hat Enterprise Linux 3 内の /etc/modules.conf か、あるいは Red Hat Enterprise Linux 4 及び Red Hat Enterprise Linux 5 では /etc/modprobe.conf に更新が追加されていることを確認します。追加した 新規のインターフェイス用に新しいエイリアスを加えます。
alias eth1 xen-vnif
その後、追加した各新規インターフェイスをテストして、ゲスト内で利用可能な ことを確認します。
# ifconfig eth1
上記のコマンドは eth1 のプロパティを表示します。 3つめのインターフェイスを追加した場合には、eth2 用に このコマンドを繰り返します。
ここで、Red Hat Enterprise Linux3 上では redhat-config-network を使用して、又は 、 Red Hat Enterprise Linux 4 と Red Hat Enterprise Linux 5 上では system-config-network を使用してネットワークインターフェイスを設定します。

12.5.2. 仮想ストレージデバイス

以下の手順を実行して、ゲスト用の追加の仮想ストレージデバイスを 設定します。
/etc/xen/YourGuestNameYourGuestName を 使用するゲスト名で入れ替えることで、ゲストの設定ファイルを編集します。オリジナルのエントリは 以下に似ているでしょう。
disk = [ "file:/var/lib/libvirt/images/rhel5_64_fv.dsk,hda,w"]
ここで、新規の物理デバイス、LUN、パーティション、又はボリューム用の追加のエントリを 設定ファイル内の “disk=” パラメータに加えます。para-virtualized ドライバーを使用するストレージエントリは以下のエントリに似ています。“tap:aio” パラメータは hypervisor に対して para-virtualized ドライバーを使用するように指示します。
disk = [ "file:/var/lib/libvirt/images/rhel5_64_fv.dsk,hda,w",
    "tap:aio:/var/lib/libvirt/images/UserStorage1.dsk,xvda,w" ]
他のエントリを追加したい場合は、それらをコンマ分離の一覧として、“disk=” セクションに追加します。

注記

You need to increment the letter for the 'xvd' device, that is for your second storage entity it would be 'xvdb' instead of 'xvda'.
disk = [ "file:/var/lib/libvirt/images/rhel5_64_fv.dsk,hda,w",
    "tap:aio:/var/lib/libvirt/images/UserStorage1.dsk,xvda,w",
    "tap:aio:/var/lib/libvirt/images/UserStorage2.dsk,xvdb,w" ]
パーティションが作成されて利用可能であることを確認します。
# cat /proc/partitions
major minor  #blocks    name
   3     0   10485760   hda
   3     1     104391   hda1
   3     2   10377990   hda2
 202     0      64000   xvda
 202     1      64000   xvdb
 253     0    8257536   dm-0
 253     1    2031616   dm-1
上記の出力では、パーティション、又はデバイス、“xvdb” はシステムに利用可能です。
新規のデバイスとディスクをローカルマウントポイントにマウントして、 ゲストの内の /etc/fstab を更新することにより、 ブート時にデバイスとパーティションがマウントされます。
# mkdir /mnt/pvdisk_xvda
# mkdir /mnt/pvdisk_xvdb
# mount /dev/xvda /mnt/pvdisk_xvda
# mount /dev/xvdb /mnt/pvdisk_xvdb
# df /mnt
Filesystem           1K-blocks      Used   Available Use%  Mounted on
/dev/xvda                64000        15       63985   1%  /mnt/pvdisk_xvda
/dev/xvdb                64000        15       63985   1%  /mnt/pvdisk_xvdb

第13章 KVM Para-virtualized ドライバー

Para-virtualized drivers are available for virtualized Windows guests running on KVM hosts. These para-virtualized drivers are included in the virtio-win package. The virtio-win package supports block (storage) devices and network interface controllers.
As with the KVM module, the virtio-win drivers package is only available on hosts running Red Hat Enterprise Linux 5.4 and newer.
Para-virtualized ドライバーは完全仮想化ゲストのパフォーマンスを強化します。 Para-virtualized ドライバーを使用すると、ゲスト I/O 遅延は減少し、スループットは ベアメタルレベル近くまで向上します。I/O が重いタスクやアプリケーションを実行している 完全仮想化ゲストには、Para-virtualized ドライバーの使用が推奨されます。
The KVM para-virtualized drivers are automatically loaded and installed on the following versions of Red Hat Enterprise Linux:
  • Red Hat Enterprise Linux 4.8 and newer
  • Red Hat Enterprise Linux 5.3 and newer
  • Red Hat Enterprise Linux 6.
Those Red Hat Enterprise Linux versions detect and install the drivers so additional installation steps are not required.

注記

PCI devices are limited by the virtualized system architecture. Out of the 32 available PCI devices for a guest 4 are not removable. This means there are up to 28 PCI slots available for additional devices per guest. Each PCI device can have up to 8 functions; some PCI devices have multiple functions and only use one slot. Para-virtualized network, para-virtualized disk devices, or other PCI devices using VT-d all use slots or functions. The exact number of devices available is difficult to calculate due to the number of available devices. Each guest can use up to 32 PCI devices with each device having up to 8 functions.
以下の Microsoft Windows のバージョンは KVM para-virtualized ドライバーを サポートしています:
  • Windows XP (32-bit only)
  • Windows Server 2003 (32-bit and 64-bit versions)
  • Windows Server 2008 (32-bit and 64-bit versions)
  • Windows 7 (32-bit and 64-bit versions)

13.1. KVM Windows para-virtualized ドライバーのインストール

このセクションでは、KVM Windows para-virtualized ドライバーのインストール プロセスを取り扱います。KVM para-virtualized ドライバーは Windows のインストール中に、 ロードするか 又はゲストのインストール後にインストールすることができます。
You can install the para-virtualized drivers on your guest by one of the following methods:
  • hosting the installation files on a network accessible to the guest,
  • using a virtualized CD-ROM device of the driver installation disk .iso file, or
  • using a virtualized floppy device to install the drivers during boot time (for Windows guests).
This guide describes installation from the para-virtualized installer disk as a virtualized CD-ROM device.
  1. ドライバーをダウンロード

    The virtio-win package contains the para-virtualized block and network drivers for all supported Windows guests.
    If the Red Hat Enterprise Linux Supplementary channel entitlements are not enabled for the system, the download will not be available. Enable the Red Hat Enterprise Linux Supplementary channel to access the virtio-win package.
    Download the virtio-win package with the yum command.
    # yum install virtio-win
    
    The drivers are also available on the Red Hat Enterprise Linux Supplementary disc or from Microsoft (windowsservercatalog.com). Note that the Red Hat Enterprise Virtualization Hypervisor and Red Hat Enterprise Linux are created on the same code base so the drivers for the same version (for example, 5.5) are supported for both environments.
    virtio-win パッケージは CD-ROM イメージ(virtio-win.iso ファイル)を /usr/share/virtio-win/ ディレクトリ内にインストールします。
  2. para-virtualized ドライバーのインストール

    デバイスを添付や修正して para-virtualized ドライバーを使用する前に、 ゲスト上にドライバーをインストールすることが推奨されます。
    root ファイルシステムを格納しているブロックデバイス、又はゲストのブートに必要となる 他のブロックデバイスには、ドライバーはデバイスが修正される前にインストールされなければ なりません。ゲスト上にドライバーがインストールされていなくて、ドライバーが virtio ドライバーに セットされている場合は、ゲストはブートしません。
Installing drivers with a virtualized CD-ROM
This procedure covers installing the para-virtualized drivers with a virtualized CD-ROM after Windows is installed.
Follow 手順13.1「Windows ゲスト用に virt-manager を使用して CD-ROM イメージを マウント」 to add a CD-ROM image with virt-manager and then install the drivers.
手順13.1 Windows ゲスト用に virt-manager を使用して CD-ROM イメージを マウント
  1. Open virt-manager and the virtualized guest

    Open virt-manager, select your virtualized guest from the list by double clicking the guest name.
  2. Open the hardware tab

    Click the Add Hardware button in the Hardware tab.
  3. Select the device type

    This opens a wizard for adding the new device. Select Storage from the dropdown menu.
    Click the Forward button to proceed.
  4. Select the ISO file

    Choose the File (disk image) option and set the file location of the para-virtualized drivers .iso image file. The location file is named /usr/share/virtio-win/virtio-win.iso.
    ドライバーが物理 CD 内に格納されている場合は、通常のディスクパーティション オプションを使用します。
    Set the Device type to IDE cdrom and click Forward to proceed.
  5. Disc assigned

    The disk has been assigned and is available for the guest once the guest is started. Click Finish to close the wizard or back if you made a mistake.
  6. Reboot

    Reboot or start the guest to add the new device. Virtualized IDE devices require a restart before they can be recognized by guests.
Once the CD-ROM with the drivers is attached and the guest has started, proceed with 手順13.2「Windows installation」.
手順13.2 Windows installation
  1. Open My Computer

    On the Windows guest, open My Computer and select the CD-ROM drive.
  2. Select the correct installation files

    There are four files available on the disc. Select the drivers you require for your guest's architecture:
    • the para-virtualized block device driver (RHEV-Block.msi for 32-bit guests or RHEV-Block64.msi for 64-bit guests),
    • the para-virtualized network device driver (RHEV-Network.msi for 32-bit guests or RHEV-Block64.msi for 64-bit guests),
    • or both the block and network device drivers.
    Double click the installation files to install the drivers.
  3. Install the block device driver

    1. Start the block device driver installation

      Double click RHEV-Block.msi or RHEV-Block64.msi.
      Press Next to continue.
    2. Confirm the exception

      Windows may prompt for a security exception.
      Press Yes if it is correct.
    3. Finish

      Press Finish to complete the installation.
  4. Install the network device driver

    1. Start the network device driver installation

      Double click RHEV-Network.msi or RHEV-Network64.msi.
      Press Next to continue.
    2. Performance setting

      This screen configures advanced TCP settings for the network driver. TCP timestamps and TCP window scaling can be enabled or disabled. The default is, 1, for window scaling to be enabled.
      TCP window scaling is covered by IETF RFC 1323. The RFC defines a method of increasing the receive window size to a size greater than the default maximum of 65,535 bytes up to a new maximum of 1 gigabyte (1,073,741,824 bytes). TCP window scaling allows networks to transfer at closer to theoretical network bandwidth limits. Larger receive windows may not be supported by some networking hardware or operating systems.
      TCP timestamps are also defined by IETF RFC 1323. TCP timestamps are used to better calculate Return Travel Time estimates by embedding timing information is embedded in packets. TCP timestamps help the system to adapt to changing traffic levels and avoid congestion issues on busy networks.
      ValueAction
      0Disable TCP timestamps and window scaling.
      1Enable TCP window scaling.
      2Enable TCP timestamps.
      3Enable TCP timestamps and window scaling.
      Press Next to continue.
    3. Confirm the exception

      Windows may prompt for a security exception.
      Press Yes if it is correct.
    4. Finish

      Press Finish to complete the installation.
  5. Reboot

    Reboot the guest to complete the driver installation.
Change the device configuration to use the para-virtualized drivers (「既存のデバイスに KVM para-virtualized ドライバーを使用する」) or install a new device which uses the para-virtualized drivers (「新規デバイス用に KVM para-virtualized ドライバーを使用する」).

13.2. Installing drivers with a virtualized floppy disk

この手続きは Windows のインストール時に para-virtualized ドライバーの インストールをします。
  • 一度限りのメニューを使用して Windows VM を初めてインストールしたら、 viostor.vfd をフロッピィとして添付します。
    1. Windows Server 2003

      Windows がサードパーティドライバー用に F6 を押すように催促したら、 それを押して画面上の指示に従います。
    2. Windows Server 2008

      インストーラがドライバーを催促した時には、 Load Driver をクリックして、 インストーラをドライブ A: にポイントし、使用中のゲスト OS と アーキテクチャに適合する ドライバーを選択します。

13.3. 既存のデバイスに KVM para-virtualized ドライバーを使用する

Modify an existing hard disk device attached to the guest to use the virtio driver instead of virtualized IDE driver. This example edits libvirt configuration files. Alternatively, virt-manager, virsh attach-disk or virsh attach-interface can add a new device using the para-virtualized drivers 「新規デバイス用に KVM para-virtualized ドライバーを使用する」.
  1. 仮想化した IDE ドライバーを使用したファイルベースのブロックデバイスを以下に示します。 これは、para-virtualized ドライバーを使用しない仮想化ゲストの標準的なエントリです。
    <disk type='file' device='disk'>
       <source file='/var/lib/libvirt/images/disk1.img'/>
       <target dev='vda' bus='ide'/>
    </disk>
    
  2. bus= エントリを virtio に 変更することにより、para-virtualized デバイスを使用するためにエントリを変更します。
    <disk type='file' device='disk'>
       <source file='/var/lib/libvirt/images/disk1.img'/>
       <target dev='vda' bus='virtio'/>
    </disk>
    

13.4. 新規デバイス用に KVM para-virtualized ドライバーを使用する

この手続きは、virt-manager で、KVM para-virtualized ドライバーを使用した新規デバイスの作成を示しています。
別の方法として、 para-virtualized ドライバーを使用するデバイスを添付するために virsh attach-diskvirsh attach-interface のコマンドが使用できます。

ドライバーを最初にインストールします

新規のデバイスをインストールする前に、Windows ゲスト上にドライバーが インストールされていることを確認します。ドライバーが利用できない場合は、 デバイスは認識されず機能しません。
  1. virt-manager 内のゲスト名をダブルクリックして 仮想化ゲストを開きます。
  2. ハードウェア タブを開きます。
  3. ハードウェアを追加 をクリックします。
  4. 仮想ハードウェアの追加タブで、デバイスのタイプに ストレージ 又は ネットワーク を選択します。
    1. New disk devices
      ストレージデバイスか、又はファイルベースイメージを選択します。Virtio Diskデバイスタイプ として選び、進む をクリックします。
    2. New network devices
      仮想ネットワーク 又は 共有物理デバイス を 選択します。デバイスタイプ として virtio を 選択して、進む をクリックします。
  5. 完了 をクリックしてデバイスを保存します。
  6. ゲストをリブートします。デバイスは Windows ゲストが再スタートするまで 認識されないかも知れません。

第14章 PCI passthrough

この章では、Xen と KVM hypervisors を用いた PCI passthrough の使用法について説明しています。
KVM and Xen hypervisors support attaching PCI devices on the host system to virtualized guests. PCI passthrough allows guests to have exclusive access to PCI devices for a range of tasks. PCI passthrough allows PCI devices to appear and behave as if they were physically attached to the guest operating system.
PCI devices are limited by the virtualized system architecture. Out of the 32 available PCI devices for a guest 4 are not removable. This means there are up to 28 PCI slots available for additional devices per guest. Each PCI device can have up to 8 functions; some PCI devices have multiple functions and only use one slot. Para-virtualized network, para-virtualized disk devices, or other PCI devices using VT-d all use slots or functions. The exact number of devices available is difficult to calculate due to the number of available devices. Each guest can use up to 32 PCI devices with each device having up to 8 functions.
The VT-d or AMD IOMMU extensions must be enabled in BIOS.
手順14.1 Preparing an Intel system for PCI passthrough
  1. Enable the Intel VT-d extensions

    The Intel VT-d extensions provides hardware support for directly assigning a physical devices to guest. The main benefit of the feature is to improve the performance as native for device access.
    The VT-d extensions are required for PCI passthrough with Red Hat Enterprise Linux. The extensions must be enabled in the BIOS. Some system manufacturers disable these extensions by default.
    These extensions are often called various terms in BIOS which differ from manufacturer to manufacturer. Consult your system manufacturer's documentation.
  2. Activate Intel VT-d in the kernel

    Activate Intel VT-d in the kernel by appending the intel_iommu=on parameter to the kernel line of the kernel line in the /boot/grub/grub.conf file.
    The example below is a modified grub.conf file with Intel VT-d activated.
    default=0
    timeout=5
    splashimage=(hd0,0)/grub/splash.xpm.gz
    hiddenmenu
    title Red Hat Enterprise Linux Server (2.6.18-190.el5)
       root (hd0,0)
       kernel /vmlinuz-2.6.18-190.el5 ro root=/dev/VolGroup00/LogVol00 intel_iommu=on
       initrd /initrd-2.6.18-190.el5.img
  3. Ready to use

    Reboot the system to enable the changes. Your system is now PCI passthrough capable.
手順14.2 Preparing an AMD system for PCI passthrough
  • Enable AMD IOMMU extensions

    The AMD IOMMU extensions are required for PCI passthrough with Red Hat Enterprise Linux. The extensions must be enabled in the BIOS. Some system manufacturers disable these extensions by default.
AMD systems only require that the IOMMU is enabled in the BIOS. The system is ready for PCI passthrough once the IOMMU is enabled.

PCI passthrough with Xen

Xen and KVM require different kernel arguments to enable PCI passthrough. The previous instructions are for KVM. For both AMD and Intel systems, PCI passthrough on Xen requires the iommu=on parameter to the hypervisor command line. Modify the /boot/grub/grub.conf file as follows to enable PCI passthrough:
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server (2.6.18-192.el5)
   root (hd0,0)
   kernel /xen.gz-2.6.18-192.el5 iommu=on
   module /vmlinuz-2.6.18-192.el5xen ro root=/dev/VolGroup00/LogVol00 
   module /initrd-2.6.18-190.el5xen.img

14.1. Adding a PCI device with virsh

These steps cover adding a PCI device to a fully virtualized guest under the Xen or KVM hypervisors using hardware-assisted PCI passthrough. Refer to 「PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux」 for details on adding a PCI device to a para-virtualized Xen guest.

重要

The VT-d or AMD IOMMU extensions must be enabled in BIOS.
This example uses a USB controller device with the PCI identifier code, pci_8086_3a6c, and a fully virtualized guest named win2k3.
  1. Identify the device

    Identify the PCI device designated for passthrough to the guest. The virsh nodedev-list command lists all devices attached to the system. The --tree option is useful for identifying devices attached to the PCI device (for example, disk controllers and USB controllers).
    # virsh nodedev-list --tree
    For a list of only PCI devices, run the following command:
    # virsh nodedev-list | grep pci
    Each PCI device is identified by a string in the following format (Where **** is a four digit hexadecimal code):
    pci_8086_****
    

    Tip: determining the PCI device

    Comparing lspci output to lspci -n (which turns off name resolution) output can assist in deriving which device has which device identifier code.
    Record the PCI device number; the number is needed in other steps.
  2. Information on the domain, bus and function are available from output of the virsh nodedev-dumpxml command:
    # virsh nodedev-dumpxml pci_8086_3a6c
    <device>
      <name>pci_8086_3a6c</name>
      <parent>computer</parent>
      <capability type='pci'>
        <domain>0</domain>
        <bus>0</bus>
        <slot>26</slot>
        <function>7</function>
        <id='0x3a6c'>82801JD/DO (ICH10 Family) USB2 EHCI Controller #2</product>
        <vendor id='0x8086'>Intel Corporation</vendor>
      </capability>
    </device>
  3. Detach the device from the system. Attached devices cannot be used and may cause various errors if connected to a guest without detaching first.
    # virsh nodedev-dettach pci_8086_3a6c 
    Device pci_8086_3a6c dettached
  4. Convert slot and function values to hexadecimal values (from decimal) to get the PCI bus addresses. Append "0x" to the beginning of the output to tell the computer that the value is a hexadecimal number.
    For example, if bus = 0, slot = 26 and function = 7 run the following:
    $ printf %x 0
    0
    $ printf %x 26
    1a
    $ printf %x 7
    7
    The values to use:
    bus='0x00'
    slot='0x1a'
    function='0x7'
  5. Run virsh edit (or virsh attach device) and add a device entry in the <devices> section to attach the PCI device to the guest. Only run this command on offline guests. Red Hat Enterprise Linux does not support hotplugging PCI devices at this time.
    # virsh edit win2k3
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
          <address domain='0x0000' bus='0x00' slot='0x1a' function='0x7'/>
      </source>
    </hostdev>
  6. Once the guest system is configured to use the PCI address, we need to tell the host system to stop using it. The ehci driver is loaded by default for the USB PCI controller.
    $ readlink /sys/bus/pci/devices/0000\:00\:1d.7/driver
    ../../../bus/pci/drivers/ehci_hcd
  7. Detach the device:
    $ virsh nodedev-dettach pci_8086_3a6c
  8. Verify it is now under the control of pci_stub:
    $ readlink /sys/bus/pci/devices/0000\:00\:1d.7/driver
    ../../../bus/pci/drivers/pci-stub
  9. Set a sebool to allow the management of the PCI device from the guest:
    # setsebool -P virt_use_sysfs 1
  10. Start the guest system :
    # virsh start win2k3
    
The PCI device should now be successfully attached to the guest and accessible to the guest operating system.

14.2. Adding a PCI device with virt-manager

PCI devices can be added to guests using the graphical virt-manager tool. The following procedure adds a 2 port USB controller to a virtualized guest.
  1. Identify the device

    Identify the PCI device designated for passthrough to the guest. The virsh nodedev-list command lists all devices attached to the system. The --tree option is useful for identifying devices attached to the PCI device (for example, disk controllers and USB controllers).
    # virsh nodedev-list --tree
    For a list of only PCI devices, run the following command:
    # virsh nodedev-list | grep pci
    Each PCI device is identified by a string in the following format (Where **** is a four digit hexadecimal code):
    pci_8086_****
    

    Tip: determining the PCI device

    Comparing lspci output to lspci -n (which turns off name resolution) output can assist in deriving which device has which device identifier code.
    Record the PCI device number; the number is needed in other steps.
  2. Detach the PCI device

    Detach the device from the system.
    # virsh nodedev-dettach pci_8086_3a6c 
    Device pci_8086_3a6c dettached
  3. Power off the guest

    Power off the guest. Hotplugging PCI devices into guests is presently unsupported and may fail or crash.
  4. Open the hardware settings

    Open the virtual machine and select the Hardware tab. Click the Add Hardware button to add a new device to the guest.
  5. Add the new device

    Select Physical Host Device from the Hardware type list. The Physical Host Device represents PCI devices. Click Forward to continue.
  6. Select a PCI device

    Select an unused PCI device. Note that selecting PCI devices presently in use on the host causes errors. In this example a PCI to USB interface device is used.
  7. Confirm the new device

    Click the Finish button to confirm the device setup and add the device to the guest.
The setup is complete and the guest can now use the PCI device.

14.3. PCI passthrough with virt-install

To use PCI passthrough with the virt-install parameter, use the additional --host-device parameter.
  1. Identify the PCI device

    Identify the PCI device designated for passthrough to the guest. The virsh nodedev-list command lists all devices attached to the system. The --tree option is useful for identifying devices attached to the PCI device (for example, disk controllers and USB controllers).
    # virsh nodedev-list --tree
    For a list of only PCI devices, run the following command:
    # virsh nodedev-list | grep pci
    Each PCI device is identified by a string in the following format (Where **** is a four digit hexadecimal code):
    pci_8086_****
    

    Tip: determining the PCI device

    Comparing lspci output to lspci -n (which turns off name resolution) output can assist in deriving which device has which device identifier code.
  2. Add the device

    Use the PCI identifier output from the virsh nodedev command as the value for the --host-device parameter.
    # virt-install \
     -n hostdev-test -r 1024 --vcpus 2 \
     --os-variant fedora11 -v --accelerate \
     -l http://download.fedoraproject.org/pub/fedora/linux/development/x86_64/os \
     -x 'console=ttyS0 vnc' --nonetworks --nographics  \
     --disk pool=default,size=8 \
     --debug --host-device=pci_8086_10bd 
    
  3. Complete the installation

    Complete the guest installation. The PCI device should be attached to the guest.

14.4. PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux

PCI passthrough is used to allow a Xen guest exclusive access to a PCI device, rather than sharing with other guests or with dom0. PCI passthrough for para-virtualized Xen guests is supported on all Red Hat Enterprise Linux 5 systems, however PCI passthrough with fully virtualized guests is only supported on Red Hat Enterprise Linux 5.4 and newer.

警告

PCI passthrough to para-virtualized guests is considered insecure and is not supported for Red Hat Enterprise Linux 6 guests.
Limitations of Xen PCI passthrough:
Any guest using PCI passthrough will no longer be available for save, restore, or migration capabilities, as it will be tied to a particular non-virtualized hardware configuration.
A guest which has access to a non-virtualized PCI device via PCI passthrough also has the potential to access the DMA address space of dom0, which is a potential security concern.
To link a PCI device to a guest the device must first be hidden from the host. If the host is using the device the device cannot be assigned to the guest.
手順14.3 Example: attaching a PCI device
  1. Given a network device which uses the bnx2 driver and has a PCI id of 0000:09:00.0, the following lines added to /etc/modprobe.conf hides the device from dom0. Either the bnx2 module must be reloaded or the host must be restarted.
    install bnx2 /sbin/modprobe pciback; /sbin/modprobe --first-time --ignore-install bnx2
    options pciback hide=(0000:09:00.0)
  2. Multiple PCI identifiers can be added to /etc/modprobe.conf to hide multiple devices.
    options pciback hide=(0000:09:00.0)(0000:0a:04.1)
  3. Use one of the following methods to add the passed-through device to the guest's configuration file:

第15章 SR-IOV

15.1. Introduction

The PCI-SIG (PCI Special Interest Group) developed the Single Root I/O Virtualization (SR-IOV) specification. The PCI-SIG Single Root IOV specification is a standard for a type of PCI passthrough which natively shares a single device to multiple guests. SR-IOV does not require hypervisor involvement in data transfer and management by providing an independent memory space, interrupts, and DMA streams for virtualized guests.
SR-IOV enables a Single Root Function (for example, a single Ethernet port), to appear as multiple, separate, physical devices. A physical device with SR-IOV capabilities can be configured to appear in the PCI configuration space as multiple functions, each device has its own configuration space complete with Base Address Registers (BARs).
SR-IOV uses two new PCI functions:
  • Physical Functions (PFs) are full PCIe devices that include the SR-IOV capabilities. Physical Functions are discovered, managed, and configured as normal PCI devices. Physical Functions configure and manage the SR-IOV functionality by assigning Virtual Functions.
  • Virtual Functions (VFs) are simple PCIe functions that only process I/O. Each Virtual Function is derived from a Physical Function. The number of Virtual Functions a device may have is limited by the device hardware. A single Ethernet port, the Physical Device, may map to many Virtual Functions that can be shared to virtualized guests.
The hypervisor can map one or more Virtual Functions to a virtualized guest. The Virtual Function's configuration space is mapped, by the hypervisor, to the virtualized guest's configuration space.
Each Virtual Function can only be mapped once as Virtual Functions require real hardware. A virtualized guest can have multiple Virtual Functions. A Virtual Function appears as a network card in the same way as a normal network card would appear to an operating system.
The SR-IOV drivers are implemented in the kernel. The core implementation is contained in the PCI subsystem, but there must also be driver support for both the Physical Function (PF) and Virtual Function (VF) devices. With an SR-IOV capable device one can allocate VFs from a PF. The VFs appear as PCI devices which are backed on the physical PCI device by resources (queues, and register sets).
Advantages of SR-IOV
SR-IOV devices can share a single physical port with multiple virtualized guests.
Virtual Functions have near-native performance and provide better performance than para-virtualized drivers and emulated access. Virtual Functions provide data protection between virtualized guests on the same physical server as the data is managed and controlled by the hardware.
These features allow for increased virtualized guest density on hosts within a data center.
Disadvantages of SR-IOV
Live migration is presently unsupported. As with PCI passthrough, identical device configurations are required for live (and offline) migrations. Without identical device configurations, guest's cannot access the passed-through devices after migrating.

15.2. Using SR-IOV

This section covers attaching Virtual Function to a guest as an additional network device.
SR-IOV requires Intel VT-d support.

SR-IOV with Xen

Xen requires additional kernel arguments to use SR-IOV. Modify the /boot/grub/grub.conf file to enable SR-IOV. To enable SR-IOV with Xen for Intel systems append the pci_pt_e820_access=on parameter to the kernel.
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server (2.6.18-192.el5xen)
   root (hd0,0)
   kernel /xen.gz-2.6.18-192.el5 iommu=1
   module /vmlinuz-2.6.18-192.el5xen ro root=/dev/VolGroup00/LogVol00 pci_pt_e820_access=on
   module /initrd-2.6.18-192.el5xen.img
手順15.1 Attach an SR-IOV network device
  1. Enable Intel VT-d in BIOS and in the kernel

    Enable Intel VT-D in BIOS. Refer to 手順14.1「Preparing an Intel system for PCI passthrough」 for more information on enabling Intel VT-d in BIOS and the kernel, or refer to your system manufacturer's documentation for specific instructions.
  2. Verify support

    Verify if the PCI device with SR-IOV capabilities are detected. This example lists an Intel 82576 network interface card which supports SR-IOV. Use the lspci command to verify if the device was detected.
    # 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)
    

    注記

    Note that the output has been modified to remove all other devices.
  3. Start the SR-IOV kernel modules

    If the device is supported the driver kernel module should be loaded automatically by the kernel. Optional parameters can be passed to the module using the modprobe command. The Intel 82576 network interface card uses the igb driver kernel module.
    # modprobe igb [<option>=<VAL1>,<VAL2>,]
    # lsmod |grep igb
    igb    87592  0
    dca    6708    1 igb
    
  4. Activate Virtual Functions

    The max_vfs parameter of the igb module allocates the maximum number of Virtual Functions. The max_vfs parameter causes the driver to spawn, up to the value of the parameter in, Virtual Functions. For this particular card the valid range is 0 to 7.
    Remove the module to change the variable.
    # modprobe -r igb
    Restart the module with the max_vfs set to 1 or any number of Virtual Functions up to the maximum supported by your device.
    # modprobe igb max_vfs=1
    
  5. Inspect the new Virtual Functions

    Using the lspci command, list the newly added Virtual Functions attached to the Intel 82576 network device.
    # lspci | grep 82576
    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)
    03:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    03:10.1 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    
    The identifier for the PCI device is found with the -n parameter of the lspci command.
    # lspci -n | grep 03:00.0
    03:00.0 0200: 8086:10c9 (rev 01)
    # lspci -n | grep 03:10.0
    03:10.0 0200: 8086:10ca (rev 01)
    
    The Physical Function corresponds to 8086:10c9 and the Virtual Function to 8086:10ca.
  6. Find the devices with virsh

    The libvirt service must find the device to add a device to a guest. Use the virsh nodedev-list command to list available host devices.
    # virsh nodedev-list | grep 8086
    pci_8086_10c9
    pci_8086_10c9_0
    pci_8086_10ca
    pci_8086_10ca_0
    [output truncated]
    
    The serial numbers for the Virtual Functions and Physical Functions should be in the list.
  7. Get advanced details

    The pci_8086_10c9 is one of the Physical Functions and pci_8086_10ca_0 is the first corresponding Virtual Function for that Physical Function. Use the virsh nodedev-dumpxml command to get advanced output for both devices.
    # virsh nodedev-dumpxml pci_8086_10ca
    # virsh nodedev-dumpxml pci_8086_10ca_0
    <device>
      <name>pci_8086_10ca_0</name>
      <parent>pci_8086_3408</parent>
      <driver>
        <name>igbvf</name>
      </driver>
      <capability type='pci'>
        <domain>0</domain>
        <bus>3</bus>
        <slot>16</slot>
        <function>1</function>
        <product id='0x10ca'>82576 Virtual Function</product>
        <vendor id='0x8086'>Intel Corporation</vendor>
      </capability>
    </device>
    
    This example adds the Virtual Function pci_8086_10ca_0 to the guest in ステップ 8. Note the bus, slot and function parameters of the Virtual Function, these are required for adding the device.
  8. Add the Virtual Function to the guest

    1. Shut down the guest.
    2. Use the output from the virsh nodedev-dumpxml pci_8086_10ca_0 command to calculate the values for the configuration file. Convert slot and function values to hexadecimal values (from decimal) to get the PCI bus addresses. Append "0x" to the beginning of the output to tell the computer that the value is a hexadecimal number.
      The example device has the following values: bus = 3, slot = 16 and function = 1. Use the printf utility to convert decimal values to hexadecimal values.
      $ printf %x 3
      3
      $ printf %x 16
      10
      $ printf %x 1
      1
      This example would use the following values in the configuration file:
      bus='0x03'
      slot='0x10'
      function='0x01'
    3. Open the XML configuration file with the virsh edit command. This example edits a guest named MyGuest.
      # virsh edit MyGuest
      
    4. The default text editor will open the libvirt configuration file for the guest. Add the new device to the devices section of the XML configuration file.
      <hostdev mode='subsystem' type='pci' managed='yes'>
            <source>
              <address bus='0x03' slot='0x10' function='0x01'/>
            </source>
      </hostdev>
      
    5. Save the configuration.
  9. Restart

    Restart the guest to complete the installation.
    # virsh start MyGuest
    
The guest should start successfully and detect a new network interface card. This new card is the Virtual Function of the SR-IOV device.

15.3. Troubleshooting SR-IOV

This section contains some issues and solutions for problems which may affect SR-IOV.
Error starting the guest
Start the configured vm , an error reported as follows:
# 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
This error is often caused by a device which is already assigned to another guest or to the host itself.

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

仮想化はゲストの時刻維持に対して諸々の懸念を与えます。一部の CPU がこの 不変タイムスタンプ カウンタを持っていないため、TSC (Time Stamp Counter) をクロックのソースとして使用する ゲストは 時刻維持問題に陥ります。正確な時刻維持を持たないゲストは実際の時刻よりも進んだり 遅れたりして同期から外れるため、一部のネットワークアプリケーションに深刻な影響を与えます。
KVM はゲストに para-virtualized クロックを装備することでこの問題を回避します。 別の方法として、一部のゲストはこれらのオペレーティングシステムの将来のバージョンで その時刻維持のために他の x86 クロックソースを使用する可能性があります。
今のところ、Red Hat Enterprise Linux 5.4 及びそれ以降のゲストのみが全面的に para-virtualized のクロックをサポートしています。
ゲストは、不正確なクロックとカウンタの原因で数種の問題を持つようになります:
  • クロックは正確な時刻との同期から外れて、セッションを無効にしたり ネットワークに影響したりします。
  • 遅くれるクロックを持つゲストは移行で問題を持つ可能性があります。
これらの問題は他の仮想化プラットフォーム上に存在しており、タイミングは 常にテストされるべきです。

NTP

NTP (Network Time Protocol) デーモンはホストとゲスト上で稼働している必要があります。 ntpd サービスを有効にして下さい:
# service ntpd start
ntpd サービスをデフォルトのスタートアップシーケンスに追加します:
# chkconfig ntpd on
ntpd サービスを使用すると、全ての ケースでクロックのずれの効果を最低限に抑えることができるはずです。
使用している CPU が不変タイムスタンプカウンタを持つかどうかを判定
constant_tsc フラグが存在する場合は、 使用中の CPU が不変タイムスタンプカウンタを持っていることになります。 その CPU が constant_tsc フラグを持つか どうかを判定するには、以下のコマンドを実行します:
$ cat /proc/cpuinfo | grep constant_tsc
なんらかの出力が表示されると、その CPU が constant_tsc ビットを持つことになります。出力がない場合は以下の案内に 従ってください。
不変タイムスタンプカウンタ無しでホストを設定
不変タイムスタンプカウンタを持たないシステムは追加の設定を必要とします。 パワーマネジメント機能は正確な時刻維持を邪魔するため、ゲスト用にはそれを 無効にして KVM での時刻維持を保護します。

注記

これらの案内は AMD 改訂 F cpus 用のみのものです。
CPU に constant_tsc ビットが無い場合、 全てのパワーマネジメント機能 (BZ#513138) を無効にして下さい。 各システムはいくつかのタイマーで時刻を維持しています。TSC はホスト上で不安定 であり、時には cpufreq 変更、deep C 状態、又は より速い TSC を持つホストへの移行により影響を受けます。 カーネルの deep C 状態 を防止するには、ホスト上で grub.conf ファイル内のカーネルブートオプションに "processor.max_cstate=1" を追加します:
term Red Hat Enterprise Linux Server (2.6.18-159.el5)
        root (hd0,0)
	kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet processor.max_cstate=1
constant_tsc の無いホスト上でのみ)cpufreq を 無効にするには、/etc/sysconfig/cpuspeed 設定ファイルの編集により、MIN_SPEED 変数と MAX_SPEED 変数を利用できる最高の周波数に変更します。 その有効な限界は /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies ファイル内で見ることができます。
Red Hat Enterprise Linux ゲストで para-virtualized クロックの使用
特定の Red Hat Enterprise Linux ゲストには、追加のカーネルパラメータが 必要になります。これらのパラメータは、ゲストの /boot/grub/grub.conf ファイル内の /kernel 行の末尾にそれら自身を追記することによりセットできます。
以下の表では、そのような Red Hat Enterprise Linux のバージョンと 不変タイムスタンプカウンタを持たないシステム上のゲストで必要となるパラメータを示しています。
Red Hat Enterprise Linuxその他のゲストカーネルパラメータ
para-virtualized クロックを持つ 5.4 AMD64/Intel 64追加のパラメータは無用です
para-virtualized クロックを持たない 5.4 AMD64/Intel 64divider=10 notsc lpj=n
para-virtualized クロックを持つ 5.4 x86追加のパラメータは無用です
para-virtualized クロックを持たない 5.4 x86divider=10 clocksource=acpi_pm lpj=n
5.3 AMD64/Intel 64divider=10 notsc
5.3 x86divider=10 clocksource=acpi_pm
4.8 AMD64/Intel 64notsc divider=10
4.8 x86clock=pmtmr divider=10
3.9 AMD64/Intel 64追加のパラメータは無用です
3.9 x86追加のパラメータは無用です
Using the Real-Time Clock with Windows Server 2003 and Windows XP guests
Windows は RTC (Real-Time Clock) と TSC (Time Stamp Counter) の両方を 使用します。Windows ゲストには、TSC の代わりに、全ての時刻ソースのために 時刻維持問題を解決する Real-Time Clock を使用します。
PMTIMER クロックソース(PMTIMER は通常 TSC を使用)用に Real-Time Clock を 有効にするには、Windows のブート設定に以下の行を追加します。Windows のブート設定は boot.ini ファイル内にありますので、boot.ini ファイルに以下の 行を追加して下さい:
/use pmtimer
Windows のブートセッティングと pmtimer オプションに関する詳細情報には Windows XP および Windows Server 2003 の Boot.ini ファイルで使用可能なスイッチ オプション を参照して下さい。
Using the Real-Time Clock with Windows Vista, Windows Server 2008 and Windows 7 guests
Windows は RTC (Real-Time Clock) と TSC (Time Stamp Counter) の両方を 使用します。Windows ゲストには、TSC の代わりに、全ての時刻ソースのために 時刻維持問題を解決する Real-Time Clock を使用します。
The boot.ini file is no longer used from Windows Vista and newer. Windows Vista, Windows Server 2008 and Windows 7 use the Boot Configuration Data Editor (bcdedit.exe) to modify the Windows boot parameters.
This procedure is only required if the guest is having time keeping issues. Time keeping issues may not affect guests on all host systems.
  1. Open the Windows guest.
  2. Open the Accessories menu of the start menu. Right click on the Command Prompt application, select Run as Administrator.
  3. Confirm the security exception, if prompted.
  4. Set the boot manager to use the platform clock. This should instruct Windows to use the PM timer for the primary clock source. The system UUID ({default} in the example below) should be changed if the system UUID is different than the default boot device.
    C:\Windows\system32>bcdedit /set {default} USEPLATFORMCLOCK on
    The operation completed successfully
This fix should improve time keeping for Windows Vista, Windows Server 2008 and Windows 7 guests.

パート IV. 管理

第17章 サーバーの最善使用法

以下のタスクとヒントは、ご使用の Red Hat Enterprise Linux 5 サーバーホスト (dom0) の信頼性の確立と保持を手助けします。
  • SELinux を強制モードで実行します。これは以下のコマンドを実行して達成できます。
    # setenforce 1
    
  • AutoFS, NFS, FTP, HTTP, NIS, telnetd, sendmail などのような不要なサービスを削除、又は 無効にします。
  • サーバー上でプラットフォーム管理に必要となる最低限のユーザーアカウントだけを追加し、 不要なユーザーアカウントは削除します。
  • 使用中のホストでは必要でないアプリケーションの実行は避けて下さい。ホスト上で アプリケーションを実行すると、仮想マシンのパフォーマンスに影響を与えて、サーバーの 安定性にも影響します。サーバーをクラッシュする可能性のあるアプリケーションはいずれも サーバー上の全ての仮想マシンが落ちる原因にもなります。
  • 仮想マシンのインストールとイメージには中心となる場所を使います。仮想マシンの イメージは /var/lib/libvirt/images/ の下に格納すべきです。 仮想マシンのイメージ用に異なるディレクトリを使用している場合は、そのディレクトリを 確実に SELinux ポリシーに追加して、インストールを開始する前にそれを再ラベルします。
  • インストールのソース、ツリー、及びイメージは中心的な場所に保存されるべき です。それは通常、ご使用の vsftpd サーバーの場所になります。

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

企業のインフラストラクチャに仮想化技術を導入する時には、ホストが侵害を受けないことを 確実にする必要があります。Xen hypervisor 内では、ホストはシステム管理を担当し、全ての仮想マシンを管理する権限のあるドメインです。このホストが安全でないと、システム内の他の全てのドメインが脆弱となります。仮想化を使用するシステム上でのセキュリティを強化するのに数種類の方法があります。担当者、又はその組織は、運営仕様を含む 導入プラン を作成して、仮想化ゲストとホストサーバーにどのサービスが必要か、及びそれらのサービスに何が 必要かと言う項目を指定すべきです。導入プランを開発する段階で考慮すべきセキュリティ問題を いくつか以下に示します:
  • ホスト上では必要なサービスのみを実行します。ホスト上で実行しているプロセスと サービスが少ない程、セキュリティとパフォーマンスのレベルが高くなります。
  • Enable Security-Enhanced Linux (SELinux) on the hypervisor. Read 「SELinux と仮想化」 for more information on using SELinux and virtualization.
  • ファイアウォールを使用して、dom0 へのトラフィックを制限します。デフォルトの拒否規則でファイアウォールを設定すると、dom0 への攻撃から保護をする助けになります。また、ネットワークが直面するサービスを制限することも大切です。
  • 一般ユーザーには dom0 へのアクセスを禁止します。一般ユーザーに dom0 へのアクセスを許すと、dom0 を危険に曝す恐れがあります。dom0 は特権用であり、非権限者に許可をすることはセキュリティレベルを低下することになります。

18.1. Storage security issues

Administrators of virtualized guests can change the partitions the host boots in certain circumstances. To prevent this administrators should follow these recommendations:
The host should not use disk labels to identify file systems in the fstab file, the initrd file or used by the kernel command line. If less privileged users, especially virtualized guests, have write access to whole partitions or LVM volumes.
Guest should not be given write access to whole disks or block devices (for example, /dev/sdb). Use partitions (for example, /dev/sdb1) or LVM volumes.

18.2. SELinux と仮想化

Security Enhanced Linux was developed by the NSA with assistance from the Linux community to provide stronger security for Linux. SELinux limits an attackers abilities and works to prevent many common security exploits such as buffer overflow attacks and privilege escalation. It is because of these benefits that Red Hat recommends all Red Hat Enterprise Linux systems should run with SELinux enabled and in enforcing mode.
SELinux prevents guest images from loading if SELinux is enabled and the images are not correctly labeled. SELinux requires that image files have the virt_image_t label applied to them. The /var/lib/libvirt/images directory has this label applied to it and its contents by default. This does not mean that images must be stored in this directory; images can be stored anywhere, provided they are labeled with virt_image_t.
SELinux を強制モードにして LVM ベースのストレージを追加
以下のセクションは、論理ボリュームを SELinux が有効になった仮想化ゲストに 追加するサンプルです。これらの案内はハードドライブのパーティション設定にも 役に立ちます。
手順18.1 SELinux が有効になった仮想化ゲスト上で論理ボリュームの作成とマウント
  1. 論理ボリュームを作成します。このサンプルでは、NewVolumeName と言う名前の 5ギガバイトの論理ボリュームを volumegroup と言う名前のボリュームグループ上に 作成します。
    # lvcreate -n NewVolumeName -L 5G volumegroup
  2. NewVolumeName の論理ボリュームを ext3 などの 拡張属性をサポートするファイルシステムでフォーマットします。
    # mke2fs -j /dev/volumegroup/NewVolumeName
    
  3. 新規の論理ボリュームをマウントする為の新規ディレクトリを作成します。この ディレクトリはユーザーファイルシステムのどこにでも置けます。しかし、それは 重要なシステムディレクトリ(/etc/var/sys など)や、ホームディレクトリ(/home 又は /root)には配置しないように推奨します。 このサンプルでは、/virtstorage と言うディレクトリを使用します。
    # mkdir /virtstorage
    
  4. 論理ボリュームのマウント
    # mount /dev/volumegroup/NewVolumeName /virtstorage
  5. Set the correct SELinux type for a Xen folder.
    semanage fcontext -a -t xen_image_t "/virtstorage(/.*)?"
    
    別の方法として、KVM のフォルダーに正しい SELinux のタイプをセットします。
    semanage fcontext -a -t virt_image_t "/virtstorage(/.*)?"
    
    targeted ポリシーが使用されている場合(targeted ポリシーがデフォルト)、 このコマンドは /etc/selinux/targeted/contexts/files/file_contexts.local ファイルに1行を追加して、それがこの変更を 恒久化します。追加される1行は以下に似ているものです:
    /virtstorage(/.*)?    system_u:object_r:xen_image_t:s0
    
  6. Label the device node (for example, /dev/volumegroup/NewVolumeName with the correct label:
    # semanage fcontext -a -t xen_image_t /dev/volumegroup/NewVolumeName
    # restorecon /dev/volumegroup/NewVolumeName
    

18.3. SELinux

このセクションには、仮想化のデプロイに於いて SELinux を使用する時点に考慮すべき 事項が含まれています。システムの変更を導入したり、デバイスを追加する時は、 それに応じて SELinux ポリシーを更新する必要があります。ゲスト用に LVM ボリュームを 設定するには、それぞれの背後にあるブロックデバイスとボリューム グループ用に SELinux コンテキストを修正しなければなりません。
# semanage fcontext -a -t xen_image_t -f -b /dev/sda2
# restorecon /dev/sda2
ブーリアンパラメータ xend_disable_t はデーモンを再起動した後に xend を規制のないモードにします。システム全体よりも単独デーモンだけの保護を無効にする方が無難です。ディレクトリを他の場所で使用する xen_image_t として再ラベルすることは避けるように 推奨します。
KVM and SELinux
There are several SELinux booleans which affect KVM. These booleans are listed below for your convenience.
KVM SELinux Booleans
SELinux BooleanDescription
allow_unconfined_qemu_transitionDefault: off. This boolean controls whether KVM guests can be transitioned to unconfined users.
qemu_full_networkDefault: on. This boolean controls full network access to KVM guests.
qemu_use_cifsDefault: on. This boolean controls KVM's access to CIFS or Samba file systems.
qemu_use_commDefault: off. This boolean controls whether KVM can access serial or parallel communications ports.
qemu_use_nfsDefault: on. This boolean controls KVM's access to NFS file systems.
qemu_use_usbDefault: on. This boolean allows KVM to access USB devices.

18.4. Virtualization firewall information

Various ports are used for communication between virtualized guests and management utilities.

Guest network services

Any network service on a virtualized guest must have the applicable ports open on the guest to allow external access. If a network service on a guest is firewalled it will be inaccessible. Always verify the guests network configuration first.
  • ICMP requests must be accepted. ICMP packets are used for network testing. You cannot ping guests if ICMP packets are blocked.
  • Port 22 should be open for SSH access and the initial installation.
  • Ports 80 or 443 (depending on the security settings on the RHEV Manager) are used by the vdsm-reg service to communicate information about the host.
  • Ports 5634 to 6166 are used for guest console access with the SPICE protocol.
  • Port 8002 is used by Xen for live migration.
  • Ports 49152 to 49216 are used for migrations with KVM. Migration may use any port in this range depending on the number of concurrent migrations occurring.
  • Enabling IP forwarding (net.ipv4.ip_forward = 1) is required for virtual bridge devices. Note that installing libvirt enables this variable so it will be enabled when the virtualization packages are installed unless it was manually disabled.

注記

Note that enabling IP forwarding is not required for physical bridge devices. When a guest is connected through a physical bridge, traffic only operates at a level that does not require IP configuration such as IP forwarding.

第19章 xend を使用したゲストの管理

xend ノード制御デーモンは、仮想マシンに関連した特定のシステム管理機能を果たします。このデーモンが仮想化リソースを制御するため、xend は 仮想マシンと相互交流するように稼動していなければなりません。xend を開始する前に、xend 設定ファイルである、/etc/xen/xend-config.sxp を編集することにより、操作パラメータを 指定する必要があります。xend-config.sxp 設定ファイルで 有効、又は無効にできるパラメータを以下に示します:
表19.1 xend の設定パラメータ
項目 説明
(console-limit)
Determines the console server's memory buffer limit and assigns that limit on a per domain basis.
(min-mem)
domain0 用に予約される最小限のメガバイト数を決定します(0 を入力すると値は変化しません)。
(dom0-cpus)
domain0 で使用する CPU の数量を決定します(デフォルトで、最低1つの CPU が割り当てられます)
(enable-dump)
これが有効になっている場合にクラッシュが発生すると、Xen はダンプファイルを 作成します(デフォルトは 0)。
(external-migration-tool)
外部デバイスの移行を処理するスクリプト、又はアプリケーションを決定します。スクリプトは etc/xen/scripts/external-device-migrate ディレクトリにある必要があります。
(logfile)
ログファイルの場所を決定します (デフォルトでは、/var/log/xend.log)。
(loglevel)
ログモードの値をフィルターにかけます: DEBUG, INFO, WARNING, ERROR, CRITICAL(デフォルトは DEBUG)。
(network-script)
ネットワーク環境を有効にするスクリプトを決定します。スクリプトは etc/xen/scripts ディレクトリに存在する必要があります。
(xend-http-server)
http ストリームパケット管理サーバーを有効にします (デフォルトは 「no」)。
(xend-unix-server)
UNIX ドメインソケットサーバーを有効にします。ソケットサーバーは、低レベルのネットワーク接続を処理し、来信の接続を受理したり拒否したりする通信エンドポイントです。デフォルト値は 「yes」にセットされています。
(xend-relocation-server)
相互マシン移行用に移転サーバーを有効にします (デフォルトは 「no」)。
(xend-unix-path)
xend-unix-server コマンドがデータを出力する場所を決定します (デフォルトでは、var/lib/xend/xend-socket)。
(xend-port)
http 管理サーバーが使用するポートを決定します (デフォルトは 8000)。
(xend-relocation-port)
移転サーバーが使用するポートを決定します (デフォルトは 8002)。
(xend-relocation-address)
移行が許可されるホストアドレスを決定します。デフォルト値は、 xend-address の値です。
(xend-address)
ドメインソケットサーバーのバインド先のアドレスを決定します。デフォルト値は 全ての接続を許可します。

これらの操作パラメータを設定した後には、xend が稼動していることを確認しなければなりません。稼動していない場合、デーモンを開始します。コマンドプロンプトで、次の入力をして xend デーモンを開始することができます:
service xend start
xend を使ってデーモンを停止することができます:
service xend stop
これがデーモンの動作を停止します。
xend を使ってデーモンを再開始することができます:で
service xend restart
デーモンはもう一度開始します。
xend デーモンのステータスをチェックすることができます。
service xend status
The output displays the daemon's status.

ブート時に xend を有効にする

chkconfig コマンドを使用して、xendinitscript に追加します。
chkconfig --level 345 xend
これで、xend は、ランレベル 3、4、及び 5 で開始します。

第20章 Xen ライブ移行

The Xen hypervisor supports Virtualization Migration for para-virtualized guests and fully virtualized guests. Migration is only supported on Red Hat Enterprise Linux 5.1 and newer systems. Migration can be performed offline or live.
  • オフライン移行はオリジナルホスト上の仮想化ゲストを休止して、それを目的地のホストへと 移動し、それからそのゲストが完全に転送された時点でそれを復帰します。オフライン移行は virsh migrate コマンドを使用します。
    # virsh migrate GuestName libvirtURI
  • A live migration keeps the guest running on the source host and begins moving the memory without stopping the guest. All modified memory pages are monitored for changes and sent to the destination while the image is sent. The memory is updated with the changed pages. The process continues until the amount of pause time allowed for the guest equals the predicted time for the final few pages to be transfer. The Xen hypervisor estimates the time remaining and attempts to transfer the maximum amount of page files from the source to the destination until Xen predicts the amount of remaining pages can be transferred during a very brief time while the virtualized guest is paused. The registers are loaded on the new host and the guest is then resumed on the destination host. If the guest cannot be merged (which happens when guests are under extreme loads) the guest is paused and then an offline migration is started instead.
    ライブ移行には virsh migrate コマンドで --live オプションを使用します。
    # virsh migrate--live GuestName libvirtURI

Itanium® サポートの注記

移行は現時点では、Itanium® アーキテクチャ上でのサポートがありません。
Xen を使用した移行を有効にするには、 /etc/xen/xend-config.sxp の 設定ファイルにいくつかの変更が必要になります。 不正確な設定がセキュリティ問題になる可能性があるため、デフォルトでは移行は 無効になっています。移行ポートを開くと権限の無いホストが移行を開始したり、移行ポートに 接続したりできるようになります。移行要求用に認証と権限授与が設定されておらず、唯一の 制御メカニズムはホスト名と IP アドレスを基にしています。移行ポートが無許可のホストに アクセスされないように特別な注意が必要です。

仮想化移行のセキュリティ

IP アドレスとホスト名のフィルタは最低限のセキュリティのみを提供します。これらの 属性は両方共、攻撃者が移行クライアントのアドレスとホスト名を知っていると偽造できます。移行のための最善のセキュリティはネットワークを、外部と権限の無い内部接続から隔離することです。
移行を有効にする
/etc/xen/xend-config.sxp 内で以下のエントリを修正して、 移行を有効にします。必要であれば値を修正して、以下のパラメータの前にあるコメント (# マーク)を削除します。
(xend-relocation-server yes)
移行を無効にするデフォルト値は、no です。xend-relocation-server の値を yes に 変更して移行を有効にします。
(xend-relocation-port 8002)
xend-relocation-serveryes に セットされている場合、このパラメータ、(xend-relocation-port)、は ポート xend が移動インターフェイスの 為に使用されるべきことを指定します。
この変数のデフォルト値は ほとんどのインストールで機能するはずです。この値を 変更する場合は、移動サーバー上で未使用のポートを使用することを確認して下さい。
xend-relocation-port パラメータでセットされたポートは両方の システムで開かれる必要があります。
(xend-relocation-address '')
(xend-relocation-address) は、 xend-relocation-server がセットされている場合に、 relocation-socket 接続の移行コマンドの為に、xend がリッスンするアドレスです。
The default is to listen on all active interfaces. The (xend-relocation-address) parameter restricts the migration server to only listen to a specific interface. The default value in /etc/xen/xend-config.sxp is an empty string(''). This value should be replaced with a single, valid IP address. For example:
(xend-relocation-address '10.0.0.1')
(xend-relocation-hosts-allow '')
The (xend-relocation-hosts-allow 'hosts') parameter controls which hostnames can communicate on the relocation port.
Unless you are using SSH or TLS, the guest's virtual memory is transferred in raw form without encryption of the communication. Modify the xend-relocation-hosts-allow option to restrict access to the migration server.
単独引用句で囲まれた空の文字列で示した上のサンプルのように、その値が空である場合、全ての接続が許可されます。これは、移動サーバーがリッスンするポートとインターフェイスに接続が到着することを想定します。(上述の xend-relocation-portxend-relocation-address も参照して下さい)
それ以外の場合は、(xend-relocation-hosts-allow) パラメータは空白で分離された正規表現の連続でなければなりません。 これらの正規表現の1つに一致する完全修飾ドメイン名、又は IP アドレスを持つ ホストはいずれも受理されます。
(xend-relocation-hosts-allow) 属性の サンプル:
(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$')
使用する設定ファイル内でパラメータを設定した後は、Xen サービスを再スタートします。
# service xend restart

20.1. ライブ移行の例

以下にライブ移行の為の簡単な環境のセットアップの仕方の例を示します。 この設定では、共有ストレージの為に NFS を 使用します。NFS はデモ用の環境には適していますが、 実稼働用の環境には、ファイバーチャンネル又は、iSCSI と GFS を使用したより強健な共有ストレージが推奨されます。
以下の設定は2つのサーバーで構成されています(et-virt07et-virt08)。この両方は eth1 をそのデフォルトネットワークインターフェイスとして 使用しているため、xenbr1 をその Xen ネットワーキング ブリッジとして使用しています。この例では、et-virt07 上でローカルに取り付けた SCSI disk (/dev/sdb) をNFS を 介して共有ストレージ用に使用しています。
ライブ移行のセットアップ
移行に使用されるディレクトリを作成してマウントします:
# mkdir /var/lib/libvirt/images
# mount /dev/sdb /var/lib/libvirt/images

重要

ディレクトリが正しいオプションでエキスポートされることを確認してください。 デフォルトのディレクトリ、/var/lib/libvirt/images/ を エキスポートしている場合は、/var/lib/libvirt/images/ のみを エキスポートすることと、/var/lib/xen/ ではないこと を 確認して下さい。/var/lib/xen/ ディレクトリは xend デーモンと他のツールにより使用されるものであり、このディレクトリを共有すると、 予知できない動作を起こす可能性があります。
# cat /etc/exports
/var/lib/libvirt/images  *(rw,async,no_root_squash)
NFS を介してエキスポートされていることを確認します:
# showmount -e et-virt07
Export list for et-virt07:
/var/lib/libvirt/images *
ゲストをインストール
ゲストのインストールの為に使用されるサンプルのインストールコマンド:
# virt-install -p -f /var/lib/libvirt/images/testvm1.dsk -s 5 -n\
testvm1 --vnc -r 1024 -l http://example.com/RHEL5-tree\
Server/x86-64/os/ -b xenbr1
For step by step installation instructions, refer to 8章ゲストオペレーティングシステムのインストール手順.
移行用の環境を確認
仮想化ネットワークブリッジが正しく設定されており、両方のホスト上で同じ名前を 持つことを確認します:
[et-virt08 ~]# brctl show
bridge name     bridge id               STP enabled     interfaces
xenbr1          8000.feffffffffff       no              peth1
vif0.1
[et-virt07 ~]# brctl show
bridge name     bridge id               STP enabled     interfaces
xenbr1          8000.feffffffffff       no              peth1
vif0.1
移動パラメータが両方のホスト上で設定されていることを確認します:
[et-virt07 ~]# grep xend-relocation /etc/xen/xend-config.sxp |grep -v '#'
(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-address '')
(xend-relocation-hosts-allow '')
[et-virt08 ~]# grep xend-relocation /etc/xen/xend-config.sxp |grep -v '#'
(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-address '')
(xend-relocation-hosts-allow '')
移動サーバーがスタートしたことと、Xen 移行 (8002) 用の専用ポートでリッスンしている ことを確認します:
[et-virt07 ~]# lsof -i :8002
COMMAND  PID  USER   FD   TYPE  DEVICE SIZE NODE NAME
python 3445 root 14u IPv4 10223 TCP *:teradataordbms (LISTEN)
[et-virt08 ~]# lsof -i :8002
COMMAND  PID USER   FD   TYPE DEVICE SIZE NODE NAME
python 3252 root 14u IPv4 10901 TCP *:teradataordbms (LISTEN)
That the default /var/lib/libvirt/images directory is available and mounted with networked storage on both hosts. Shared, networked storage is required for migrations.
[et-virt08 ~]# df /var/lib/libvirt/images
Filesystem           1K-blocks      Used Available Use% Mounted on
et-virt07:/var/lib/libvirt/images    70562400   2379712  64598336   4% /var/lib/libvirt/images
[et-virt08 ~]# file /var/lib/libvirt/images/testvm1.dsk 
/var/lib/libvirt/images/testvm1.dsk: x86 boot sector; partition 1: ID=0x83,
active, starthead 1, startsector 63, 208782 sectors; partition 2: ID=0x8e, 
starthead 0, startsector 208845, 10265535 sectors, code offset 0x48
[et-virt08 ~]# touch /var/lib/libvirt/images/foo
[et-virt08 ~]# rm -f /var/lib/libvirt/images/foo
ゲストの保存と復元を確認します
仮想マシンをスタートします(まだ仮想マシンがオンでない場合):
[et-virt07 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
[et-virt07 ~]# virsh start testvm1
Domain testvm1 started
仮想マシンが稼働していることを確認します:
[et-virt07 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
ローカルホスト上の仮想マシンを保存します:
[et-virt07 images]# time virsh save testvm1 testvm1.sav
real    0m15.744s
user    0m0.188s
sys     0m0.044s
[et-virt07 images]# ls -lrt testvm1.sav
-rwxr-xr-x 1 root root 1075657716 Jan 12 06:46 testvm1.sav
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
ローカルホスト上で仮想マシンを復元します:
[et-virt07 images]# virsh restore testvm1.sav
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Start the live migration of domain-id from et-virt08 to et-virt07. The hostname you are migrating to and <domain-id> must be replaced with valid values. This example uses the et-virt08 host which must have SSH access to et-virt07
[et-virt08 ~]# xm migrate --live testvm1 et-virt07
Verify the virtual machine is no longer present on et-virt08
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
Verify the virtual machine has been migrated to et-virt07:
[et-virt07 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        running
進行具合をテストしてライブ移行を始動
Create the following script inside the virtual machine to log date and hostname during the migration. This script performs I/O tasks on the guest's file system.
#!/bin/bash

while true
do
touch /var/tmp/$$.log
echo `hostname` >>  /var/tmp/$$.log
	echo `date`     >>  /var/tmp/$$.log
	cat  /var/tmp/$$.log
	df /var/tmp
	ls -l  /var/tmp/$$.log
	sleep 3
	done
スクリプトは単にテスト目的だけのためであり、実稼働環境でのライブ移行には 不要であることを忘れないで下さい。
仮想マシンを et-virt07 に移行する前に、 それが et-virt08 上で稼働していることを確認します:
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
et-virt07 へのライブ移行を始動します。 time コマンドを追加すると、移行にかかる時間を見ることができます:
[et-virt08 ~]# xm migrate --live testvm1 et-virt07
ゲスト内でスクリプトを実行します:
# ./doit
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:27 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 62 Jan 12 02:26 /var/tmp/2279.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:27 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:30 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 124 Jan 12 02:26 /var/tmp/2279.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:27 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:30 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:33 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 186 Jan 12 02:26 /var/tmp/2279.log
Fri Jan 12 02:26:45 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:48 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:51 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:54:57 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:55:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:55:03 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 744 Jan 12 06:55 /var/tmp/2279.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:27 EST 2007
仮想マシンが et-virt08 上でシャットダウンされたことを確認します:
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
仮想マシンが et-virt07 上でスタートしたことを確認します:
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
et-virt07 から et-virt08 へと もう 1度移行サイクルを実行します。et-virt07 から et-virt08 への移行を以下のようにして開始します:
[et-virt07 images]# xm migrate --live testvm1 et-virt08
仮想マシンがシャットダウンされたことを確認します:
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
移行を初めて執行する前に、ゲスト内で簡単なスクリプトを開始して、ゲストが 移行するときの時間の変化に注意します:
# ./doit
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 62 Jan 12 06:57 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 124 Jan 12 06:57 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:58:00 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 186 Jan 12 06:57 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:58:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:00 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 248 Jan 12 02:30 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:58:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:03 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 310 Jan 12 02:30 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:58:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:03 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:06 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 372 Jan 12 02:30 /var/tmp/2418.log
移行コマンドが et-virt07 上で完了すると、 et-virt08 上で仮想マシンがスタートしたことを 確認します:
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
そしてもう1つのサイクルを実行します:
[et-virt08 ~]# time virsh migrate --live testvm1 et-virt07
real    0m10.378s
user    0m0.068s
sys     0m0.052s
これで、オフラインとライブの移行テストを正常に実行できました。

20.2. ゲストライブ移行の設定

このセクションは、Red Hat Enterprise Linux を稼働している 他のサーバーへの Xen ゲストのオフライン移行を説明しています。 移行はオフラインメソッド内で 実行されます(xm migrate コマンドを使用)。ライブ移行は 同じコマンドで実行できますが、その場合、xend-config 設定ファイルにいくらかの追加修正が必要になります。この例では、正しい移行を達成する為に 修正すべきエントリを識別しています:
(xend-relocation-server yes)
The default for this parameter is 'no', which keeps the relocation/migration server deactivated (unless on a trusted network) and the domain virtual memory is exchanged in raw form without encryption.
(xend-relocation-port 8002)
このパラメータは、xend が移行用に使用するポートを設定します。使用するネットワーク環境がカスタム値を要求しない限りは、この値を使用します。コメント用の シンボルを削除して有効にします。
(xend-relocation-address )
このパラメータは、ユーザーが xend-relocation-server を有効にした後に、移動ソケット接続の為にリッスンするアドレスです。Xen hypervisor は 指定されたインターフェイス上の移行ネットワークトラフィックだけをリッスンします。
(xend-relocation-hosts-allow )
このパラメータは移動ポートと通信するホストを制御します。その値が空であれば、全ての来信接続は許可されます。これを空白で区切られた正規表現の連続に変える必要があります。例えば:
(xend-relocation-hosts-allow- '^localhost\\.localdomain$' )>
受理される値には、完全修飾ドメイン名、IP アドレス、あるいは空白で隔離した 正規表現が含まれます。
設定した後に、ホストを再起動して新しいセッティングをロードします。

第21章 KVM ライブ移行

この章では、KVM hypervisor で稼働しているゲストを別の KVM ホストに移行する方法を説明しています。
Migration is the process of moving a virtualized guest from one host to another. Migration is a key feature of virtualization as software is completely separated from hardware. Migration is useful for:
  • ロードバランシング: あるホストが過大な負荷を持つとき、ゲストは使用度の低いホストへと 移動できます。
  • ハードウェアフェイルオーバー:ホスト上のハードウェアデバイスが障害を持つと、 ゲストが安全な場所に移動して、その間にホストは電源を落として修理ができます。
  • エネルギー節約:ゲストが他のホストに再分配されると、ホストシステムは 電源を落とすことによりエネルギーを節約し、使用度が低い時にはコストを 低減します。
  • 地域的な移行:ゲストは、低遅延度を求めて、又は重大な状況下で 他の地域に移動することができます。
Migrations can be performed live or offline. To migrate guests the storage must be shared. Migration works by sending the guests memory to the destination host. The shared storage stores the guest's default file system. The file system image is not sent over the network from the source host to the destination host.
オフライン移行はゲストを休止して、それからそのゲストのメモリーイメージを目的地の ホストに移動します。ゲストは目的地のホストで復帰して、送信元ホスト上でゲストが使用した メモリーは開放されます。
オフライン移行が必要とする時間はネットワークのバンド幅と遅延度によります。 2GB のメモリーを持つゲストでは 1 Gbit イーサネットリンクで平均的に10秒位の 時間がかかります。
ライブ移行は送信元のホスト上でゲストを稼働し続け、ゲストを停止することなく、 そのメモリーの移動を始めます。全ての修正されたメモリーページはその変更部を監視され、 そのイメージが送信されている間に目的地へ送信されます。メモリーは変更のあった ページで更新されます。このプロセスはゲスト用に許容された休止時間数が、転送される 最後の数ページ用の予想時間と同等になるまで継続します。KVM はその残りの時間を推測し、 仮想化ゲストの短い休止時間内に残りのページが転送できると予測できるまで 送信元から送信先まで最大量のページを転送する試みを続けます。レジスタが新規の ホストにロードされて、ゲストはそれから送信先のホストで復帰します。ゲストが マージできない場合(ゲストが極端な負荷を持つ時に発生)、ゲストは休止して、 それから代わりに オフライン移行が始まります。
オフライン移行にかかる時間は、ネットワークのバンド幅とその遅延度によります。ネットワークが多大な負荷を持つ場合、又はバンド幅が低い場合は、移行には長い 時間がかかります。

21.1. ライブ移行の要件

ゲストの移行には以下が必要です:
移行の要件
  • 以下のプロトコルの1つを使用して共有ネットワークストレージにインストール された仮想化ゲスト:
    • ファイバーチャンネル
    • iSCSI
    • NFS
    • GFS2
  • 同じ更新を持つ同じバージョンの 2つ又はそれ以上の Red Hat Enterprise Linux システム
  • 両方のシステムは適切なポートを開いている必要があります。
  • 両方のシステムは同一のネットワーク設定を持つ必要があります。全ての ブリッジとネットワーク設定は両方のホスト上で全く同じでなければなりません。
  • 共有ストレージは送信元と送信先のシステム上で同じ場所でマウントしなければ なりません。そしてマウントされたディレクトリ名も同一である必要があります。
ネットワークストレージの継続
Configure shared storage and install a guest on the shared storage. For shared storage instructions, refer to パートV「Virtualization Storage Topics」.

21.2. 共有ストレージサンプル: 簡単な移行のための NFS

この例では、NFS を使用して他の KVM ホストと共にゲストイメージを共有しています。 この例は、大規模のインストールには実用的ではありません。これ例は、単に移行の 技術を示すためのものであり、小規模の導入用です。この例を数個の仮想化 ゲスト以上の環境で移行、又は実行に使用しないで下さい。
For advanced and more robust shared storage instructions, refer to パートV「Virtualization Storage Topics」
  1. libvirt イメージディレクトリをエキスポート

    デフォルトのイメージディレクトリを /etc/exports ファイルに 追加します:
    /var/lib/libvirt/images *.example.com(rw,no_root_squash,async)
    
    ご自分の環境に適するようにホストパラメータを変更します。
  2. NFS の開始

    1. NFS パッケージがインストールされていない場合は、インストールします:
      # yum install nfs
      
    2. iptables で NFS 用のポートを開きます。そして NFS を /etc/hosts.allow ファイルに追加します。
    3. NFS サービスを開始:
      # service nfs start
      
  3. 共有ストレージを目的地でマウントします

    目的地のシステムで、/var/lib/libvirt/images ディレクトリをマウントします:
    # mount sourceURL:/var/lib/libvirt/images /var/lib/libvirt/images
    

    場所は送信元と送信先で同じにならなければなりません。

    ゲスト用にどのディレクトリが選択されても、それはホストとゲスト上で全く 同じでなければなりません。これは、全てのタイプの共有ストレージに該当 します。ディレクトリが同じでないと、移行は失敗します。

21.3. virsh を使用した ライブ KVM 移行

virsh コマンドを使用してゲストを別のホストに移行することが できます。migrate コマンドは 以下の形式のパラメータを 受け付けます:
# virsh migrate --live GuestName DestinationURL
GuestName パラメータは、移行したいゲストの 名前を表すものです。
DestinationURL パラメータは目的地システムの URL かホスト名です。目的地システムは Red Hat Enterprise Linux の同じバージョンを 実行しなければならず、同じ hypervisor を使用して、libvirt が 稼働している必要があります。
コマンドが入力されると、目的地システムの root パスワードを催促されます。
例: virsh を使用したライブ移行
この例では、test1.example.com から test2.example.com へ移行をします。ご自分の 環境に適したホスト名に変更して下さい。この例は RHEL4test と言う 仮想マシンを移行します。
This example assumes you have fully configured shared storage and meet all the prerequisites (listed here: 移行の要件).
  1. ゲストが稼働していることを確認します

    送信元のシステム test1.example.com から RHEL4test が稼働していることを確認します:
    [root@test1 ~]# virsh list
    Id Name                 State
    ----------------------------------
     10 RHEL4                running
    
  2. ゲストを移行

    以下のコマンドを実行して、ゲストを目的地、test2.example.com に ライブ移行します。/system を目的地の URL の末尾に追記することで全面的アクセスが 必要であることを libvirt に伝えます。
    # virsh migrate --live RHEL4test qemu+ssh://test2.example.com/system
    コマンドが入力されると、目的地システムの root パスワードを催促されます。
  3. 待ち時間

    この移行はゲスト上の負荷とそのサイズによりいくらかの時間がかかります。virsh は エラーを報告するだけです。このゲストは完全に移行が終了するまで送信元のホストで稼働し続けます。
  4. ゲストが目的地のホストに到着したことを確認

    目的地のシステム、test2.example.com から、 RHEL4test が稼働していることを確認します:
    [root@test2 ~]# virsh list
    Id Name                 State
    ----------------------------------
     10 RHEL4                running
    
ライブ移行はこれで完了しました。

その他のネットワーキングメソッド

libvirt supports a variety of networking methods including TLS/SSL, unix sockets, SSH, and unencrypted TCP. Refer to 22章仮想化ゲストのリモート管理 for more information on using other methods.

21.4. virt-manager での移行

このセクションでは、virt-manager を使用した KVM ベース ゲストの移行を取り扱います。
  1. 送信元を送信先のホストを接続します。ファイル メニューで、 接続を追加 をクリックすると、接続を 追加 のウィンドウが出現します。
    以下の詳細を入力します:
    • Hypervisor: QEMU を選択。
    • 接続: 接続タイプを選択します。
    • ホスト名: ホスト名を入力します。
    接続 をクリックします。
    仮想マシンマネージャのウィンドウが接続してあるホストの一覧を表示します。
  2. ソースとターゲットのホストに同じ NFS を使用するストレージプールを追加します。
    編集 メニューで、ホストの詳細 をクリックすると、「ホストの詳細」ウィンドウが表示されます。
    ストレージ タブをクリックします。
  3. 新規のストレージプールを追加します。そのウィンドウの左下コーナーで + ボタンをクリックします。「新規ストレージプールの追加」ウィンドウが表示されます。
    以下の詳細を入力します:
    • 名前: ストレージプールの名前を入力します。
    • タイプ: netfs: Network Exported ディレクトリ を選択します。
    進む をクリックします。
  4. 以下の詳細を入力します:
    • 形式: ストレージタイプを選択します。これはライブ移行用には NFS か、又は iSCSI のいずれかです。
    • ホスト名: ストレージサーバーの IP アドレスか、又は 完全修飾型ドメイン名を入力します。
    完了 をクリックします。
  5. 共有ストレージプール内で新規のボリュームを作成して、新規ボリューム をクリックします。
  6. 詳細を入力して、それから ボリュームの作成 をクリックします。
  7. 新規のボリュームで仮想マシンを作成します。その後仮想マシンを実行します。
    仮想マシンのウィンドウが開きます。
  8. 仮想マシンマネージャのウィンドウで、仮想マシン上で右クリックします。 移行 を選択してから、移行の場所をクリックします。
  9. はい をクリックして移行を継続します。
    The Virtual Machine Manager displays the virtual machine in its new location.
    The VNC connection displays the remote host's address in its title bar.

第22章 仮想化ゲストのリモート管理

このセクションでは、ssh か、TLS か、あるいは SSL を 使用して仮想化ゲストをリモートで管理する方法を説明しています。

22.1. SSH を使用したリモート管理

ssh パッケージは、リモート仮想化サーバーに対して安全に 管理機能を送信できる暗号化したネットワークプロトコルを提供します。ここに説明してある 方法は SSH 接続経由で安全にトンネル通過する libvirt 管理接続を使用して、リモートマシンを管理します。全ての認証は 使用中の SSH エージェントに よって収集された SSH パブリックキー暗号とパスワード、又はパスフレーズを 使用して行われます。更には、各ゲスト仮想マシンの VNC コンソールは SSH 経由でトンネル通過します。
SSH は通常、デフォルトで設定されており、 ユーザーには多分、既に SSH キーがセットされている可能性があり、管理サービスや VNC コンソールにアクセスするための余分のファイアウォール ルールは必要ないでしょう。
リモートで仮想マシンを管理するための SSH の 使用に於いて、以下を含む各種問題に注意して下さい:
  • 仮想マシンの管理には、リモートマシンへの root ログインでアクセスする必要があります。
  • 初期の接続セットアップは時間がかかるかも知れません。
  • there is no standard or trivial way to revoke a user's key on all hosts or guests, and
  • ssh は多数のリモートマシン群に対してはうまく機能しません。
Configuring password less or password managed SSH access for virt-manager
The following instructions assume you are starting from scratch and do not already have SSH keys set up. If you have SSH keys set up and copied to the other systems you can skip this procedure.

The user is important for remote management

SSH keys are user dependent. Only the user who owns the key may access that key.
virt-manager must run as the user who owns the keys to connect to the remote host. That means, if the remote systems are managed by a non-root user virt-manager must be run in unprivileged mode. If the remote systems are managed by the local root user then the SSH keys must be own and created by root.
You cannot manage the local host as an unprivileged user with virt-manager.
  1. Optional: Changing user

    Change user, if required. This example uses the local root user for remotely managing the other hosts and the local host.
    $ su -
  2. Generating the SSH key pair

    Generate a public key pair on the machine virt-manager is used. This example uses the default key location, in the ~/.ssh/ directory.
    $ ssh-keygen -t rsa
    
  3. Coping the keys to the remote hosts

    Remote login without a password, or with a passphrase, requires an SSH key to be distributed to the systems being managed. Use the ssh-copy-id command to copy the key to root user at the system address provided (in the example, root@example.com).
    # ssh-copy-id -i ~/.ssh/id_rsa.pub root@example.com root@example.com's password: Now try logging into the machine, with "ssh 'root@example.com'", and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting 
    
    Repeat for other systems, as required.
  4. Optional: Add the passphrase to the ssh-agent

    Add the passphrase for the SSH key to the ssh-agent, if required. On the local host, use the following command to add the passphrase (if there was one) to enable password-less login.
    # ssh-add ~/.ssh/id_rsa.pub
The SSH key was added to the remote system.
libvirt デーモン (libvirtd)
The libvirt daemon provide an interface for managing virtual machines. You must have the libvirtd daemon installed and running on every remote host that needs managing.
$ ssh root@somehost
# chkconfig libvirtd on
# service libvirtd start
libvirtdSSH の設定が終了した後は、リモートで仮想マシンへ アクセスして管理できるはずです。また、この時点で VNC を 使用してゲストへもアクセスできるはずです。
Accessing remote hosts with virt-manager
Remote hosts can be managed with the virt-manager GUI tool. SSH keys must belong to the user executing virt-manager for password-less login to work.
  1. Start virt-manager.
  2. Open the File->Add Connection menu.
  3. Input values for the hypervisor type, the connection, Connection->Remote tunnel over SSH, and enter the desired hostname, then click connection.

22.2. TLS と SSL を使用したリモート管理

You can manage virtual machines using TLS and SSL. TLS and SSL provides greater scalability but is more complicated than ssh (refer to 「SSH を使用したリモート管理」). TLS and SSL is the same technology used by web browsers for secure connections. The libvirt management connection opens a TCP port for incoming connections, which is securely encrypted and authenticated based on x509 certificates. In addition the VNC console for each guest virtual machine will be setup to use TLS with x509 certificate authentication.
This method does not require shell accounts on the remote machines being managed. However, extra firewall rules are needed to access the management service or VNC console. Certificate revocation lists can revoke users' access.
virt-manager 用に TLS/SSL アクセスをセットアップする手順
以下の短いガイドはユーザーが初めての試みをしていること、及び TLS/SSL 証明書の 知識を持っていないことを想定しています。ユーザーが幸運にも証明書管理サーバーを 所有している場合は、最初のステップは多分飛ばすことができるでしょう。
libvirt サーバーセットアップ
証明書の作成についての詳細には、libvirt website, http://libvirt.org/remote.html を参照して下さい。
Xen VNC サーバー
Xen VNC サーバーは設定ファイル /etc/xen/xend-config.sxp を 編集することにより TLS を有効にすることができます。設定ファイル内の (vnc-tls 1) 設定パラメータのコメント化を外します。
The /etc/xen/vnc directory needs the following 3 files:
  • ca-cert.pem - The CA certificate
  • server-cert.pem - The Server certificate signed by the CA
  • server-key.pem - The server private key
This provides encryption of the data channel. It might be appropriate to require that clients present their own x509 certificate as a form of authentication. To enable this remove the commenting on the (vnc-x509-verify 1) parameter.
virt-managervirsh のクライアントセットアップ
クライアントのセットアップは少しここでは不均等です。TLS を介して libvirt 管理 API を有効にするには、CA と クライアントの証明書が /etc/pki 内に 配置されなければなりません。この詳細に関しては http://libvirt.org/remote.html をご覧下さい。
In the virt-manager user interface, use the 'SSL/TLS' transport mechanism option when connecting to a host.
virsh 用に URI は以下のような形式を持ちます:
  • KVM 対応の qemu://hostname.guestname/system
  • Xen 対応の xen://hostname.guestname/ .
VNC 用に SSL と TLS を有効にするには、証明書権限とクライアント証明書を、 $HOME/.pki に入れる必要があります。それは以下の 3つのファイルです:
  • CA 又は、ca-cert.pem - CA 証明書
  • libvirt-vnc 又は clientcert.pem - CA によって署名されたクライアント証明書。
  • libvirt-vnc 又は clientkey.pem - クライアントのプライベートキーです。

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

リモートの管理には libvirt が以下のようなトランスポートモードをサポートします:
Transport Layer Security (TLS)
Transport Layer Security TLS 1.0 (SSL 3.1) で認証されて暗号化された TCP/IP ソケットは 通常、パブリックポート番号の内の1つでリッスンしています。これを使用するには、クライアントと サーバーの証明書を生成する必要があります。標準のポートは 16514 です。
UNIX ソケット
Unix ドメインソケットはローカルマシーン上でのみアクセス可能です。ソケットは暗号化 されておらず、認証のために UNIX 権限又は、SELinux を使用します。標準のソケット名は /var/run/libvirt/libvirt-sock/var/run/libvirt/libvirt-sock-ro (読み込み専用接続)です。
SSH
Secure Shell protocol (SSH) 接続経由でのトランスポートです。Netcat (nc パッケージ)のインストールを必要とします。 libvirt デーモン (libvirtd) がリモートマシン上で 実行している必要があります。Port 22 が SSH アクセス用に開いていなければ なりません。なんらかの ssh キー管理(例えば、ssh-agent ユーティリティ)を 使用する必要があり、そうでないとパスワードを要求されます。
ext
ext パラメータはいずれかの外部プログラム用に使用 されるものです。これは libvirt の範疇にはない手法でリモートマシンに接続をします。 このパラメータはサポートされていません。
tcp
暗号化のない TCP/IP ソケットです。実稼働使用には推奨できません。これは 通常無効になっていますが、管理者はテスト目的や、信頼できるネットワーク上で 有効にすることができます。デフォルトのポートは 16509 です。
他に指定がない場合は、デフォルトのトランスポートは tls です。
リモート URI
Uniform Resource Identifier (URI) はリモートホストに接続するために virshlibvirt により使用されます。\n URI はまた、virsh コマンド用に --connect パラメータと 一緒にリモートホスト上で単独コマンドや移行を実行するのに使用されます。
libvirt URI は一般的な形式を取ります(角括弧 "[ ]" の中身はオプションの関数を示します):
driver[+transport]://[username@][hostname][:port]/[path][?extraparameters]
外部の場所を目標とする為にトランスポートモード、又はホスト名が 供給される必要があります。
リモート管理パラメータのサンプル
  • SSH トランスポート及び SSH ユーザー名 ccurran を使用して towada と言うホスト上のリモート Xen hypervisor に接続します。
    xen+ssh://ccurran@towada/
    
  • TLS を使用して towada と言う名前のホスト上のリモート Xen hypervisor に接続します。
    xen://towada/
    
  • Connect to a remote Xen hypervisor on host towada using TLS. The no_verify=1 tells libvirt not to verify the server's certificate.
    xen://towada/?no_verify=1
    
  • SSH を使用して、ホスト towada 上のリモート KVM hypervisor に 接続します。
    qemu+ssh://towada/system
    
テスト用サンプル
  • 標準でない UNIX ソケットを使用してローカルの KVM hypervisor に接続します。 この場合 Unix ソケットへの完全なパスは 明示的に供給されます。
    qemu+unix:///system?socket=/opt/libvirt/run/libvirt/libvirt-sock
    
  • ポート 5000 で IP アドレス 10.1.1.10 を持つ サーバーへの 暗号化のない TCP/IP 接続を 使用して libvirt デーモンへ接続します。これは、デフォルト設定を持つテストドライバーを 使用します。
    test+tcp://10.1.1.10:5000/default
    
その他の URI パラメータ
Extra parameters can be appended to remote URIs. The table below 表22.1「その他の URI パラメータ」 covers the recognized parameters. All other parameters are ignored. Note that parameter values must be URI-escaped (that is, a question mark (?) is appended before the parameter and special characters are converted into the URI format).
表22.1 その他の URI パラメータ
名前 トランスポートモード 説明 使用法のサンプル
name 全てのモード リモート virConnectOpen 関数に渡される名前です。この名前は通常、リモート URI からトランスポート、ホスト名、 ポート番号、ユーザー名、及び余分のパラメータを削除したものですが、一部の複雑なケースでは、名前を明示的に 供給するのが適切な場合もあります。 name=qemu:///system
command ssh と ext 外部コマンドです。外部のトランスポートにはこれが必須となります。ssh 用には デフォルトは ssh です。コマンドの為に PATH が検索されます。 command=/opt/openssh/bin/ssh
socket unix と ssh UNIX ドメインソケットへのパスです。これはデフォルトを上書きします。 ssh トランスポートには、これがリモート netcat コマンドに渡されます(netcat 参照)。 socket=/opt/libvirt/run/libvirt/libvirt-sock
netcat ssh
netcat コマンドはリモートシステムに接続するのに 使用できます。デフォルトの netcat パラメータは nc コマンドを 使用します。SSH トランスポート用には、libvirt が以下の形式を使用して SSH コマンドを 構築します:
								command -p port [-l username] hostname
								netcat -U socket
portusername、及び hostname パラメータはリモート URI の一部として 指定できます。commandnetcat、及び socket は他の追加のパラメータ 由来のものです。
netcat=/opt/netcat/bin/nc
no_verify tls If set to a non-zero value, this disables client checks of the server's certificate. Note that to disable server checks of the client's certificate or IP address you must change the libvirtd configuration. no_verify=1
no_tty ssh ゼロ以外の値にセットしてある場合、(ssh-agent 又は同類の使用で)自動的にリモートマシンに ログインできない場合に、ssh がパスワードを要求することを止めます。例えば、 libvirt を使用するグラフィカルプログラム内のターミナルにアクセスを持たない時に これを使用します。 no_tty=1

パート V. Virtualization Storage Topics

Introduction to storage administration for virtualization

This part covers using shared, networked storage with virtualization on Red Hat Enterprise Linux.
The following methods are supported for virtualization:
  • Fibre Channel
  • iSCSI
  • NFS
  • GFS2
Networked storage is essential for live and offline guest migrations. You cannot migrate guests without shared storage.

第23章 Using shared storage with virtual disk images

This chapter covers the use of shared and network storage devices for virtual disks.

23.1. Using iSCSI for storing virtual disk images

This section demonstrates how to set up an iSCSI target on Red Hat Enterprise Linux and how to configure iSCSI on a libvirt KVM host using virsh, and finally how to provision a guest on iSCSI using virt-install.

重要

Setting up a Red Hat Enterprise Linux server as an iSCSI target is not recommended. The example used in this section should not be used in production, and is provided as an example which should only be referred to for basic shared storage testing and educational purposes.

23.1.1. How to set up an iSCSI target on Red Hat Enterprise Linux

  1. Install and enable the iSCSI target service

    Install and enable the iSCSI target service with the following commands:
    # yum install scsi-target-utils
    # chkconfig tgtd on
    # service tgtd start
    

    重要

    The scsi-target-utils package required for this example is provided only in the Cluster Storage add-on for Red Hat Enterprise Linux 5, and may not be available for your system. Contact your support agent to activate this add-on if you are currently unable to install this package.
  2. Allocate storage for the LUNs

    The iSCSI target service is not dependent on a particular type of exported LUN. The LUNs can be plain files, LVM volumes, or block devices. There is however a performance overhead if using the LVM and/or file system layers as compared to block devices. The guest providing the iSCSI service in this example has no spare block or LVM devices, so raw files will be used.
    This example demonstrates the creation of two LUNs; one is a 10GB thin-provisioned (sparse file) LUN, and the other has 500MB, of which are fully-allocated. The following commands will achieve this configuration. Be aware that your environment will be different and this is provided only as an example:
    # mkdir -p /var/lib/tgtd/kvmguest
    # dd if=/dev/zero of=/var/lib/tgtd/kvmguest/rhelx86_64.img bs=1M seek=10240 count=0
    # dd if=/dev/zero of=/var/lib/tgtd/kvmguest/shareddata.img bs=1M count=512
    # restorecon -R /var/lib/tgtd
    
  3. Export the iSCSI target and LUNs

    For Red Hat Enterprise Linux 5, a series of tgtadm commands is required to create a target and associate the storage volumes created earlier. First, the following command adds a target using an iSCSI Qualified Name (IQN):
    # tgtadm --lld iscsi --op new --mode target --tid 1 --targetname \ 
    iqn.2004-04.rhel:rhel5:iscsi.kvmguest
    
    Now the storage volumes must be associated with LUNs in the iSCSI target with these two commands:
    # tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 \
    --backing-store /var/lib/tgtd/kvmguest/rhelx86_64.img
    
    # tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 2 \
    --backing-store /var/lib/tgtd/kvmguest/shareddata.img
    

    重要

    Add the previous 3 tgtadm commands to the end of the /etc/rc.local file to ensure normal operation upon restarting of the system.
    To confirm the successful operation of the previous commands, query the iSCSI target setup:
    tgtadm --lld iscsi --op show --mode target
    Target 1: iqn.2004-04.rhel:rhel5:iscsi.kvmguest
        System information:
            Driver: iscsi
            State: ready
        I_T nexus information:
        LUN information:
            LUN: 0
                Type: controller
                SCSI ID: IET     00010000
                SCSI SN: beaf10
                Size: 0 MB, Block size: 1
                Online: Yes
                Removable media: No
                Readonly: No
                Backing store type: null
                Backing store path: None
                Backing store flags: 
            LUN: 1
                Type: disk
                SCSI ID: IET     00010001
                SCSI SN: beaf11
                Size: 10737 MB, Block size: 512
                Online: Yes
                Removable media: No
                Readonly: No
                Backing store type: rdwr
                Backing store path: /var/lib/tgtd/kvmguest/rhelx86_64.img
                Backing store flags: 
            LUN: 2
                Type: disk
                SCSI ID: IET     00010002
                SCSI SN: beaf12
                Size: 537 MB, Block size: 512
                Online: Yes
                Removable media: No
                Readonly: No
                Backing store type: rdwr
                Backing store path: /var/lib/tgtd/kvmguest/shareddata.img
                Backing store flags: 
        Account information:
        ACL information:
    
  4. Allow client access to the target

    Finally, this example command allows access to all clients without any authentication:
    # tgtadm --lld iscsi --op bind --mode target --tid 1 --initiator-address ALL
    

Two common mistakes

The two most common problems encountered when configuring the iSCSI target are SELinux and iptables. If adding plain files as LUNs in an iSCSI target, ensure the files are labelled system_u:object_r:tgtd_var_lib_t:s0. TCP port 3260 must also be open in your iptables configuration.

23.1.2. How to configure iSCSI on a libvirt KVM host and provision a guest using virt-install

The previous section described how to set up an iSCSI target. This section demonstrates how to configure iSCSI on a libvirt KVM instance using virsh, and then how to provision a guest using virt-install.
  1. Defining the storage pool

    All libvirt storage is managed through storage pools, of which there are many possible types: SCSI, NFS, ext4, plain directory and iSCSI. All libvirt objects are configured via XML description files, and storage pools are no different in this regard. For an iSCSI storage pool there are three important pieces of information to provide:
    • The target path - this determines how libvirt will expose device paths for the pool. Paths like /dev/sda and /dev/sdb are not an ideal choice as they can change between reboots, and can change across machines within a cluster; in other words, the names are assigned on a first come, first served basis by the kernel. It is strongly recommended to use the /dev/disk/by-path format. This results in a consistent naming scheme across all machines.
    • The host name - this is simply the fully-qualified DNS name of the iSCSI server.
    • The source path - this is the iSCSI qualified name (IQN) seen in the previous setup procedure (iqn.2004-04.rhel:rhel5:iscsi.kvmguest).
    Although your environment will likely be different, the following text is what an iSCSI configuration will look like:
    <pool type='iscsi'>
        <name>kvmguest</name>
        <source>
            <host name='myiscsi.example.com'/>
            <device path='iqn.2004-04.rhel:rhel5:iscsi.kvmguest'/>
        </source>
        <target>
            <path>/dev/disk/by-path</path>
        </target>
    </pool>
    
    Save this XML code to a file named iscsirhel5.xml and load it into libvirt using the pool-define command:
    # virsh pool-define iscsirhel5.xml
    Pool kvmguest defined from iscsirhel5.xml
    
    # virsh pool-list --all
    Name                 State      Autostart
    -----------------------------------------
    default              active     yes
    kvmguest             inactive   no
    
  2. Starting the storage pool

    The configuration is saved, but the iSCSI target has not yet been logged into, so no LUNs will be visible on the host at this point. Use the pool-start command the make the LUNs visible with the vol-list command.
    # virsh pool-start kvmguest
    Pool kvmguest started
    
    # virsh vol-list kvmguest
    Name                 Path
    -----------------------------------------
    10.0.0.1             /dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1
    10.0.0.2             /dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-2
    
  3. Querying LUN information

    Further information about each LUN can be obtained using the vol-info and vol-dumpxml commands:
    # virsh vol-info /dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1
    
    Name:           10.0.0.1
    Type:           block
    Capacity:       10.00 GB
    Allocation:     10.00 GB
    
    
    # virsh vol-dumpxml /dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1
    <volume>
      <name>10.0.0.1</name>
      <key>/dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1</key>
      <source>
      </source>
      <capacity>10737418240</capacity>
      <allocation>10737418240</allocation>
      <target>
        <path>/dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-2</path>
        <format type='unknown'/>
        <permissions>
          <mode>0660</mode>
          <owner>0</owner>
          <group>6</group>
          <label>system_u:object_r:fixed_disk_device_t:s0</label>
        </permissions>
      </target>
    </volume>
    
  4. Activating the storage at boot time

    If everything is configured properly, the pool can be set to start automatically upon booting of the host:
    # virsh pool-autostart kvmguest
    Pool kvmguest marked as autostarted
    
  5. Provisioning a guest on iSCSI

    The virt-install command can be used to install new guests from the command line. The --disk argument can take the name of a storage pool, followed by the name of any contained volumes. Continuing this example, the following command will begin the installation of a guest with two disks; the first disk is the root file system, the second disk can be shared between multiple guests for common data:
    # virt-install --accelerate --name rhelx86_64 --ram 800 --vnc --disk \ vol=kvmguest/10.0.0.1 --disk vol=kvmguest/10.0.0.2,perms=sh --pxe
    
    Once this rhelx86_64 guest is installed, the following command and output shows the XML that virt-install used to associate the guest with the iSCSI LUNs:
    # virsh dumpxml rhelx86_64
    
    <domain type='kvm' id='4'>
      <name>rhelx86_64</name>
      <uuid>ad8961e9-156f-746f-5a4e-f220bfafd08d</uuid>
      <memory>819200</memory>
      <currentMemory>819200</currentMemory>
      <vcpu>1</vcpu>
      <os>
        <type arch='x86_64' machine='rhel'>hvm</type>
        <boot dev='network'/>
      </os>
      <features>
        <acpi/>
        <apic/>
        <pae/>
      </features>
      <clock offset='utc'/>
      <on_poweroff>destroy</on_poweroff>
      <on_reboot>destroy</on_reboot>
      <on_crash>destroy</on_crash>
      <devices>
        <emulator>/usr/libexec/qemu-kvm</emulator>
        <disk type='block' device='disk'>
          <driver name='qemu' type='raw'/>
          <source dev='/dev/disk/by-path/ip-192.168.122.170:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1'/>
          <target dev='hda' bus='ide'/>
          <alias name='ide0-0-0'/>
          <address type='drive' controller='0' bus='0' unit='0'/>
        </disk>
        <disk type='block' device='disk'>
          <driver name='qemu' type='raw'/>
          <source dev='/dev/disk/by-path/ip-192.168.122.170:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-2'/>
          <target dev='hdb' bus='ide'/>
          <shareable/>
          <alias name='ide0-0-1'/>
          <address type='drive' controller='0' bus='0' unit='1'/>
        </disk>
        <controller type='ide' index='0'>
          <alias name='ide0'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
        </controller>
        <interface type='network'>
          <mac address='52:54:00:0a:ca:84'/>
          <source network='default'/>
          <target dev='vnet1'/>
          <alias name='net0'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
        </interface>
        <serial type='pty'>
          <source path='/dev/pts/28'/>
          <target port='0'/>
          <alias name='serial0'/>
        </serial>
        <console type='pty' tty='/dev/pts/28'>
          <source path='/dev/pts/28'/>
          <target port='0'/>
          <alias name='serial0'/>
        </console>
        <input type='mouse' bus='ps2'/>
        <graphics type='vnc' port='5901' autoport='yes' keymap='en-us'/>
        <video>
          <model type='cirrus' vram='9216' heads='1'/>
          <alias name='video0'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
        </video>
      </devices>
    </domain>
    
    There are two important items of note in this output:
    • The guest uses the large /dev/disk/by-path paths to refer to the LUNs. As described earlier, this is so that file names and paths will remain constant.
    • The second disk has the <shareable/> flag set. Critical for the disk to be safely shared between guests, this ensures that the SELinux labelling will be appropriate for multiple guests to access the disk and that all I/O caching is disabled on the host.
For migration of guests between hosts to succeed, some form of shared storage is required. Although NFS is often used for this purpose, the lack of SELinux labelling for NFS means there is limited sVirt protection between guests. This lack of sVirt support could allow one guest to use another guest's disks, which is usually undesirable.
Using iSCSI provides full sVirt isolation between guests to the same degree of non-shared storage.

パート VI. 仮想化リファレンスガイド

第24章 仮想化のツール

Xen を実行するシステムに役に立つ仮想化の管理、デバッギング、及びネットワーキングの 為のツールリストを以下に示します。
システム管理ツール
  • vmstat
  • iostat
  • lsof
    # lsof -i :5900
    xen-vncfb 10635  root  5u  IPv4 218738  TCP grumble.boston.redhat.com:5900 (LISTEN)
    
  • qemu-img
高度なデバッギングツール
  • systemTap
  • crash
  • xen-gdbserver
  • sysrq
  • sysrq t
  • sysrq w
  • sysrq c
ネットワーキング
brtcl
  • # brctl show
    bridge name  bridge id            STP enabled    interfaces
    xenbr0       8000.feffffffffff    no             vif13.0
    						 pdummy0
                                                     vif0.0
    
  • # brctl showmacs xenbr0
    port no  mac addr                is local?       aging timer
      1      fe:ff:ff:ff:ff:ff       yes             0.00
    
  • # brctl showstp xenbr0
    xenbr0
    bridge id              8000.feffffffffff
    designated root        8000.feffffffffff
    root port              0                    path cost                 0
    max age                20.00                bridge max age            20.00
    hello time             2.00                 bridge hello time         2.00
    forward delay          0.00                 bridge forward delay      0.00
    aging time            300.01
    hello timer            1.43                 tcn timer                 0.00
    topology change timer  0.00                 gc timer                  0.02
    flags
    
    vif13.0 (3)
    port id                8003                 state                    forwarding
    designated root        8000.feffffffffff    path cost                100
    designated bridge      8000.feffffffffff    message age timer        0.00
    designated port        8003                 forward delay timer      0.00
    designated cost        0                    hold timer               0.43
    flags
    
    pdummy0 (2)
    port id                8002                 state                    forwarding
    designated root        8000.feffffffffff    path cost                100
    designated bridge      8000.feffffffffff    message age timer        0.00
    designated port        8002                 forward delay timer      0.00
    designated cost        0                    hold timer               0.43
    flags
    
    vif0.0 (1)
    port id                8001                 state                    forwarding
    designated root        8000.feffffffffff    path cost                100
    designated bridge      8000.feffffffffff    message age timer        0.00
    designated port        8001                 forward delay timer      0.00
    designated cost        0                    hold timer               0.43
    flags
    
  • ifconfig
  • tcpdump
KVM ツール
  • ps
  • pstree
  • top
  • kvmtrace
  • kvm_stat
Xen ツール
  • xentop
  • xm dmesg
  • xm log

第25章 virsh でゲストを管理

virsh はゲストと hypervisor を管理するための コマンドラインインターフェイスです。
virsh ツールは libvirt 管理 API を 土台にして構築されており、xm コマンドとグラフィカルゲスト マネージャ (virt-manager) への代替として機能します。 virsh は特別権限のないユーザーにより読み込み専用モードで 使用可能です。 virsh を使用してゲストマシン用のスクリプトを 実行することができます。
virsh コマンドのクイックリファレンス
以下の表では、全ての virsh コマンドラインオプションのクイックリファレンスを 提供します。
表25.1 ゲスト管理のコマンド
コマンド 説明
help 基本的なヘルプ情報を表示します。
list 全てのゲストを一覧表示します。
dumpxml ゲスト用の XML 設定ファイルを出力します。
create XML 設定ファイルからゲストを作成して新規のゲストを開始します。
start 停止中のゲストを開始します。
destroy ゲストを強制的に停止します。
define ゲスト用の XML 設定ファイルを出力します。
domid Displays the guest's ID.
domuuid Displays the guest's UUID.
dominfo ゲスト情報を表示します。
domname Displays the guest's name.
domstate ゲストの状態を表示します。
quit 対話式のターミナルを終了します。
reboot ゲストを再起動します。
restore ファイル内に以前に保存されているゲストを復元します。
resume 休止中のゲストを復帰します。
save ゲストの現在の状態をファイルに保存します。
shutdown ゲストを丁寧にシャットダウンします。
suspend ゲストを休止します。
undefine ゲストに関連のファイルをすべて削除します。
migrate ゲストを別のホストに移行します。

以下の virsh コマンドはゲストと hypervisor リソースを 管理します:
表25.2 リソース管理のオプション
コマンド 説明
setmem ゲストのために割り当てたメモリーを設定します。
setmaxmem hypervisor 用の最大メモリー限度を設定します。
setvcpus ゲストに割り当てた仮想 CPU の数を変更します。
vcpuinfo ゲストに関して仮想 CPU 情報を表示します。
vcpupin ゲストの仮想 CPU 同類を制御します。
domblkstat 実行中ゲストのブロックデバイス統計を表示します。
domifstat 実行中のゲストのネットワークインターフェイス統計を表示します。
attach-device XML ファイル内のデバイス定義を使用してゲストへデバイスを添付します。
attach-disk 新規のディスクデバイスをゲストに添付します。
attach-interface 新規のネットワークインターフェイスをゲストに添付します。
detach-device ゲストからデバイスを分離し、attach-device コマンドと 同じ種類の XML 記述を提示します。
detach-disk ゲストからディスクデバイスを分離します。
detach-interface ゲストからネットワークインターフェイスを分離します。

以下にその他の virsh オプションを示します:
表25.3 その他のオプション
コマンド 説明
version virshのバージョンを表示します。
nodeinfo hypervisor に関する情報を出力します。

Hypervisor への接続
virsh で hypervisor セッションへ接続します:
# virsh connect {hostname OR URL}
ここで、<name> は hypervisor のマシン名です。読み込み専用の接続を開始したい場合、上記のコマンドに -readonly を追記します。
仮想マシン XML ダンプ(設定ファイル)を作成
Output a guest's XML configuration file with virsh:
# virsh dumpxml {domain-id, domain-name or domain-uuid}
This command outputs the guest's XML configuration file to standard out (stdout). You can save the data by piping the output to a file. An example of piping the output to a file called guest.xml:
# virsh dumpxml GuestID > guest.xml
This file guest.xml can recreate the guest (refer to Editing a guest's configuration file. You can edit this XML configuration file to configure additional devices or to deploy additional guests. Refer to 「virsh を用いた XML 設定ファイルの使用」 for more information on modifying files created with virsh dumpxml.
virsh dumpxml 出力の例:
# virsh dumpxml r5b2-mySQL01
<domain type='xen' id='13'>
    <name>r5b2-mySQL01</name>
    <uuid>4a4c59a7ee3fc78196e4288f2862f011</uuid>
    <bootloader>/usr/bin/pygrub</bootloader>
    <os>
        <type>linux</type>
        <kernel>/var/lib/libvirt/vmlinuz.2dgnU_</kernel>
	<initrd>/var/lib/libvirt/initrd.UQafMw</initrd>
        <cmdline>ro root=/dev/VolGroup00/LogVol00 rhgb quiet</cmdline>
    </os>
    <memory>512000</memory>
    <vcpu>1</vcpu>
    <on_poweroff>destroy</on_poweroff>
    <on_reboot>restart</on_reboot>
    <on_crash>restart</on_crash>
    <devices>
        <interface type='bridge'>
            <source bridge='xenbr0'/>
            <mac address='00:16:3e:49:1d:11'/>
            <script path='vif-bridge'/>
        </interface>
        <graphics type='vnc' port='5900'/>
        <console tty='/dev/pts/4'/>
    </devices>
</domain>
設定ファイルからゲストを作成
Guests can be created from XML configuration files. You can copy existing XML from previously created guests or use the dumpxml option (refer to 仮想マシン XML ダンプ(設定ファイル)を作成). To create a guest with virsh from an XML file:
# virsh create configuration_file.xml
Editing a guest's configuration file
Instead of using the dumpxml option (refer to 仮想マシン XML ダンプ(設定ファイル)を作成) guests can be edited either while they run or while they are offline. The virsh edit command provides this functionality. For example, to edit the guest named softwaretesting:
# virsh edit softwaretesting
これがテキストエディタを開きます。デフォルトのテキストエディタは $EDITOR シェルパラメータです(デフォルトで vi にセット)。
ゲストの休止
virsh を使用してゲストを休止します:
# virsh suspend {domain-id, domain-name or domain-uuid}
When a guest is in a suspended state, it consumes system RAM but not processor resources. Disk and network I/O does not occur while the guest is suspended. This operation is immediate and the guest can be restarted with the resume (ゲストの復帰) option.
ゲストの復帰
resume オプションと共に virsh を 使用して休止中のゲストを復帰します:
# virsh resume {domain-id, domain-name or domain-uuid}
この操作は直ちに反映されて、ゲストパラメータは suspend resume 操作用に保持されます。
ゲストを保存
virsh コマンドを使用してゲストの現在の状態をファイルに 保存します:
# virsh save {domain-name, domain-id or domain-uuid} filename
This stops the guest you specify and saves the data to a file, which may take some time given the amount of memory in use by your guest. You can restore the state of the guest with the restore (ゲストの復帰) option. Save is similar to pause, instead of just pausing a guest the present state of the guest is saved.
ゲストの復帰
Restore a guest previously saved with the virsh save command (ゲストを保存) using virsh:
# virsh restore filename
This restarts the saved guest, which may take some time. The guest's name and UUID are preserved but are allocated for a new id.
ゲストのシャットダウン
virsh コマンドを使用してゲストをシャットダウンします:
# virsh shutdown {domain-id, domain-name or domain-uuid}
You can control the behavior of the rebooting guest by modifying the on_shutdown parameter in the guest's configuration file.
ゲストの再起動
virsh コマンドを使用してゲストを再起動します:
#virsh reboot {domain-id, domain-name or domain-uuid}
You can control the behavior of the rebooting guest by modifying the on_reboot element in the guest's configuration file.
ゲストを強制的に停止
virsh コマンドを使用してゲストの停止を強制します:
# virsh destroy {domain-id, domain-name or domain-uuid}
This command does an immediate ungraceful shutdown and stops the specified guest. Using virsh destroy can corrupt guest file systems . Use the destroy option only when the guest is unresponsive. For para-virtualized guests, use the shutdown option(ゲストのシャットダウン) instead.
ゲストのドメイン ID を取得
ゲストのドメイン ID を取得するには:
# virsh domid {domain-name or domain-uuid}
ゲストのドメイン名を取得
ゲストのドメイン名を取得するには:
# virsh domname {domain-id or domain-uuid}
ゲストの UUID を取得
ゲストの UUID(Universally Unique Identifier)を取得するには:
# virsh domuuid {domain-id or domain-name}
virsh domuuid の出力の例:
# virsh domuuid r5b2-mySQL01
4a4c59a7-ee3f-c781-96e4-288f2862f011
ゲスト情報の表示
Using virsh with the guest's domain ID, domain name or UUID you can display information on the specified guest:
# virsh dominfo {domain-id, domain-name or domain-uuid}
以下に virsh dominfo 出力の例を示します:
# virsh dominfo r5b2-mySQL01
id:             13
name:           r5b2-mysql01
uuid:           4a4c59a7-ee3f-c781-96e4-288f2862f011
os type:      	linux
state:          blocked
cpu(s):         1
cpu time:     	11.0s
max memory:     512000 kb
used memory:    512000 kb
ホスト情報の表示
ホストに関する情報を表示するには:
# virsh nodeinfo
virsh nodeinfo 出力の例 :
# virsh nodeinfo
CPU model                    x86_64
CPU (s)                      8
CPU frequency                2895 Mhz
CPU socket(s)                2      
Core(s) per socket           2
Threads per core:            2
Numa cell(s)                 1
Memory size:                 1046528 kb
これは、ノード情報と仮想化プロセスに対応するマシンを表示します。
ゲストの表示
virsh コマンドを使用してゲストの一覧とその現在状態を 表示するには:
# virsh list
使用できる他のオプションには以下があります:
活動していないゲスト(定義されていても現在活動していないゲスト)の一覧表示する --inactive オプション 。そして
全てのゲストを一覧表示する --all オプション。 例えば:
# virsh list --all
 Id Name                 State
----------------------------------
  0 Domain-0             running
  1 Domain202            paused
  2 Domain010            inactive
  3 Domain9600           crashed
virsh list からの出力は6つの状態の1つとして 分類されます(以下の一覧)。
  • running 状態は CPU 上で現在活動中のゲストを 示します。
  • blocked として表示してあるゲストは阻止されており、 実行していないか、又は実行不可能です。これは I/O 待ちのゲスト(旧来の wait 状態)か、 スリープモードのゲストがその要因です。
  • paused 状態は休止中のドメインを一覧表示します。 これは、管理者が virt-managerxm pause、 又は virsh suspend で、pause ボタンを使用する ことで発生します。ゲストが休止している時は、メモリーとその他のリソースを消費しますが、スケジュールと hypervisor からの CPU リソースには無視できる量です。
  • shutdown 状態は シャットダウンプロセスにある ゲスト用のものです。ゲストはシャットダウン信号を受けてその運用を丁寧に終了するプロセスに 入るべき状態です。これは全てのゲストオペレーティングシステムでは機能しないかも知れません。 一部のオペレーティングシステムはこの信号に良く反応しません。
  • dying 状態のドメインはご臨終のプロセスにある ものです。これはドメインがシャットダウンやクラッシュを完全に終了していない状態を指します。
  • crashed の場合、ゲストは実行中に障害を受け、もう 実行していない状態です。この状態はクラッシュ時にゲストが再スタートしないように設定されている 場合にのみ発生します。
仮想 CPU 情報の表示
virsh を使用してゲストからの仮想 CPU の情報を 表示するには:
# virsh vcpuinfo {domain-id, domain-name or domain-uuid}
virsh vcpuinfo 出力の例:
# virsh vcpuinfo r5b2-mySQL01
VCPU:           0
CPU:            0
State:          blocked
CPU time:       0.0s
CPU Affinity:   yy
仮想 CPU 類似物の設定
物理 CPU を使用して、仮想 CPU の類似物を設定するには:
# virsh vcpupin domain-id vcpu cpulist
The domain-id parameter is the guest's ID number or name.
vcpu パラメータは、ゲストに割り当てられた仮想 CPU の数を示します。 vcpu パラメータは必須項目です。
cpulist パラメータは、コンマで区切られた物理 CPU の 識別子番号の一覧です。cpulist パラメータはどの物理 CPU で VCPU が稼働するかを決定します。
仮想 CPU カウントの設定
virsh を使用してゲストに割り当てられた CPU の数を 修正するには:
# virsh setvcpus {domain-name, domain-id or domain-uuid} count
新しい count 値はゲストが作成された時に指定されたカウントを 超過することは出来ません。
メモリー割り当ての設定
To modify a guest's memory allocation with virsh :
# virsh setmem {domain-id or domain-name} count
count はキロバイトで指定する必要があります。新しいカウントは ゲストを作成した時に指定した数量を超えることができないことに注意して下さい。64 MB より低い値はほとんどのオペレーティングシステムでは多分機能しないでしょう。最大メモリーを上げても 活動中ゲストに影響することはありません。新しい値がより低い場合、利用可能なメモリーは 縮小し、ゲストはクラッシュする可能性があります。
ゲストブロックデバイス情報の表示
virsh domblkstat を使用すると稼働中のゲストの ブロックデバイス統計が表示できます。
# virsh domblkstat GuestName block-device
ゲストネットワークデバイス情報の表示
virsh domifstat を使用すると、稼働中のゲストの ネットワークインターフェイス統計が表示できます。
# virsh domifstat GuestName interface-device 
virsh でゲスト移行を管理
ゲストは virsh を使用して別のホストへ移行することが できます。ドメインを別のホストへ移行します。ライブ移行用には --live を追加します。 migrate コマンドは以下の形式のパラメータを受け付けます:
# virsh migrate --live GuestName DestinationURL
--live パラメータはオプションです。ライブ移行用には --live パラメータを追加します。
GuestName パラメータは移行したいゲストの名前を示します。
DestinationURL パラメータは移行先システムの URL 又はホスト名です。移行先システムは以下を必要とします:
  • Red Hat Enterprise Linux の同じバージョン
  • 同じ hypervisor (KVM か Xen)、それに
  • libvirt サービスが開始する必要があります。
コマンドが入力された後は、目的地システムの root パスワードを 要求されます。
仮想ネットワークの管理
このセクションでは、virsh コマンドを使用した仮想化 ネットワークの管理を説明します。仮想化ネットワークを一覧表示するには:
# virsh net-list
このコマンドは以下のような出力を出します:
# virsh net-list
Name                 State      Autostart
-----------------------------------------
default              active     yes      
vnet1	             active     yes      
vnet2	             active     yes
特定の仮想ネットワークの為のネットワーク情報を表示するには:
# virsh net-dumpxml NetworkName
この画面は指定された仮想ネットワークに関する情報を XML 形式で表示します:
# virsh net-dumpxml vnet1
<network>
  <name>vnet1</name>
  <uuid>98361b46-1581-acb7-1643-85a412626e70</uuid>
  <forward dev='eth0'/>
  <bridge name='vnet0' stp='on' forwardDelay='0' />
  <ip address='192.168.100.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.100.128' end='192.168.100.254' />
    </dhcp>
  </ip>
</network>
仮想ネットワークの管理に使用される他の virsh コマンドを以下に示します:
  • virsh net-autostart [network name]network-name で指定された ネットワークを自動開始します。
  • virsh net-create XMLfile — 既存の XML ファイルを使用して新規のネットワークを生成して開始します。
  • virsh net-define XMLfile — 既存の XML ファイルから新規のネットワークデバイスを生成しますが開始しません。
  • virsh net-destroy network-namenetwork-name として指定された ネットワークを破棄します。
  • virsh net-name networkUUID — 指定された networkUUID をネットワーク名に変換します。
  • virsh net-uuid network-name — 指定された network-name をネットワーク UUID に変換します。
  • virsh net-start nameOfInactiveNetwork — 休止中のネットワークを開始します。
  • virsh net-undefine nameOfInactiveNetwork — 休止中のネットワークを定義解除します。

第26章 仮想マシンマネージャ(virt-manager) でゲストを管理する

このセクションでは、仮想マシンマネージャ (virt-manager) ウィンドウ、ダイアログボックス、各種 GUI 制御などを説明しています。
virt-manager はユーザーのシステム上とリモートマシン上の hypervisor とゲストのグラフィカル表示を提供します。para-virtualized と完全仮想化の両方の ゲストを定義するのにも virt-manager を使用できます。そして virt-manager は以下を含む、仮想化管理のタスクも演じることができます:
  • メモリーの割り当て、
  • 仮想 CPU の割り当て、
  • 動作パフォーマンスの監視、
  • 仮想化ゲストの保存と復元、休止と復帰、及びシャットダウンと開始、
  • テキストとグラフィカルのコンソールへのリンク、
  • ライブとオフラインの移行。

26.1. The Add Connection window

ウィンドウがまず表示されてユーザーに対して hypervisor セッションを選択するように催促します。 特権の無いユーザーは読み込み専用のセッションを開始できます。Root ユーザーは完全な 読み込み/書き込みステータスでセッションを開始できます。通常の使用には、ローカル Xen ホスト オプションか、QEMU (KVM 用) を選択して下さい。
仮想マシンマネージャの接続ウィンドウ
図26.1 仮想マシンマネージャの接続ウィンドウ

26.2. 仮想マシンマネージャの主要ウィンドウ

This main window displays all the running guests and resources used by guests. Select a virtualized guest by double clicking the guest's name.
仮想マシンマネージャの主要ウィンドウ
図26.2 仮想マシンマネージャの主要ウィンドウ

26.3. The guest Overview tab

The Overview tab displays graphs and statistics of a guest's live resource utilization data available from virt-manager. The UUID field displays the globally unique identifier for the virtual machines.
The Overview tab
図26.3 The Overview tab

26.4. 仮想マシングラフィカルコンソール

This window displays a virtual machine's graphical console. Para-virtualized and fully virtualized guests use different techniques to export their local virtual framebuffers, but both technologies use VNC to make them available to the Virtual Machine Manager's console window. If your virtual machine is set to require authentication, the Virtual Machine Graphical console prompts you for a password before the display appears.
グラフィカルコンソールウィンドウ
図26.4 グラフィカルコンソールウィンドウ

セキュリティと VNC に関する注記

VNC is considered insecure by many security experts, however, several changes have been made to enable the secure usage of VNC for virtualization on Red Hat enterprise Linux. The guest machines only listen to the local host (dom0)'s loopback address (127.0.0.1). This ensures only those with shell privileges on the host can access virt-manager and the virtual machine through VNC.
Remote administration can be performed following the instructions in 22章仮想化ゲストのリモート管理. TLS can provide enterprise level security for managing guest and host systems.
Your local desktop can intercept key combinations (for example, Ctrl+Alt+F11) to prevent them from being sent to the guest machine. You can use the virt-manager sticky key capability to send these sequences. To use this capability, you must press any modifier key (Ctrl or Alt) 3 times and the key you specify gets treated as active until the next non-modifier key is pressed. You can then send Ctrl-Alt-F11 to the guest by entering the key sequence 'Ctrl Ctrl Ctrl Alt+F1'.

注記

Due to a limitation of virt-manager, it is not possible to use this sticky key feature to send a Sysrq key combination to a guest.

26.5. virt-manager の開始

virt-manager のセッションを開始するには、 アプリケーション メニューを開いて、それから システムツール メニュー、仮想マシンマネージャ (virt-manager) と進んで行きます。
virt-manager の主要ウィンドウが表示されます。
virt-manager の開始
図26.5 virt-manager の開始

Alternatively, virt-manager can be started remotely using ssh as demonstrated in the following command:
ssh -X host's address[remotehost]# virt-manager
Using ssh to manage virtual machines and hosts is discussed further in 「SSH を使用したリモート管理」.

26.6. 保存したマシンの復元

仮想マシンマネージャを開始した後は、システム上の全ての仮想マシンが主要ウィンドウに表示されます。Domain0 はユーザーのホストシステムです。マシンの表示がない場合は、現在、システム上で実行中のマシンがないと言う意味になります。
以前の保存セッションを復元するには:
  1. ファイル メニューから 保存したマシンの復元 を選択します。
    仮想マシンの復元
    図26.6 仮想マシンの復元

  2. 仮想マシンの復元 の主要ウィンドウが出ます。
  3. 該当のディレクトリに移動して、保存したセッションファイルを選択します。
  4. 開く をクリックします。
保存してある仮想システムが仮想マシンマネージャの主要ウィンドウに出て来ます。
復元された仮想マシンマネージャのセッション
図26.7 復元された仮想マシンマネージャのセッション

26.7. ゲストの詳細表示

仮想マシンモニターを使用して、システム上の仮想マシン用の活動データ情報を表示することができます。
To view a virtual system's details:
  1. 仮想マシンマネージャの主要ウィンドウで、表示したい仮想マシンを強調表示します。
    表示する仮想マシンを選択
    図26.8 表示する仮想マシンを選択

  2. From the Virtual Machine Manager Edit menu, select Machine Details (or click the Details button on the bottom of the Virtual Machine Manager main window).
    Displaying the overview window
    図26.9 Displaying the overview window

    On the Virtual Machine window, click the Overview tab.
    The Overview tab summarizes CPU and memory usage for the virtualized guest you specified.
    ゲストの詳細概要を表示
    図26.10 ゲストの詳細概要を表示

  3. On the Virtual Machine window, click the Hardwaretab.
    ゲストハードウェアの詳細を表示
    図26.11 ゲストハードウェアの詳細を表示

  4. ハードウェア タブで プロセッサ をクリックして、現在のプロセッサ割り当ての表示や変更をします。
    プロセッサ割り当てのパネル
    図26.12 プロセッサ割り当てのパネル

  5. ハードウェア タブで、メモリー をクリックして、現在の RAM メモリー割り当ての表示や変更をします。
    メモリー割り当ての表示
    図26.13 メモリー割り当ての表示

  6. ハードウェア タブで ディスク をクリックして現在のハードディスク設定の表示や変更をします。
    ディスク設定の表示
    図26.14 ディスク設定の表示

  7. On the Hardware tab, click on NIC to view or change the current network configuration.
    ネットワーク設定の表示
    図26.15 ネットワーク設定の表示

26.8. ステータスの監視

Status status monitoring preferences can be modified with virt-manager's preferences window.
To configure status monitoring:
  1. 編集 メニューから 個人設定 を選択します。
    ゲストの個人設定の修正
    図26.16 ゲストの個人設定の修正

    The Preferences window appears.
  2. From the Stats tab specify the time in seconds or stats polling options.
    ステータス監視の設定
    図26.17 ステータス監視の設定

26.9. ゲスト識別子の表示

システム上の全ての仮想マシン用のドメイン ID を表示するには:
  1. 表示 メニューから、ドメイン ID チェックボックスを選択します。
    ゲスト ID の表示
    図26.18 ゲスト ID の表示

  2. 仮想マシンマネージャは、システム上の全てのドメイン用のドメイン ID を一覧表示します。
    ドメイン ID の表示
    図26.19 ドメイン ID の表示

26.10. Displaying a guest's status

システム上の全ての仮想マシンのステータスを表示するには:
  1. 表示 メニューから、ステータス チェックボックスを選択します。
    Selecting a virtual machine's status
    図26.20 Selecting a virtual machine's status

  2. 仮想マシンマネージャはシステム上の全ての仮想マシンのステータスを一覧表示します。
    Displaying a virtual machine's status
    図26.21 Displaying a virtual machine's status

26.11. 仮想 CPU の表示

システム上の全ての仮想マシン用の仮想 CPU の数量を表示するには:
  1. 表示 メニューから、仮想 CPU チェックボックスを選択します。
    仮想 CPU オプションの選択
    図26.22 仮想 CPU オプションの選択

  2. 仮想マシンマネージャは、システム上の全ての仮想マシン用の仮想 CPU を一覧表示します。
    仮想 CPU の表示
    図26.23 仮想 CPU の表示

26.12. CPU 使用量の表示

システム上の全ての仮想マシン用の CPU 使用量を表示するには:
  1. 表示 メニューから、CPU 使用量 チェックボックスを選択します。
    CPU 使用量の選択
    図26.24 CPU 使用量の選択

  2. 仮想マシンマネージャは、システム上の全ての仮想マシン用の CPU 使用率を一覧表示します。
    CPU 使用量の表示
    図26.25 CPU 使用量の表示

26.13. メモリー使用量の表示

システム上の全ての仮想マシン用のメモリー使用量を表示するには:
  1. 表示 メニューから、メモリー使用量 チェックボックスを選択します。
    メモリー使用量の選択
    図26.26 メモリー使用量の選択

  2. 仮想マシンマネージャは、システム上の全ての仮想マシン用のメモリー使用量をメガバイトで一覧表示します。
    メモリー使用量の表示
    図26.27 メモリー使用量の表示

26.14. 仮想ネットワークの管理

システム上の仮想ネットワークを設定するには:
  1. 編集 メニューから ホストの詳細(Host Details) を選択します。
    Selecting a host's details
    図26.28 Selecting a host's details

  2. これが ホストの詳細 メニューを開きます。 仮想ネットワーク タブをクリックします。
    仮想ネットワークの設定
    図26.29 仮想ネットワークの設定

  3. 使用できる仮想ネットワークは全て、メニューの左側ボックスに表示されています。 このボックスから一つの仮想ネットワークを選択して、必要に応じた編集をすることで その設定を変更できます。

26.15. 仮想ネットワークの作成

システム上に仮想ネットワークを作成するには:
  1. Open the Host Details menu (refer to 「仮想ネットワークの管理」) and click the Add button.
    仮想ネットワークの設定
    図26.30 仮想ネットワークの設定

    そうすると、新規仮想ネットワークの作成(Create a new virtual network) メニューが開きます。進む(Forward) をクリックして 継続します。
    新規仮想ネットワークの作成
    図26.31 新規仮想ネットワークの作成

  2. 使用する仮想ネットワークの名前を入力して、それから 進む をクリックします。
    仮想ネットワークの命名
    図26.32 仮想ネットワークの命名

  3. 使用する仮想ネットワークの IPv4 アドレスを入力して、それから 進む を クリックします。
    IPv4 のアドレススペースの選択
    図26.33 IPv4 のアドレススペースの選択

  4. IP アドレスの 開始終了 の 範囲を指定して、使用したい仮想ネットワークの DHCP 幅を定義します。 進む(Forward) をクリックして継続します。
    DHCP の範囲を選択
    図26.34 DHCP の範囲を選択

  5. 仮想ネットワークが物理ネットワークに接続する方法を選択します。
    物理ネットワークへの接続
    図26.35 物理ネットワークへの接続

    物理ネットワークへ転送(Forwarding to physical network) を選択する場合、転送先(Destination)いずれかの物理デバイスに NAT とすべきか、又は、物理デバイス eth0 に NAT とすべきを選びます。
    進む をクリックして継続します。
  6. これでネットワーク作成の準備ができました。ネットワークの設定を確認して、 完了(Finish) をクリックします。
    ネットワーク作成への準備終了
    図26.36 ネットワーク作成への準備終了

  7. 仮想ネットワークが今、ホストの詳細(Host Details)仮想ネットワーク タブで使用できます。
    新規の仮想ネットワークが今、使用できます。
    図26.37 新規の仮想ネットワークが今、使用できます。

第27章 xm コマンドのクイックリファレンス

xm コマンドには Xen hypervisor を管理する機能があります。 ほとんどの操作は libvirt ツール、virt-manager アプリケーション、 あるいは、virsh コマンドで実行されます。xm コマンドは、libvirt ツールのエラーチェック機能を持ちませんので libvirt ツールのタスクには 使用すべきではありません。
現時点では、virt-manager の使用では実行 できない操作がいくつかあります。xm コマンドの 他の Xen 実装用のオプションの一部は Red Hat Enterprise Linux 5 で動作 しません。以下のリストは利用可能と利用不可能なコマンドオプションの概要を 提供します。

警告

xm ではなく、virsh、又は virt-manager の使用が推奨されます。xm コマンドはエラーチャックや設定ファイルエラーをうまく処理できないため、誤動作が 仮想マシン内のシステム不安定性やエラーを招きます。Xen 設定ファイルを手動で編集することは 危険であり、回避すべきです。この章はご自分の責任で使用判断して下さい。
基本的管理オプション
一般に使用される基本的な xm コマンド群を以下に示します:
  • xm help [--long]: 使用可能なオプションとヘルプテキストを表示します。
  • xm list コマンドを使用して活動中のドメインをリストできます:
    $ xm list
    Name                                ID  Mem(MiB)   VCPUs      State      Time(s)
    Domain-0                            0     520       2         r-----     1275.5
    r5b2-mySQL01                       13     500       1         -b----       16.1
    
  • xm create [-c] DomainName/ID: start a virtual machine. If the -c option is used, the start up process will attach to the guest's console.
  • xm console DomainName/ID: attach to a virtual machine's console.
  • xm destroy DomainName/ID: パワーオフと同様に、仮想マシンを終了します。
  • xm reboot DomainName/ID: 仮想マシンをリブートして、通常のシステムシャットダウンと開始のプロセスを実行します。
  • xm shutdown DomainName/ID: 仮想マシンをシャットダウンして、通常のシステムシャットダウン工程を実行できます。
  • xm pause
  • xm unpause
  • xm save
  • xm restore
  • xm migrate
リソース管理のオプション
次の xm コマンド群を使用してリソースを管理することができます:
  • xm mem-set
  • xm vcpu-list を使用して仮想化 CPU のグループをリストできます:
    $ xm vcpu-list
    Name                          ID  VCPUs   CPU State  Time(s)  CPU Affinity
    Domain-0                       0    0      0    r--   708.9    any cpu
    Domain-0                       0    1      1   -b-    572.1    any cpu
    r5b2-mySQL01                  13    0      1   -b-     16.1    any cpu
    
  • xm vcpu-pin
  • xm vcpu-set
  • xm sched-credit コマンドを使用して任意のドメイン用の スケジューラパラメータを表示することができます:
    $ xm sched-credit -d 0
    {'cap': 0, 'weight': 256}
    $ xm sched-credit -d 13
    {'cap': 25, 'weight': 256}
    
監視とトラブルシューティングのオプション
監視とトラブルシューティングには、次の xm コマンド群を 使用します:
  • xm top
  • xm dmesg
  • xm info
  • xm log
  • xm uptime を使用してゲストとホストのアップタイムを表示 できます:
    $ xm uptime
    Name                       ID  Uptime
    Domain-0                    0  3:42:18
    r5b2-mySQL01               13  0:06:27
    
  • xm sysrq
  • xm dump-core
  • xm rename
  • xm domid
  • xm domname
現在サポートのないオプション
xm vnet-list には、現在サポートがありません。

第28章 Xen カーネルブートパラメータの設定

GRUB (GNU Grand Unified Boot Loader) は各種のインストール済オペレーティングシステム、 またはカーネルをブートするプログラムです。またこれは、ユーザーがカーネルに引数を渡すことを 可能にします。GRUB 設定ファイル (/boot/grub/grub.conf に存在) は GRUB ブートメニューインターフェイス用にオペレーティングシステムのリストを作成します。kernel-xen RPM をインストールすると、スクリプトが kernel-xen エントリを GRUB 設定ファイルに追加し、これがデフォルトで kernel-xen を ブートします。 grub.conf ファイルの編集で、デフォルトの カーネルを修正するか、又は別のカーネルパラメータを追加します。
title Red Hat Enterprise Linux Server (2.6.18-3.el5xen)
root (hd0,0)
	kernel  /xen.gz.-2.6.18-3.el5
	module  /vmlinuz-2.6..18-3.el5xen ro root=/dev/VolGroup00/LogVol00  rhgb quiet
	module  /initrd-2.6.18-3. el5xenxen.img
Linux grub エントリをこの例のように設定すると、ブートローダは hypervisor とinitrd イメージと Linux カーネルをロードします。カーネルエントリは他のエントリの上部にある為、カーネルが最初にメモリーにロードされます。ブートローダはコマンドライン引数を hypervisor と Linux カーネルに送り、またそれらから受理します。次の例では Dom0 linux カーネルメモリーを 800 MB に制限する方法を示しています:
title Red Hat Enterprise Linux Server (2.6.18-3.el5xen)
root (hd0,0)
	kernel  /xen.gz.-2.6.18-3.el5 dom0_mem=800M
	module  /vmlinuz-2.6..18-3.el5xen ro root=/dev/VolGroup00/LogVol00  rhgb quiet
	module  /initrd-2.6.18-3. el5xenxen.img
これらの GRUB パラメータを使用することで Virtualization hypervisor を設定できます:
mem
これが hypervisor カーネルで利用できるメモリーの容量を制限します。
com1=115200, 8n1
これによりシステム内の一番目のシリアルポートがシリアルコンソールとして動作できるようになります (com2 は その次のポートと言う順に割り当てられます)。
dom0_mem
これが、 hypervisor 用に使用できるメモリーを制限します。
dom0_max_vcpus
これが Xen domain0 から見える CPU の容量を制限します。
acpi
これが ACPI hypervisor を hypervisor と domain0 に切り替えます。ACPI パラメータのオプションには次のようなものがあります:
/*   ****  Linux config options: propagated to domain0  ****/
/*   "acpi=off":      Disables both ACPI table parsing and interpreter.   */
/*   "acpi=force":    Overrides the disable blacklist.                    */
/*   "acpi=strict":   Disables out-of-spec workarounds.                   */
/*   "acpi=ht":       Limits ACPI from boot-time to enable HT.            */
/*   "acpi=noirq":    Disables ACPI interrupt routing.                    */
noacpi
これは割り込み伝達用の ACPI を無効にします。

第29章 ELILO の設定

ELILO は 特に Itanium® などの EFI ベースの システムで使用されるブートローダです。x86 と x86-64 のシステム上のブートローダ、GRUB と同様に ELILO はユーザーがシステムブートシーケンスでインストール済みのカーネルを選択できるようにします。ELILO は また、ユーザーがカーネルに引数を渡すことができるようにします。ELILO 設定ファイルは ELILO ブート パーティションにあり、/etc/elilo.conf にシンボルリンクがあるもので、グローバル オプションとイメージスタンザの一覧を含んでいます。kernel-xen RPM をインストール すると、ポストインストールスクリプトが適切なイメージスタンザを elilo.conf に追加します。

ELILO

ELILO に関するこのセクションは、intel Itanium アーキテクチャ上で Xen カーネルを稼働しているシステムが対象です。
ELILO 設定ファイルは次の 2つのセクションを持ちます:
  • ELILO の動作と全てのエントリに影響するグローバルオプション。 標準的には,これらをデフォルト値から変更する必要はありません。
  • 関連のオプションと共にブート選択を定義するイメージスタンザ。
Here is a sample image stanza in elilo.conf:
image=vmlinuz-2.6.18-92.el5xen
        vmm=xen.gz-2.6.18-92.el5
        label=linux
        initrd=initrd-2.6.18-92.el5xen.img
        read-only
        root=/dev/VolGroup00/rhel5_2
        append="-- rhgb quiet"
The image parameter indicates the following lines apply to a single boot selection. This stanza defines a hypervisor (vmm), initrd, and command line arguments (read-only, root and append) to the hypervisor and kernel. When ELILO is loaded during the boot sequence, the image is labeled linux.
ELILO は read-only をカーネルコマンドラインオプションの ro と解釈して、ルートファイルシステムが読み込み専用としてマウントされる要因となります。この状態は initscripts がルート ドライブを読み込み/書き込みとしてマウントするまで継続します。ELILO は "root" 行を カーネルコマンドラインにコピーします。これらは "append" 行とマージされて、以下の ような 完全なコマンド行を構成します:
"-- root=/dev/VolGroup00/rhel5_2 ro rhgb quiet"
-- シンボルは、hypervisor とカーネルの引数に 区切りを付けます。hypervisor 引数が最初に来て、それから -- デリミタで、 その後、カーネル引数が来ます。hypervisor は通常引数を取りません。

技術メモ

ELILO は全コマンド行を hypervisor に渡します。hypervisor はそのコンテンツを 分割して、カーネルオプションをカーネルに渡します。
hypervisor をカスタマイズするには、-- の前にパラメータを 挿入します。hypervisor メモリー (mem) パラメータと カーネル用の quiet パラメータのサンプルを以下に示します:
append="dom0_mem=2G -- quiet"
ELILO hypervisor のパラメータ
パラメータ説明
mem=mem パラメータは hypervisor の最大 RAM 使用を定義 します。システム内の追加の RAM はいずれも無視されます。このパラメータは、B, K, M あるいは G の 接尾辞で指定でき、それぞれバイト、キロバイト、メガバイト、ギガバイトを 示します。接尾辞がない場合、デフォルトの単位はキロバイトです。
dom0_mem=dom0_mem= は dom0 に割り当てる RAM のサイズをセットします。 上記の mem パラメータと同じ接尾辞が通用します。Itanium® 上での Red Hat Enterprise Linux 5.2 のデフォルトは 4G です。
dom0_max_vcpus=dom0_max_vcpus= は、hypervisor に割り当てる CPU の 数量をセットします。Itanium® 上での Red Hat Enterprise Linux 5.2 のデフォルトは 4 です。
com1=<baud>,DPS,<io_base>,<irq>com1= は最初のシリアル行の為のパラメータをセットします。 例えば、com1=9600,8n1,0x408,5io_baseirq のオプションは無視して標準のデフォルトで結構です。baud パラメータは auto にセットしてブートローダ設定がそのまま保持 されるようにします。ELILO 内か、EFI 設定内でグローバルシリアルオプションとしてシリアルパラメータが セットされている場合は、com1 パラメータは無視できます。
com2=<baud>,DPS,<io_base>,<irq>2つめのシリアル行にパラメータをセットします。上述の com1 パラメータの説明を参照して下さい。
console=<specifier_list>console はコンソールオプション用のコンマで区切られた 個人設定一覧です。オプションには、vga、com1 、及び com2 が含まれます。hypervisor が EFI コンソール設定の継承を試みるため、この設定は除外されるべきです。

ELILO パラメータについての詳細には

ELILO パラメータの完全リストは XenSource で取得できます。
上記の修正済み設定のサンプルは、メモリーと cpu 割り当てのパラメータを hypervisor に 追加する為の構文を示しています:
image=vmlinuz-2.6.18-92.el5xen
        vmm=xen.gz-2.6.18-92.el5
        label=linux
        initrd=initrd-2.6.18-92.el5xen.img
        read-only
        root=/dev/VolGroup00/rhel5_2
        append="dom0_mem=2G dom0_max_vcpus=2 --"
更には、このサンプルでは、カーネルパラメータ "rhgb quiet" を削除して、カーネルと initscript の出力がコンソールで 生成されるようにしています。append 行が hypervisor 引数として正しく解釈されるように 2つのダッシュは保持されることに注意して下さい。

第30章 libvirt configuration reference

This chapter provides is a references for various parameters of libvirt XML configuration files
表30.1 libvirt configuration files
Item Description
pae
Specifies the physical address extension configuration data.
apic
Specifies the advanced programmable interrupt controller configuration data.
memory
Specifies the memory size in megabytes.
vcpus
Specifies the numbers of virtual CPUs.
console
Specifies the port numbers to export the domain consoles to.
nic
Specifies the number of virtual network interfaces.
vif
Lists the randomly-assigned MAC addresses and bridges assigned to use for the domain's network addresses.
disk
Lists the block devices to export to the domain and exports physical devices to domain with read only access.
dhcp
Enables networking using DHCP.
netmask
Specifies the configured IP netmasks.
gateway
Specifies the configured IP gateways.
acpi
Specifies the advanced configuration power interface configuration data.

第31章 Xen 設定ファイル

Red Hat Enterprise Linux uses libvirt configuration files for most tasks. Some users may need Xen configuration files which contain the following standard variables. Configuration items within these files must be enclosed in single quotes('). These configuration files reside in the /etc/xen directory.
The table below, 表31.1「Xen 設定ファイルの参照」, is formatted output from xm create --help_config.
表31.1 Xen 設定ファイルの参照
Parameter
Description
vncpasswd=NAME HVM ドメインにある VNC コンソール用のパスワード
vncviewer=no | yes ドメイン内の vnc サーバーの為の vncviewer リスニングを引き起こします。 vncviewer のアドレスは、VNC_SERVER=<host>:<port> を 使用してカーネルコマンド行上のドメインへ渡されます。vnc に使用されるポートは 5500 + DISPLAY です。 フリーポートを持つ表示値は可能であれば選択されます。vnc=1 の時にのみ有効です。
vncconsole=no | yes Spawn a vncviewer process for the domain's graphical console. Only valid when vnc=1.
name=NAME ドメイン名。特有のものにします。
bootloader=FILE ブートローダーへのパス
bootargs=NAME ブートローダーへのパスの引数
bootentry=NAME 破棄されました。ブートローダーを経由したブートへのエントリ。bootargs を使用
kernel=FILE カーネルイメージへのパス
ramdisk=FILE ramdisk へのパス
features=FEATURES ゲストカーネル内で有効にする機能
builder=FUNCTION ドメインをビルドするために使用する関数
memory=MEMORY MB 表示のドメインメモリー
maxmem=MEMORY MB 表示の最大ドメインメモリー
shadow_memory=MEMORY MB 表示のドメインシャドーメモリー
cpu=CPU VCPU0 を維持する CPU
cpus=CPUS ドメインを稼働する CPUS
pae=PAE HVM ドメインの PAE を有効化/無効化
acpi=ACPI HVM ドメインの ACPI を有効化/無効化
apic=APIC HVM ドメインの APIC を有効化/無効化
vcpus=VCPUs ドメイン内の仮想 CPUS の数
cpu_weight=WEIGHT Set the new domain's cpu weight. WEIGHT is a float that controls the domain's share of the cpu.
restart=onreboot | always | never ドメインが 終了時に再スタートすべきかどうかを決定するものです。 - onreboot= シャットダウンコード reboot を付けて終了時に再スタート - always = 常に終了時に再スタート、終了コードを無視。 - never = 終了時に再スタートしない、終了コードを無視。 これらはすべて破棄されました。代わりにon_poweroffon_reboot、及び on_crash を使います。
on_poweroff=destroy | restart | preserve | destroy Behavior when a domain exits with reason 'poweroff'. - destroy: the domain is cleaned up as normal; - restart: a new domain is started in place of the old one; - preserve: no clean-up is done until the domain is manually destroyed (using xm destroy, for example); - rename-restart: the old domain is not cleaned up, but is renamed and a new domain started in its place.
on_reboot=destroy | restart | preserve | destroy Behavior when a domain exits with reason 'reboot'. - destroy: the domain is cleaned up as normal; - restart: a new domain is started in place of the old one; - preserve: no clean-up is done until the domain is manually destroyed (using xm destroy, for example); - rename-restart: the old domain is not cleaned up, but is renamed and a new domain started in its place.
on_crash=destroy | restart | preserve | destroy Behavior when a domain exits with reason 'crash'. - destroy: the domain is cleaned up as normal; - restart: a new domain is started in place of the old one; - preserve: no clean-up is done until the domain is manually destroyed (using xm destroy, for example); - rename-restart: the old domain is not cleaned up, but is renamed and a new domain started in its place.
blkif=no | yes ドメインをブロックデバイスバックエンドにする
netif=no | yes ドメインをネットワークインターフェイスバックエンドにする
tpmif=no | yes ドメインを TPM インターフェイスバックエンドにする
disk=phy:DEV,VDEV,MODE[,DOM] ディスクデバイスをドメインに追加します。物理デバイスは DEV となり、ドメインに対して VDEV として現れます。MODEr の場合は、 読み込み専用で、 MODEw の場合は、読み込み/書き込みと なります。DOM が指定されると、それはディスクの為に使用するようにバックエンドドライバー ドメインを定義します。このオプションは複数のディスクを追加するために繰り返すことができます。
pci=BUS:DEV.FUNC 任意のパラメータ(16進法で)を使用して、ドメインに PCI デバイスを追加します。 例えば、pci=c0:02.1a。このオプションは、繰り返して 複数の PCI デバイスを追加することができます。
ioports=FROM[-TO] パラメータ(16進法で)使用してドメインにレガシー I/O の幅を追加します。 ioports=02f8-02ff。このオプションは、繰り返して 複数の I/O の幅を追加することができます。
irq=IRQ ドメインに IRQ(割り込みの行)を追加します。例えば、irq=7。このオプションは繰り返して複数の IRQ を追加することができます。
usbport=PATH そのポートへのパスで指定されている通りにドメインに物理 USB ポートを追加します。 このオプションは繰り返して複数のポートを追加することが出来ます。
vfb=type={vnc,sdl}, vncunused=1, vncdisplay=N,
vnclisten=ADDR, display=DISPLAY,
xauthority=XAUTHORITY, vncpasswd=PASSWORD,
keymap=KEYMAP
Make the domain a framebuffer backend. The backend type should be either sdl or vnc. For type=vnc, connect an external vncviewer. The server will listen on ADDR (default 127.0.0.1) on port N+5900. N defaults to the domain id. If vncunused=1, the server will try to find an arbitrary unused port above 5900. For type=sdl, a viewer will be started automatically using the given DISPLAY and XAUTHORITY, which default to the current user's ones.
vif=type=TYPE, mac=MAC, bridge=BRIDGE, ip=IPADDR,
script=SCRIPT, backend=DOM, vifname=NAME
該当する MAC アドレスとブリッジを使用してネットワーク インターフェイスを追加します。vif は該当する設定スクリプトを コールすることにより、設定されます。タイプが指定されていない場合は、デフォルトは netfront となり、 ioemu ではありません。MAC が指定されていない場合は、ランダムに MAC アドレスが使用されます。指定されていないと、ネットワークバックエンドはそれ自身の MAC アドレスを選択します。ブリッジが指定されていないと、最初に見付かったブリッジが使用されます。スクリプトが 指定されていないと、デフォルトのスクリプトが使用されます。バックエンドが指定されていないと、デフォルトの バックエンドドライバードメインが使用されます。vif 名が指定されていない場合は、バックエンドの仮想インターフェイスが vifD.N と言う名前を取り、この D はドメイン id であり、N がインターフェイスの id となります。このオプションは 複数の vif を追加する時に繰り返されます。vif を指定することにより、必要に応じてインターフェイスの数を増加できます。
vtpm=instance=INSTANCE,backend=DOM TPM インターフェイスを追加します。バックエンド側では、該当するインスタンスを 仮想 TPM インスタンスとして使用します。与えられた数値は単に好みのインスタンス番号です。 hotplug スクリプトはどのインスタンス番号が実際にドメインに割り当てられるかを決定します。 仮想マシンと TPM インスタンス番号は /etc/xen/vtpm.db 内で見る ことが出来ます。該当するドメインにはバックエンドを使用して下さい。
access_control=policy=POLICY,label=LABEL セキュリティラベルとそれを定義するセキュリティポリシー参照を追加します。 ローカルの ssid 参照は、ドメインが開始、又は復帰する時点に算出されます。この 時点で、ポリシーがアクティブなポリシーに対してチェックされます。このようにして、 「保存」又は「復元」の機能が処理されて、ローカルラベルはドメインが開始、又は 復帰するシステム上で自動的に正しく作成されます。
nics=NUM 破棄されています。代わりに空の vif エントリを使用します。ネットワークインターフェイスの 数を設定します。vif オプションを使用するとインターフェイスのパラメータを定義できます。 それ以外ではデフォルトが使用されます。vif を指定することにより必要に応じてインターフェイスの 数を増加できます。
root=DEVICE カーネルコマンド行に root= パラメータをセットします。 NFS root には、例えば、/dev/sda1/dev/nfs のようなデバイスを使用します。
extra=ARGS カーネルコマンド行に追記するために余分の引数をセットします。
ip=IPADDR カーネル IP インターフェイスアドレスをセットします。
gateway=IPADDR カーネル IP ゲートウェイをセットします。
netmask=MASK カーネル IP ネットマスクをセットします。
hostname=NAME カーネル IP ホスト名をセットします。
interface=INTF カーネル IP インターフェイス名をセットします。
dhcp=off|dhcp カーネル dhcp オプションをセットします。
nfs_server=IPADDR NFS root 用に NFS サーバーのアドレスをセットします。
nfs_root=PATH root NFS ディレクトリのパスをセットします。
device_model=FILE デバイスモデルプログラムへのパス
fda=FILE fda へのパス
fdb=FILE fdb へのパス
serial=FILE シリアルか、pty か vc へのパス
localtime=no | yes RTC がローカルタイムにセットされているかどうか
keymap=FILE 使用されるキーボードマップをセットします。
usb=no | yes USB デバイスを模倣します。
usbdevice=NAME 追加する USB デバイスの名前
stdvga=no | yes Use std vga or Cirrus Logic graphics
isa=no | yes ISA のみのシステムをシミュレートします
boot=a|b|c|d デフォルトのブートデバイス
nographic=no | yes デバイスモデルがグラフィックスを使用すべきか?
soundhw=audiodev デバイスモデルがオーディオデバイスを有効にすべきか?
vnc デバイスモデルが VNC を使用すべきか?
vncdisplay 使用する VNC 表示
vnclisten リッスンする VNC サーバー用のアドレス
vncunused VNC サーバーには未使用のポートを見つけるようにします。vnc=1 の時にのみ有効。
sdl デバイスモデルが SDL を使用すべきか?
display=DISPLAY 使用する X11 ディスプレイ
xauthority=XAUTHORITY 使用する X11 権限
uuid 使用する xenstore UUID (universally unique identifier) です。このオプションが セットされていないと、ランダムに1つ生成されます。仮想ネットワークインターフェイス用の MAC アドレスと同様です。これはクラスター全域に渡って特有である必要があります。

表31.3「設定パラメータのデフォルト値」 lists all configuration parameters available, the Python parser function which sets the value and default values. The setter function gives an idea of what the parser does with the values you specify. It reads these as Python values, then feeds them to a setter function to store them. If the value is not valid Python, you get an obscure error message. If the setter rejects your value, you should get a reasonable error message, except it appears to get lost somehow, along with your bogus setting. If the setter accepts, but the value is incorrect the application may fail.
表31.2 パラメータ値をセットする Python 関数
パーサー関数 有効な引数
set_bool
受理される値:
  • yes
  • y
  • no
  • yes
set_float
Accepts a floating point number with Python's float(). For example:
  • 3.14
  • 10.
  • .001
  • 1e100
  • 3.14e-10
set_int
Accepts an integer with Python's int().
set_value
いずれの Python 値も受理します。
append_value
いずれの Python 値も受理して、アレイに格納されている以前の値に追記します。

表31.3 設定パラメータのデフォルト値
Parameter パーサー関数 デフォルト値
name setter default value
vncpasswd set_value None
vncviewer set_bool None
vncconsole set_bool None
name set_value None
bootloader set_value None
bootargs set_value None
bootentry set_value None
kernel set_value None
ramdisk set_value ''
features set_value ''
builder set_value 'linux'
memory set_int 128
maxmem set_int None
shadow_memory set_int 0
cpu set_int None
cpus set_value None
pae set_int 0
acpi set_int 0
apic set_int 0
vcpus set_int 1
cpu_weight set_float None
restart set_value None
on_poweroff set_value None
on_reboot set_value None
on_crash set_value None
blkif set_bool 0
netif set_bool 0
tpmif append_value 0
disk append_value []
pci append_value []
ioports append_value []
irq append_value []
usbport append_value []
vfb append_value []
vif append_value []
vtpm append_value []
access_control append_value []
nics set_int -1
root set_value ''
extra set_value ''
ip set_value ''
gateway set_value ''
netmask set_value ''
hostname set_value ''
interface set_value "eth0"
dhcp set_value 'off'
nfs_server set_value None
nfs_root set_value None
device_model set_value ''
fda set_value ''
fdb set_value ''
serial set_value ''
localtime set_bool 0
keymap set_value ''
usb set_bool 0
usbdevice set_value ''
stdvga set_bool 0
isa set_bool 0
boot set_value 'c'
nographic set_bool 0
soundhw set_value ''
vnc set_value None
vncdisplay set_value None
vnclisten set_value None
vncunused set_bool 1
sdl set_value None
display set_value None
xauthority set_value None
uuid set_value None

パート VII. ヒントと裏技

第32章 ヒントと裏技

この章には仮想化のパフォーマンス、拡張性、及び安定性を改善する為の 役に立つヒントと裏技が含まれています。

32.1. 自動的にゲストを開始

This section covers how to make virtualized guests start automatically during the host system's boot phase.
ここにある例は、ゲストの開始に virsh を使用して、 TestServer を 介してホストがブートする時点に自動的にスタートします。
# virsh autostart TestServer
Domain TestServer marked as autostarted
これでゲストはホストと一緒に自動的にスタートします。
ゲストの自動ブートを停止するには、--disable パラメータを使用します。
# virsh autostart --disable TestServer
Domain TestServer unmarked as autostarted
もうゲストは自動的にホストと一緒にスタートしません。

32.2. KVM と Xen hypervisor との間での切り替え

このセクションは、KVM と Xen hypervisor 間での切り替えについて説明します。
Red Hat は一度に一つのみのアクティブ hypervisor をサポートします。

hypervisor 間での仮想ゲストの移行

現時点では、Xen ベースのゲストを KVM へ切り替えたり、又は KVM ベースの ゲストを Xen に切り替えたりするアプリケーションは有りません。ゲストはそれが 作成されたタイプの hypervisor でしか使用できません。

警告

この手順は Red Hat Enterprise Linux 5.4 又はそれ以降の Intel 64 又は AMD64 の バージョンにのみ利用可能です。他の構成や Red Hat Enterprise Linux の他のバージョンは サポートされていません。KVM は Red Hat Enterprise Linux 5.4 以前のバージョンでは 利用できません。

32.2.1. Xen から KVM へ

以下の手順は Xen hypervisor から KVM hypervisor への変更を説明しています。この 手順は kernel-xen パッケージがインストールしてあり、有効に なっていることを想定しています。
  1. KVM パッケージをインストール

    まだ kvm パッケージをインストールしていない場合、インストールします。
    # yum install kvm
    
  2. どのカーネルが使用中かを確認

    kernel-xen パッケージがインストールされている可能性があります。 uname コマンドを使用して、どのカーネルが稼働しているか判定します:
    $ uname -r
    2.6.18-159.el5xen
    
    現在、カーネル "2.6.18-159.el5xen" がシステムで稼働中です。 デフォルトカーネル、"2.6.18-159.el5" が稼働している場合は、 このサブステップは無視できます。
    1. Xen カーネルをデフォルトカーネルに変更

      grub.conf ファイルはどのカーネルがブートされるかを決定します。 デフォルトのカーネルを変更するには、/boot/grub/grub.conf ファイルを以下のように編集します。
      								default=1
      timeout=5
      splashimage=(hd0,0)/grub/splash.xpm.gz
      hiddenmenu
      title Red Hat Enterprise Linux Server (2.6.18-159.el5)
              root (hd0,0)
              kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              initrd /initrd-2.6.18-159.el5.img
      title Red Hat Enterprise Linux Server (2.6.18-159.el5xen)
              root (hd0,0)
              kernel /xen.gz-2.6.18-159.el5
              module /vmlinuz-2.6.18-159.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              module /initrd-2.6.18-159.el5xen.img
      
      default=1 パラメータを見てください。 これは GRUB ブートローダーに対して2つめのエントリである Xen カーネルをブートするように 指示しています。デフォルトを 0 (又は、デフォルトカーネルの番号)に 変更します。
      								default=0
      timeout=5
      splashimage=(hd0,0)/grub/splash.xpm.gz
      hiddenmenu
      title Red Hat Enterprise Linux Server (2.6.18-159.el5)
              root (hd0,0)
              kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              initrd /initrd-2.6.18-159.el5.img
      title Red Hat Enterprise Linux Server (2.6.18-159.el5xen)
              root (hd0,0)
              kernel /xen.gz-2.6.18-159.el5
              module /vmlinuz-2.6.18-159.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              module /initrd-2.6.18-159.el5xen.img
      
  3. 再起動して新しいカーネルをロードします。

    システムを再起動します。コンピュータはデフォルトのカーネルで再スタートします。 KVM モジュールは、カーネルで自動的にロードされるはずです。KVM が稼働していることを 確認します:
    $ lsmod | grep kvm
    kvm_intel              85992  1 
    kvm                   222368  2 ksm,kvm_intel
    
    もし全てが正常に機能していれば、kvm モジュールと、 kvm_intel モジュール、あるいは kvm_amd モジュールが存在するはずです。

32.2.2. KVM から Xen へ

以下の手順は KVM hypervisor から Xen hypervisor への変更を説明しています。この 手順は kvm パッケージがインストールしてあり、有効になって いることを想定しています。
  1. Xen パッケージをインストール

    まだ、kernel-xenxen の パッケージをインストールしていない場合はインストールします。
    # yum install kernel-xen xen
    
    kernel-xen パッケージはインストールされていて、無効に なっている可能性があります。
  2. どのカーネルが使用中かを確認

    uname コマンドを使用すると、どのカーネルが実行中であるか 判定できます。
    $ uname -r
    2.6.18-159.el5
    
    現在のカーネル "2.6.18-159.el5" はシステム上で実行中です。 これがデフォルトのカーネルです。カーネルがその末尾に xen を 持つ場合(例えば、2.6.18-159.el5xen)、Xen カーネルが 実行中であるため、このサブステップは無視しても結構です。
    1. デフォルトカーネルから Xen カーネルへ変更

      grub.conf ファイルはどのカーネルがブートされるかを決定します。 デフォルトのカーネルを変更するには、/boot/grub/grub.conf ファイルを以下のように編集します。
      								default=0
      timeout=5
      splashimage=(hd0,0)/grub/splash.xpm.gz
      hiddenmenu
      title Red Hat Enterprise Linux Server (2.6.18-159.el5)
              root (hd0,0)
              kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              initrd /initrd-2.6.18-159.el5.img
      title Red Hat Enterprise Linux Server (2.6.18-159.el5xen)
              root (hd0,0)
              kernel /xen.gz-2.6.18-159.el5
              module /vmlinuz-2.6.18-159.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              module /initrd-2.6.18-159.el5xen.img
      
      default=0 パラメータに注意して下さい。 これは、GRUB ブートローダに対して最初のエントリ(デフォルトカーネル)をブート するように指示しています。デフォルトを 1 (又は Xen カーネルの番号)に変更します:
      								default=1
      timeout=5
      splashimage=(hd0,0)/grub/splash.xpm.gz
      hiddenmenu
      title Red Hat Enterprise Linux Server (2.6.18-159.el5)
              root (hd0,0)
              kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              initrd /initrd-2.6.18-159.el5.img
      title Red Hat Enterprise Linux Server (2.6.18-159.el5xen)
              root (hd0,0)
              kernel /xen.gz-2.6.18-159.el5
              module /vmlinuz-2.6.18-159.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              module /initrd-2.6.18-159.el5xen.img
      
  3. 再起動して新しいカーネルをロードします。

    システムを再起動します。コンピュータは Xen カーネルで再スタートするでしょう。 uname コマンドを使用して確認します:
    $ uname -r
    2.6.18-159.el5xen
    
    出力が末尾に xen を示すなら、Xen カーネルが稼働しています。

32.3. qemu-img の使用

qemu-img コマンドラインツールは、Xen と KVM で使用している 各種ファイルシステムのフォーマットに使用されます。qemu-img は 仮想化ゲストイメージ、追加のストレージデバイス、及びネットワークストレージのフォーマットに 使用されるものです。qemu-img のオプションと使用法は以下の一覧に 示されています。
新規イメージ、又はデバイスのフォーマットと作成
サイズ size と形式 format の 新しいディスクイメージファイル名を作成します。
# qemu-img create [-6] [-e] [-b base_image] [-f format] filename [size]
base_image が指定されている場合、そのイメージは base_image との相違のみを 記録します。この場合、サイズは指定する必要はありません。base_image は、 "commit" と言うモニターコマンドを使用しない限りは、修正しません。
既存のイメージを別の形式に変換
認識されている形式を別のイメージ形式に変換するのには、convert オプションが使用されます。
コマンドの形式:
# qemu-img convert [-c] [-e] [-f format] filename [-O output_format] output_filename
フォーマット output_format を使用して、ディスクイメージ filename を ディスクイメージ output_filename に 変換します。ディスクイメージは -e オプションを使用して暗号化したり、 -c オプションで圧縮したりできます。
"qcow" フォーマットのみが暗号化、又は圧縮をサポートします。 圧縮は読み込み専用です。このことは圧縮したセクターが再書き込みされると、それは 圧縮無しのデータとして再書き込みされると言う意味です。
暗号化は非常に安全な 128-bit キーを持つ AES 形式を使用します。長いパスワード (16文字以上)の使用で最大の保護を得ることができます。
イメージ変換も、qcow 又は cow などの 増大する形式を使用する時には小さいイメージを取得するのに役立ちます。空のセクターは検知されて 目的地イメージから抑圧されます。
イメージ情報の取得
info パラメータはディスクイメージに関する情報を 表示します。info オプション用の形式は以下のようになります:
# qemu-img info [-f format] filename
これはディスクイメージのファイル名に関する情報を与えます。特に表示されたサイズとは 異なる可能性のあるディスク上で保存されたサイズを知る目的で使用します。vm スナップショットが ディスクイメージに格納されている場合は、それらも表示されます。
サポートされている形式
イメージのフォーマットは通常、自動的に行われます。以下のフォーマットが サポートされています:
raw
Raw ディスクイメージフォーマット(デフォルト)。このフォーマットは単純で、全ての 他のエミュレータに簡単にエキスポートできます。ユーザーのファイルシステムが holes(例えば、Linux での ext2 や ext3 で、Windows での NTFS で)をサポートしていれば、 書き込まれたセクターのみがスペースを保存します。qemu-img info を使用して、イメージ又は Unix/Linux 上で ls -ls で使用されている本当のサイズを知ることができます。
qcow2
QEMU イメージフォーマットは最も柔軟性のあるフォーマットです。より小さなイメージ (例えば Windows で使用フィルシステムが holes をサポートしない場合)、オプションの AES 暗号化、zlib ベースの圧縮、及び 複数 VM スナップショットのサポートなどを得るのに 使用します。
qcow
旧来の QEMU イメージフォーマットです。古いバージョンとの互換性の為にのみ含まれています。
cow
ユーザーモード Linux Copy On Write イメージフォーマットです。cow フォーマットは以前のバージョンとの互換性の為にのみ含まれています。Windows では機能しません。
vmdk
VMware 3 と 4 の互換イメージフォーマットです。
cloop
Linux 圧縮ループイメージは、例として Knoppix CD-ROM などに収納されている 直接圧縮 CD-ROM を再利用する時にのみ役に立ちます。

32.4. Overcommitting Resources

The KVM hypervisor supports overcommitting CPUs and memory. Overcommitting is the process of allocating more virtualized CPUs or memory than there are physical resources on the system. CPU overcommit allows under-utilized virtualized servers or desktops to run on fewer servers which saves power and money.

Xen サポート

Memory overcommitting is not supported for the Xen hypervisor, however CPU overcommitting is supported.
メモリーのオーバーコミット
ほとんどのオペレーティングシステムとアプリケーションは利用可能な RAM を常に 100% 使用することはありません。この状況を KVM で活用して使用物理メモリー 以上の仮想メモリーを仮想化ゲスト用に使用することが出来ます。
When using KVM, virtual machines operate as Linux processes. Guests on the KVM hypervisor do not have blocks of physical RAM assigned to them, instead they function as processes. Each process in a Linux system is allocated memory when it requests more memory. In a similar way, KVM allocates memory for guests when the guest requests more or less memory. The guest only uses slightly more physical memory than the virtualized operating system appears to use.
When physical memory is nearly completely used or a process is inactive for some time, Linux moves the process's memory to swap. Swap is usually a partition on a hard disk drive or solid state drive which Linux uses to extend virtual memory. Swap is significantly slower than RAM.
As KVM virtual machines are Linux processes, memory used by virtualized guests can be put into swap if the guest is idle or not in heavy use. Memory can be committed over the total size of the swap and physical RAM. This can cause issues if virtualized guests use their total RAM. Without sufficient memory and swap space for the virtual machine processes, the system can run completely out of memory, leading to the failure of one or more virtual machine processes.

警告

十分なスワップが使用できない場合は、ゲストオペレーティングシステムは 強制的にシャットダウンされます。これによりゲストは運用不能になります。 これを回避するには、決して使用可能なスワップ以上のメモリーをオーバーコミット しないことです。
スワップパーティションは、メモリーのパフォーマンスを高速化するために低使用の メモリーをハードドライブにスワップするために使用します。スワップパーティションの デフォルトサイズは RAM のサイズとオーバーコミット率から算出されます。KVM を 使用してメモリーをオーバーコミットする計画があれば、スワップパーティションは 大きめにすることが推奨されます。推薦オーバーコミット率は 50% (0.5) です。 その数式は以下のようになります:
(0.5 * RAM) + (overcommit ratio * RAM) = Recommended swap size
Red Hat Knowledgebase はスワップパーティションのサイズを決定する 安全性と効率についての記事を収納しています。
Overcommitting guests by swapping out temporarily unused guest memory can be very slow, due to the IO latency introduced by disk seek times. However, Red Hat Enterprise Linux virtualization with KVM can often avoid this disk IO penalty by merging multiple pages with identical content into the same physical pages. This is done by the KSM (Kernel Samepage Merging) kernel process, which scans memory to find identical pages. The KSM kernel process uses CPU time to avoid disk IO. This tradeoff is often beneficial in workloads with many smaller, similar guests.
システム内の物理 RAM サイズに対して仮想化ゲスト数の10倍のオーバーコミット率で 稼働することも可能です。これは特定のアプリケーション負荷状況でのみ機能できます (例えば、100% 以下の使用率のデスクトップ仮想化)。オーバーコミット率をセット することは厳格な数式ではありません。ご使用の環境に応じた率をテストしてカスタマイズ する必要があります。
仮想化 CPU のオーバーコミット
KVM hypervisor は仮想化 CPU のオーバーコミットをサポートします。仮想化 CPU は 仮想化ゲストが許容する負荷限度までオーバーコミットが可能です。但し、100% 近くの負荷は 要求の未処理や、使用に適しない反応時間の原因になるため、VCPU のオーバーコミットには 注意が必要です。
仮想化 CPU は、仮想化ゲストが1つの VCPU のみを持つ時に最善のオーバーコミットと なります。Linux スケジューラはこのタイプの負荷で非常に効率良くなります。KVM は 5 VCPU の率で 100% 以下の負荷を持つゲストを安全にサポートするはずです。
対称型のマルチプロセッシングゲストは物理プロセッシングコアの数以上にオーバーコミット することは出来ません。例えば、4 VCPU を持つゲストは、デュアルコアプロセッサを持つ ホスト上では実行すべきではありません。物理プロセッシングコアの数に対して対称型 マルチプロセッシングゲストをオーバーコミットすると、深刻なパフォーマンス低下の 原因になります。
ゲスト VCPU を物理コアの数まで割り当てることが適切であり、それが期待どおりに 動作します。例えば、4 VCPU を持つ仮想化ゲストを4連コアのホストで実行することです。 100% 以下の負荷を持つゲストはこのセットアップで効率的に機能するはずです。

常に最初にテスト

徹底的なテスト無しでは、実稼働環境でのメモリーと CPU のオーバーコミットはしないで 下さい。100% のメモリーやプロセッシングリソースを使用するアプリケーションは オーバーコミット環境では使用不能になる可能性があります。導入する前にテストを 実行すべきです。

32.5. /etc/grub.conf の修正

This section describes how to safely and correctly change your /etc/grub.conf file to use the virtualization kernel. You must use the xen kernel to use the Xen hypervisor. Copy your existing xen kernel entry make sure you copy all of the important lines or your system will panic upon boot (initrd will have a length of '0'). If you require xen hypervisor specific values you must append them to the xen line of your grub entry.
以下の出力は、kernel-xen パッケージを実行しているシステムからの grub.conf エントリの例です。個人のシステムの grub.conf は 異なるでしょう。以下の例の重要な部分は title 行から次の新しい行のセクションです。
#boot=/dev/sda
default=0
timeout=15
#splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console

title Red Hat Enterprise Linux Server (2.6.17-1.2519.4.21.el5xen)
	root (hd0,0)
	kernel /xen.gz-2.6.17-1.2519.4.21.el5 com1=115200,8n1
	module /vmlinuz-2.6.17-1.2519.4.21.el5xen ro root=/dev/VolGroup00/LogVol00
	module /initrd-2.6.17-1.2519.4.21.el5xen.img

grub.conf の編集に関する重要点

Your grub.conf could look very different if it has been manually edited before or copied from an example. Read 28章Xen カーネルブートパラメータの設定 for more information on using virtualization and grub.
起動時にホストシステムに割り当てるメモリーの量を 256MB にセットするには、 grub.confxen 行に dom0_mem=256M を追記する必要があります。 以前の例の中の grub 設定ファイルの変更バージョンは以下のようになります:
#boot=/dev/sda
default=0
timeout=15
#splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console

title Red Hat Enterprise Linux Server (2.6.17-1.2519.4.21.el5xen)
	root (hd0,0)
	kernel /xen.gz-2.6.17-1.2519.4.21.el5 com1=115200,8n1 dom0_mem=256MB
	module /vmlinuz-2.6.17-1.2519.4.21.el5xen ro
	root=/dev/VolGroup00/LogVol00
	module /initrd-2.6.17-1.2519.4.21.el5xen.img

32.6. 仮想化拡張を確認

このセクションを活用してユーザーのシステムがハードウェア仮想化拡張を持つかどうか 判定して下さい。仮想化拡張 (Intel VT 又は AMD-V) は完全仮想化で必須項目です。

仮想化拡張が無い状態で仮想化が使用できますか?

ハードウェア仮想化拡張が存在しなければ、Red Hat kernel-xen パッケージを使用して Xen para-virtualization を利用することができます。
  1. 以下のコマンドを実行すると、CPU 仮想化拡張が利用可能であることを確認 できます:
    $ grep -E 'svm|vmx' /proc/cpuinfo
    
  2. Analyze the output.
    • 以下の出力は vmx エントリを含んでおり、 Intel VT 拡張を持つ Intel プロセッサを示しています:
      flags   : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush 
      	dts acpi mmx fxsr sse sse2 ss ht  tm syscall lm constant_tsc pni monitor ds_cpl
      	vmx est tm2 cx16 xtpr lahf_lm
      
    • 以下の出力は svm エントリを含んでおり、 AMD-V 拡張を持つ AMD プロセッサを示しています:
      flags   :  fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush
      	mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni cx16
      	lahf_lm cmp_legacy svm cr8legacy ts fid vid ttp tm stc
      
    If any output is received, the processor has the hardware virtualization extensions. However in some circumstances manufacturers disable the virtualization extensions in BIOS.
    "flags:" の内容は、システム上の各ハイパースレッド、コア、 又は CPU の複数倍として表ることがあります。
    The virtualization extensions may be disabled in the BIOS. If the extensions do not appear or full virtualization does not work refer to 手順35.1「BIOS 内で仮想化拡張を有効にする」.
  3. For users of the KVM hypervisor

    If the kvm package is installed. I As an additional check, verify that the kvm modules are loaded in the kernel:
    # lsmod | grep kvm
    
    If the output includes kvm_intel or kvm_amd then the kvm hardware virtualization modules are loaded and your system meets requirements. sudo

Additional output

If the libvirt package is installed, the virsh command can output a full list of virtualization system capabilities. Run virsh capabilities as root to receive the complete list.

32.7. Accessing data from a guest disk image

There are various methods for accessing the data from guest image files. One common method is to use the kpartx tool, covered by this section, to mount the guest file system as a loop device which can then be accessed.
The kpartx command creates device maps from partition tables. Each guest storage image has a partition table embedded in the file.
The libguestfs and guestfish packages, available from the EPEL repository, allow advanced modification and access to guest file systems. The libguestfs and guestfish packages are not covered in this section at this time.

警告

Guests must be offline before their files can be read. Editing or reading files of an active guest is not possible and may cause data loss or damage.
手順32.1 Accessing guest image data
  1. Install the kpartx package.
    # yum install kpartx
    
  2. Use kpartx to list partition device mappings attached to a file-based storage image. This example uses a image file named guest1.img.
    # kpartx -l /var/lib/libvirt/images/guest1.img
    loop0p1 : 0 409600 /dev/loop0 63
    loop0p2 : 0 10064717 /dev/loop0 409663
    guest1 is a Linux guest. The first partition is the boot partition and the second partition is an EXT3 containing the root partition.
  3. Add the partition mappings to the recognized devices in /dev/mapper/.
    # kpartx -a /var/lib/libvirt/images/guest1.img
    
    1. Test that the partition mapping worked. There should be new devices in the /dev/mapper/ directory
      # ls /dev/mapper/
      loop0p1
      loop0p2
      
      The mappings for the image are named in the format loopXpY.
  4. Mount the loop device which to a directory. If required, create the directory. This example uses /mnt/guest1 for mounting the partition.
    # mkdir /mnt/guest1
    # mount /dev/mapper/loop0p1 /mnt/guest1 -o loop,ro
  5. The files are now available for reading in the /mnt/guest1 directory. Read or copy the files.
  6. Unmount the device so the guest image can be reused by the guest. If the device is mounted the guest cannot access the image and therefore cannot start.
    # umount /mnt/tmp
  7. Disconnect the image file from the partition mappings.
    # kpartx -d /var/lib/libvirt/images/guest1.img
    
The guest can now be started again.
Accessing data from guest LVM volumes
Many Linux guests use Logical Volume Management (LVM) volumes. Additional steps are required to read data on LVM volumes on virtual storage images.
  1. Add the partition mappings for the guest1.img to the recognized devices in the /dev/mapper/ directory.
    # kpartx -a /var/lib/libvirt/images/guest1.img
    
  2. In this example the LVM volumes are on a second partition. The volumes require a rescan with the vgscan command to find the new volume groups.
    # vgscan
    Reading all physical volumes . This may take a while...
    Found volume group "VolGroup00" using metadata type lvm2
  3. Activate the volume group on the partition (called VolGroup00 by default) with the vgchange -ay command.
    # vgchange -ay VolGroup00
    2 logical volumes in volume group VolGroup00 now active.
  4. Use the lvs command to display information about the new volumes. The volume names (the LV column) are required to mount the volumes.
    # lvs
    LV VG Attr Lsize Origin Snap% Move Log Copy%
    LogVol00 VolGroup00 -wi-a- 5.06G
    LogVol01 VolGroup00 -wi-a- 800.00M
  5. Mount /dev/VolGroup00/LogVol00 in the /mnt/guestboot/ directory.
    # mount /dev/VolGroup00/LogVol00 /mnt/guestboot
  6. The files are now available for reading in the /mnt/guestboot directory. Read or copy the files.
  7. Unmount the device so the guest image can be reused by the guest. If the device is mounted the guest cannot access the image and therefore cannot start.
    # umount /mnt/
  8. Disconnect the volume group VolGroup00
    # vgchange -an VolGroup00
    
  9. Disconnect the image file from the partition mappings.
    # kpartx -d /var/lib/libvirt/images/guest1.img
    
The guest can now be restarted.

32.8. Setting KVM processor affinities

This section covers setting processor and processing core affinities with libvirt for KVM guests.
By default, libvirt provisions guests using the hypervisor's default policy. For most hypervisors, the policy is to run guests on any available processing core or CPU. There are times when an explicit policy may be better, in particular for systems with a NUMA (Non-Uniform Memory Access) architecture. A guest on a NUMA system should be pinned to a processing core so that its memory allocations are always local to the node it is running on. This avoids cross-node memory transports which have less bandwidth and can significantly degrade performance.
On a non-NUMA systems some form of explicit placement across the hosts’ sockets, cores and hyperthreads may be more efficient.
Identifying CPU and NUMA topology
The first step in deciding what policy to apply is to determine the host’s memory and CPU topology. The virsh nodeinfo command provides information about how many sockets, cores and hyperthreads there are attached a host.
# virsh nodeinfo
CPU model:           x86_64
CPU(s):              8
CPU frequency:       1000 MHz
CPU socket(s):       2
Core(s) per socket:  4
Thread(s) per core:  1
NUMA cell(s):        1
Memory size:         8179176 kB
This system has eight CPUs, in two sockets, each processor has four cores.
The output shows that that the system has a NUMA architecture. NUMA is more complex and requires more data to accurately interpret. Use the virsh capabilities to get additional output data on the CPU configuration.
# virsh capabilities
<capabilities>
  <host>
    <cpu>
      <arch>x86_64</arch>
    </cpu>
    <migration_features>
      <live/>
      <uri_transports>
        <uri_transport>tcp</uri_transport>
      </uri_transports>
    </migration_features>
    <topology>
      <cells num='2'>
        <cell id='0'>
          <cpus num='4'>
            <cpu id='0'/>
            <cpu id='1'/>
            <cpu id='2'/>
            <cpu id='3'/>
          </cpus>
        </cell>
        <cell id='1'>
          <cpus num='4'>
            <cpu id='4'/>
            <cpu id='5'/>
            <cpu id='6'/>
            <cpu id='7'/>
          </cpus>
        </cell>
      </cells>
    </topology>
    <secmodel>
      <model>selinux</model>
      <doi>0</doi>
    </secmodel>
  </host>

 [ Additional XML removed ]

</capabilities>
The output shows two NUMA nodes (also know as NUMA cells), each containing four logical CPUs (four processing cores). This system has two sockets, therefore we can infer that each socket is a separate NUMA node. For a guest with four virtual CPUs, it would be optimal to lock the guest to physical CPUs 0 to 3, or 4 to 7 to avoid accessing non-local memory, which are significantly slower than accessing local memory.
If a guest requires eight virtual CPUs, as each NUMA node only has four physical CPUs, a better utilization may be obtained by running a pair of four virtual CPU guests and splitting the work between them, rather than using a single 8 CPU guest. Running across multiple NUMA nodes significantly degrades performance for physical and virtualized tasks.
Decide which NUMA node can run the guest
Locking a guest to a particular NUMA node offers no benefit if that node does not have sufficient free memory for that guest. libvirt stores information on the free memory available on each node. Use the virsh freecell command to display the free memory on all NUMA nodes.
# virsh freecell
0: 2203620 kB
1: 3354784 kB
If a guest requires 3 GB of RAM allocated, then the guest should be run on NUMA node (cell) 1. Node 0 only has 2.2GB free which is probably not sufficient for certain guests.
Lock a guest to a NUMA node or physical CPU set
Once you have determined which node to run the guest on, refer to the capabilities data (the output of the virsh capabilities command) about NUMA topology.
  1. Extract from the virsh capabilities output.
    <topology>
      <cells num='2'>
        <cell id='0'>
        <cpus num='4'>
          <cpu id='0'/>
          <cpu id='1'/>
          <cpu id='2'/>
          <cpu id='3'/>
        </cpus>
      </cell>
      <cell id='1'>
        <cpus num='4'>
          <cpu id='4'/>
          <cpu id='5'/>
          <cpu id='6'/>
          <cpu id='7'/>
        </cpus>
      </cell>
      </cells>
    </topology>
  2. Observe that the node 1, <cell id='1'>, has physical CPUs 4 to 7.
  3. The guest can be locked to a set of CPUs by appending the cpuset attribute to the configuration file.
    1. While the guest is offline, open the configuration file with virsh edit.
    2. Locate where the guest's virtual CPU count is specified. Find the vcpus element.
      <vcpus>4</vcpus>
      The guest in this example has four CPUs.
    3. Add a cpuset attribute with the CPU numbers for the relevant NUMA cell.
      <vcpus cpuset='4-7'>4</vcpus>
  4. Save the configuration file and restart the guest.
The guest has been locked to CPUs 4 to 7.
Automatically locking guests to CPUs with virt-install
The virt-install provisioning tool provides a simple way to automatically apply a 'best fit' NUMA policy when guests are created.
The cpuset option for virt-install can use a CPU set of processors or the parameter auto. The auto parameter automatically determines the optimal CPU locking using the available NUMA data.
For a NUMA system, use the --cpuset=auto with the virt-install command when creating new guests.
Tuning CPU affinity on running guests
There may be times where modifying CPU affinities on running guests is preferable to rebooting the guest. The virsh vcpuinfo and virsh vcpupin commands can perform CPU affinity changes on running guests.
The virsh vcpuinfo command gives up to date information about where each virtual CPU is running.
In this example, guest1 is a guest with four virtual CPUs is running on a KVM host.
# virsh vcpuinfo guest1
VCPU:           0
CPU:            3
State:          running
CPU time:       0.5s
CPU Affinity:   yyyyyyyy
VCPU:           1
CPU:            1
State:          running
CPU Affinity:   yyyyyyyy
VCPU:           2
CPU:            1
State:          running
CPU Affinity:   yyyyyyyy
VCPU:           3
CPU:            2
State:          running
CPU Affinity:   yyyyyyyy
The virsh vcpuinfo output (the yyyyyyyy value of CPU Affinity) shows that the guest can presently run on any CPU.
To lock the virtual CPUs to the second NUMA node (CPUs four to seven), run the following commands.
# virsh vcpupin guest1 0 4
# virsh vcpupin guest1 1 5
# virsh vcpupin guest1 2 6
# virsh vcpupin guest1 3 7
The virsh vcpuinfo command confirms the change in affinity.
# virsh vcpuinfo guest1
VCPU:           0
CPU:            4
State:          running
CPU time:       32.2s
CPU Affinity:   ----y---
VCPU:           1
CPU:            5
State:          running
CPU time:       16.9s
CPU Affinity:   -----y--
VCPU:           2
CPU:            6
State:          running
CPU time:       11.9s
CPU Affinity:   ------y-
VCPU:           3
CPU:            7
State:          running
CPU time:       14.6s
CPU Affinity:   -------y

32.9. 新規の特有 MAC アドレスを生成

In some case you will need to generate a new and unique MAC address for a guest. There is no command line tool available to generate a new MAC address at the time of writing. The script provided below can generate a new MAC address for your guests. Save the script to your guest as macgen.py. Now from that directory you can run the script using ./macgen.py and it will generate a new MAC address. A sample output would look like the following:
$ ./macgen.py 
00:16:3e:20:b0:11
	
#!/usr/bin/python
# macgen.py script to generate a MAC address for virtualized guests on Xen
#
import random
#
def randomMAC():
	mac = [ 0x00, 0x16, 0x3e,
		random.randint(0x00, 0x7f),
		random.randint(0x00, 0xff),
		random.randint(0x00, 0xff) ]
	return ':'.join(map(lambda x: "%02x" % x, mac))
#
print randomMAC()
使用ゲストの為の新規 MAC の別の生成方法
組込み済みのモジュール python-virtinst を使用しても 新規 MAC アドレスと ゲスト設定ファイル用の UUID を 生成できます。
# echo  'import virtinst.util ; print\
 virtinst.util.uuidToString(virtinst.util.randomUUID())' | python
# echo  'import virtinst.util ; print virtinst.util.randomMAC()' | python
上記のスクリプトは、下記に示してあるようにスクリプトファイルとしても 実装できます。
#!/usr/bin/env python
#  -*- mode: python; -*-
print ""
print "New UUID:"
import virtinst.util ; print virtinst.util.uuidToString(virtinst.util.randomUUID())
print "New MAC:"
import virtinst.util ; print virtinst.util.randomMAC()
print ""

32.10. Xen ゲスト用のネットワークバンド幅を制限

In some environments it may be required to limit the network bandwidth available to certain guests. This can be used to implement basic Quality of Service on a host running multiple virtual machines. By default, the guest can use any bandwidth setting available which your physical network card supports. The physical network card must be mapped to one of virtual machine's virtual network interfaces. In Xen the “rate” parameter part of the VIF entries can throttle virtualized guests.
この一覧は変数を取り扱います
rate
The rate= option can be added to the VIF= entry in a virtual machine configuration file to limit a virtual machine's network bandwidth or specify a specific time interval for a time window.
時間ウィンドウ
時間ウィンドウは rate= オプションへの選択肢です:
デフォルトの時間ウィンドウは 50ms です。
小さい時間ウィンドウは少なめの突発伝送 (burst transmission) を提供しますが、 補充レートと遅延は増加します。
デフォルトの 50ms 時間ウィンドウは遅延とスループットの間の良いバランスです。 ほとんどのケースで変更は必要ないでしょう。
rate パラメータ値と使用法の例
rate=10Mb/s
ゲストからの発信ネットワークトラフィックを 10MB/s に制限します。
rate=250KB/s
ゲストからの発信ネットワークトラフィックを 250KB/s に制限します。
rate=10MB/s@50ms
バンド幅を 10MB/s に制限して 50ms 毎に 50KB のブロックをゲストに提供します。
仮想マシンの設定で、サンプルの VIF エントリは以下のように なります:
vif = [ 'rate=10MB/s , mac=00:16:3e:7a:55:1c, bridge=xenbr1']
This rate entry would limit the virtual machine's interface to 10MB/s for outgoing traffic

32.11. Xen プロセッサ類似物の設定

Xen は単数、又は複数の CPU と関連付けるために仮想 CPU を割り当てることができます。 これが本当のプロセッシングリソースを仮想化ゲストに割り当てます。このアプローチにより、 Red Hat Enterprise Linux は、デュアルコア、ハイパースレッド、あるいは、他の CPU 並行稼働 技術を使用する時にプロセッサリソースを最適化します。Xen クレジットスケジューラは自動的に 物理 CPU 間の仮想化 CPU のバランスを取り、システム使用を最大限にします。仮想化 CPU が物理 CPU に固定してある限りは、必要であれば Red Hat Enterprise Linux は、クレジット スケジューラが CPU を使い分けできるようにします。
I/O 集中のタスクを実行している場合、domain0 を稼働するためにハイパースレッドか、 あるいはプロセッサコア全体を専従させることが推奨されます。
KVM はデフォルトで Linux カーネルスケジューラを使用するため、KVM 用には これは必要ないことに注意して下さい。
CPU 類似物は virshvirt-manager でセットできます:
To set CPU affinities using virsh refer to 仮想 CPU 類似物の設定 for more information.
To configure and view CPU information with virt-manager refer to 「仮想 CPU の表示」 for more information.

32.12. Xen hypervisor の修正

Managing host systems often involves changing the boot configuration file /boot/grub/grub.conf. Managing several or more hosts configuration files quickly becomes difficult. System administrators often prefer to use the 'cut and paste' method for editing multiple grub.conf files. If you do this, ensure you include all five lines in the Virtualization entry (or this will create system errors). Hypervisor specific values are all found on the 'xen' line. This example represents a correct grub.conf virtualization entry:
# boot=/dev/sda/
default=0
timeout=15
#splashimage=(hd0, 0)/grub/splash.xpm.gz

hiddenmenu
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console
title Red Hat Enterprise Linux Server (2.6.17-1.2519.4.21. el5xen)
root (hd0, 0)
kernel /xen.gz-2.6.17-1.2519.4.21.el5 com1=115200,8n1
    module /vmlinuz-2.6.17-1.2519.4.21el5xen ro root=/dev/VolGroup00/LogVol00
    module /initrd-2.6.17-1.2519.4.21.el5xen.img
For example, to change the memory entry on your hypervisor (dom0) to 256MB at boot time, edit the 'xen' line and append it with this entry: 'dom0_mem=256M'. This example is the grub.conf with the hypervisor's memory entry modified.
# boot=/dev/sda
default=0
timeout=15
#splashimage=(hd0,0)/grubs/splash.xpm.gz
hiddenmenu
serial --unit=0 --speed =115200 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console
title Red Hat Enterprise Linux Server (2.6.17-1.2519.4.21. el5xen)
root (hd0,0)
kernel /xen.gz-2.6.17-1.2519.4.21.el5 com1=115200,8n1 dom0_mem=256MB
    module /vmlinuz-2.6.17-1.2519.4.21.el5xen ro root=/dev/VolGroup00/LogVol00
    module /initrd-2.6.17-1.2519.4.21.el5xen.img

32.13. 非常にセキュアな ftpd

vsftpd は para-virtualized ゲストの インストールツリー(例えば、Red Hat Enterprise Linux 5 のレポジトリ)又は他のデータ へのアクセスを提供します。サーバーのインストール時に vsftpd を インストールしていない場合は、インストールメディアの Server ディレクトリから RPM パッケージを取得して、rpm -ivh vsftpd*.rpm を 使用してインストールできます(RPM パッケージは作業中のディレクトリになければならないことに 注意して下さい)。
  1. To configure vsftpd, edit /etc/passwd using vipw and change the ftp user's home directory to the directory where you are going to keep the installation trees for your para-virtualized guests. An example entry for the FTP user would look like the following:
    ftp:x:14:50:FTP User:/xen/pub:/sbin/nologin
    
  2. chkconfig --list vsftpd を使用して、vsftpd が 有効になっていないことを確認します:
    $ chkconfig --list vsftpd
    vsftpd          0:off   1:off   2:off   3:off   4:off   5:off   6:off
    
  3. chkconfig --levels 345 vsftpd on を実行して、ランレベル 3 と 4 と 5 で vsftpd が自動的にスタートするようにします。
  4. chkconfig --list vsftpd コマンドを使用すると、vsftpd デーモン が システムブート時にスタートするように有効になっていることを確認できます:
    $ chkconfig --list vsftpd
    vsftpd          0:off   1:off   2:off   3:on    4:on    5:on    6:off
    
  5. service vsftpd start vsftpd を使用して、vsftpd サービスを スタートします:
    $service vsftpd start vsftpd
    Starting vsftpd for vsftpd:                  [  OK  ]
    

32.14. LUN 永続化の設定

This section covers how to implement LUN persistence in guests and on the host machine with and without multipath.
multipath を使用しないで LUN 永続化の実装
システムがマルチパスを使用していない場合、udev を使用して LUN 永続化を実装することができます。自分のシステムで LUN 永続化の実装をする前に、正しい UUID を取得することを確認して下さい。これらを取得した後は、/etc ディレクトリ内にある scsi_id ファイルを編集して LUN 永続化を設定できます。テキストエディタでこのファイルを開いたら、以下の行をコメントアウトする必要があります:
# options=-b
そして、これを次のパラメータで入れ換えます:
# options=-g
これが、返って来る UUID の為にシステム SCSI デバイス全てを監視するように udev に指示します。システム UUID を決定するには、以下のように scsi_id コマンドを使用します:
# scsi_id -g -s /block/sdc
*3600a0b80001327510000015427b625e*
この出力内の長い文字列は UUID です。UUID はユーザーが新規デバイスをシステムに 追加しても変化しません。デバイス群用のルールを作成するために各デバイス毎に UUID を取得して下さい。新規のデバイスルールを作成するには、/etc/udev/rules.d ディレクトリ内にある 20-names.rules ファイルを 編集します。デバイス命名ルールは以下の形式に従います:
# KERNEL="sd*",  BUS="scsi",  PROGRAM="sbin/scsi_id", RESULT="UUID", NAME="devicename"
既存の UUIDdevicename を、上記の取り込んだ UUID エントリに入れ換えます。その規則は以下に似たものになります:
KERNEL="sd*",  BUS="scsi",  PROGRAM="sbin/scsi_id", RESULT="3600a0b80001327510000015427b625e", NAME="mydevicename"
これが、 /dev/sd* パターンに一致する全てのデバイスを有効にして、任意の UUID を検査するようになります。一致するデバイスを発見した場合、 /dev/devicename と呼ばれるデバイスノードを作成します。この例では、デバイスノードは /dev/mydevice にしています。最後に /etc/rc.local ファイルに以下の行を追記します:
/sbin/start_udev
multipath を使用した LUN 永続化の実装
マルチパス環境内で LUN 永続化を実装するには、マルチパスデバイス用のエイリアス名を定義する必要があります。例えば、/etc/ ディレクトリ内にある multipath.conf ファイルを編集して、四つのデバイスエイリアスを定義する必要があります。
multipath  {  
             wwid       3600a0b80001327510000015427b625e
             alias      oramp1
}
multipath  {  
             wwid       3600a0b80001327510000015427b6
             alias      oramp2
}
multipath  {  
             wwid       3600a0b80001327510000015427b625e
             alias      oramp3
}
multipath  {  
             wwid       3600a0b80001327510000015427b625e
             alias      oramp4
}
これが、4 つ の LUN を定義します: /dev/mpath/oramp1/dev/mpath/oramp2/dev/mpath/oramp3、及び dev/mpath/oramp4 です。デバイスは /dev/mpath ディレクトリ内に存在します。これらの LUN 名は、各 LUN 毎の wwid 上でエイリアス名を作成する為、再起動後にも残る永続性を持ちます。

32.15. ゲスト用の SMART ディスク監視を無効化

仮想ディスク上で実行しているため、及び物理ストレージがホストで管理されているため、 SMART ディスク監視は無効にすることができます。
/sbin/service smartd stop
/sbin/chkconfig --del smartd

32.16. 古い Xen 設定ファイルを整理

Over time you will see a number of files accumulate in /var/lib/xen, the usually named vmlinuz.****** and initrd.******. These files are the initrd and vmlinuz files from virtual machines which either failed to boot or failed for some other reason. These files are temporary files extracted from virtual machine's boot disk during the start up sequence. These files should be automatically removed after the virtual machine is shut down cleanly. Then you can safely delete old and stale copies from this directory.

32.17. VNC サーバーの設定

VNC サーバーを設定するには、システム > 個人設定 と進んで、リモートディスクトップ を使用します。 別の方法として、vino-preferences コマンドを実行することもできます。
以下のステップは、専従の VNC サーバーセッションをセットアップします:
  1. ~/.vnc/xstartup ファイルを編集することで、 vncserver がスタートする時にはいつも GNOME セッションが スタートするようにします。vncserver スクリプトを初めて 実行する時は使用する VNC セッション用のパスワードを要求して来ます。
  2. xstartup ファイルのサンプル:
    #!/bin/sh
    # Uncomment the following two lines for normal desktop:
    # unset SESSION_MANAGER
    # exec /etc/X11/xinit/xinitrc
    [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
    [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
    #xsetroot -solid grey
    #vncconfig -iconic &
    #xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
    #twm &
    if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
    	eval `dbus-launch --sh-syntax –exit-with-session`
    	echo "D-BUS per-session daemon address is: \
    	$DBUS_SESSION_BUS_ADDRESS"
    fi
    exec  gnome-session
    

32.18. ゲスト設定ファイルのクローン

You can copy an existing configuration file to create an all new guest. You must modify the name parameter of the guests' configuration file. The new, unique name then appears in the hypervisor and is viewable by the management utilities. You must generate an all new UUID as well by using the uuidgen command. Then for the vif entries you must define a unique MAC address for each guest (if you are copying a guest configuration from an existing guest, you can create a script to handle it). For the xen bridge information, if you move an existing guest configuration file to a new host, you must update the xenbr entry to match your local networking configuration. For the Device entries, you must modify the entries in the 'disk=' section to point to the correct guest image.
You must also modify these system configuration settings on your guest. You must modify the HOSTNAME entry of the /etc/sysconfig/network file to match the new guest's hostname.
/etc/sysconfig/network-scripts/ifcfg-eth0 ファイルの HWADDR アドレスを修正して、ifconfig eth0 からの 出力に一致するようにしなければなりません。そして、静的 IP アドレスを使用している場合は、IPADDR エントリを修正する必要があります。

32.19. 既存ゲストとその設定ファイルを複製

This section outlines copying an existing configuration file to create a new guest. There are key parameters in your guest's configuration file you must be aware of, and modify, to successfully duplicate a guest.
name
hypervisor によって知られており、管理ユーティリティに表示されているゲストの名前です。このエントリはシステム内で特有でなければなりません。
uuid
ゲスト用の特有の処理です。新規の UUID は uuidgen コマンドを 使用して再生成できます。UUID の出力のサンプルは以下のようになります:
$ uuidgen 
a984a14f-4191-4d14-868e-329906b211e5
vif
  • The MAC address must define a unique MAC address for each guest. This is automatically done if the standard tools are used. If you are copying a guest configuration from an existing guest you can use the script 「新規の特有 MAC アドレスを生成」.
  • 新規のホストに向けて既存のゲスト設定ファイルを移動したり複製したりする場合は、 xenbr エントリを調節して使用中のローカル ネットワーキング設定に対応するようにしなければなりません。(brctl show コマンドを使用すると、ブリッジ情報を取得できます)。
  • デバイスエントリについては、そのエントリを disk= セクション内で調節して、正しいゲストイメージにポイントする ように確認します。
ここで、使用ゲスト上のシステム設定セッティングを調節します:
/etc/sysconfig/network
Modify the HOSTNAME entry to the guest's new hostname.
/etc/sysconfig/network-scripts/ifcfg-eth0
  • HWADDR アドレスを ifconfig eth0 からの 出力に合わせて変更します。
  • 静的 IP アドレスが使用されている場合は、IPADDR エントリを 変更します。

第33章 カスタムの libvirt スクリプト作成

このセクションでは、libvirt の使用により、操作を簡単にするためのカスタムスクリプト作成を計画しているプログラマとシステム管理者に役立つ 一部の情報を提供します。
32章ヒントと裏技 is recommended reading for programmers thinking of writing new applications which use libvirt.

33.1. virsh を用いた XML 設定ファイルの使用

virsh can handle XML configuration files. You may want to use this to your advantage for scripting large deployments with special options. You can add devices defined in an XML file to a running para-virtualized guest. For example, to add a ISO file as hdc to a running guest create an XML file:
# cat satelliteiso.xml
<disk type="file" device="disk">
	<driver name="file"/>
	<source file="/var/lib/libvirt/images/rhn-satellite-5.0.1-11-redhat-linux-as-i386-4-embedded-oracle.iso"/>
	<target dev="hdc"/>
	<readonly/>
</disk>
Run virsh attach-device to attach the ISO as hdc to a guest called "satellite" :
# virsh attach-device satellite satelliteiso.xml

パート VIII. トラブルシューティング

トラブルシューティングと問題解決への案内

以下の章では、仮想化の使用で遭遇するトラブルシューティング問題に於いて ユーザーを支援する情報を提供しています。

仮想化問題についての重要な注記

バグの作成と修正をする継続的開発のため、このマニュアルには現在遭遇している問題は 記載されていないかも知れません。既知のバグとバグ修正に関する最新のリストには、 ご使用のバージョンとアーキテクチャ用の Red Hat Enterprise Linux Release Notes を お読み下さい。Release Notes は Red Hat ウェブサイト www.redhat.com/docs/manuals/enterprise/ のドキュメントセクションで見つけることができます。

何も達成できない場合は...

Red Hat グローバルサポートサービス(https://www.redhat.com/apps/support/)までご連絡下さい。弊社のスタッフが喜んで問題解決のお手伝いをします。

目次

34. Xen のトラブルシューティング
34.1. Xen でのデバッギングとトラブルシューティング
34.2. ログファイルの概要
34.3. ログファイルの説明
34.4. 重要ディレクトリの場所
34.5. ログを使用したトラブルシューティング
34.6. シリアルコンソールを使用したトラブルシューティング
34.7. Para-virtualized ゲストコンソールのアクセス
34.8. 完全仮想化ゲストコンソールのアクセス
34.9. 一般的な Xen の問題
34.10. ゲスト作成のエラー
34.11. シリアルコンソールを使用したトラブルシューティング
34.11.1. Xen 用のシリアルコンソール出力
34.11.2. para-virtualized ゲストからの Xen シリアルコンソール出力
34.11.3. 完全仮想化ゲストからのシリアルコンソール出力
34.12. Xen 設定ファイル
34.13. Xen エラーメッセージの解釈
34.14. ログディレクトリのレイアウト
35. トラブルシューティング
35.1. 利用可能なストレージとパーティションを判別する
35.2. Xen ベースのゲストを再起動した後にコンソールはフリーズ
35.3. 仮想化イーサネットデバイスはネットワーキングツールでは見付からない。
35.4. ループデバイスエラー
35.5. メモリー不足によるドメイン作成の失敗
35.6. 間違えたカーネルイメージのエラー
35.7. 間違えたカーネルイメージのエラー:PAE プラットフォーム上に非 PAE カーネル
35.8. 完全仮想化 64 bit ゲストが起動失敗
35.9. ローカルホストエントリの欠如が virt-manager の失敗原因
35.10. ゲスト起動時の Microcode エラー
35.11. 仮想マシン開始時での Python 低評価警告メッセージ
35.12. BIOS 内で、Intel VT と AMD-V の仮想化ハードウェア拡張を有効にする
35.13. KVM ネットワーキングパフォーマンス
36. Xen para-virtualized ドライバーのトラブルシューティング
36.1. Red Hat Enterprise Linux 5 仮想化のログファイルとディレクトリ
36.2. Para-virtualized ゲストは、Red Hat Enterprise Linux 3 のゲストオペレーティング システム上ではロードに失敗。
36.3. Red Hat Enterprise Linux 3 に para-virtualized ドライバーをインストールする時点に 警告メッセージ。
36.4. para-virtualized ドライバーを手動でロードする
36.5. para-virtualized ドライバーが正常にロードされたことを確認
36.6. システムは、para-virtualized ドライバーではスループットに制限があります

第34章 Xen のトラブルシューティング

この章では、Xen に於けるトラブルシューティング問題でユーザーを支援するための 基本的な概念を扱います。この章で扱うトラブルシューティングのトピックには以下が 含まれます:
  • Linux 及び仮想化のためのトラブルシューティングツール
  • 問題判別の為のトラブルシューティング技術
  • ログファイルの場所とログ内の情報の説明
この章では、読者に対して仮想化技術の問題場所を判別するための基礎を提供します。 トラブルシューティングは本で学習することが困難な実践と経験を要します。ユーザーは Red Hat Enterprise Linux 上で仮想化の実験とテストをして、トラブルシューティングの 能力を開発することが推奨されます。
If you cannot find the answer in this document there may be an answer online from the virtualization community. Refer to 「オンラインリソース」 for a list of Linux virtualization websites.

34.1. Xen でのデバッギングとトラブルシューティング

このセクションはシステム管理アプリケーション、ネットワーキングユーティリティ、 及びデバグツールなどを要約しています。これらの標準のシステム管理者ツールとログを 活用してトラブルシューティングの手助けにできます:
トラブルシューティングの為の役に立つコマンドとアプリケーション
xentop
xentop はホストシステムとゲストドメインに関するリアルタイムの 情報を表示します。
xm
dmesglog の使用
  • vmstat
  • iostat
  • lsof
iostat コマンド、mpstat コマンド、及び sar コマンドは全て sysstat パッケージで用意されています。
これらの高度なデバグツールとログを活用してトラブルシュートの手助けにできます:
  • XenOprofile
  • systemtap
  • crash
  • sysrq
  • sysrq t
  • sysrq w
これらのネットワーキングツールを活用して仮想化ネットワーキング問題での トラブルシュートの手助けにできます:
  • ifconfig
  • tcpdump
    The tcpdump command 'sniffs' network packets. tcpdump is useful for finding network abnormalities and problems with network authentication. There is a graphical version of tcpdump named wireshark.
  • brctl
    brctl は Virtualization linux カーネル内のイーサネットブリッジ構成を検査して設定するネットワーキングツールです。これらのサンプルコマンドを実行するには root アクセスが必要になります:
    # brctl show 
    
    bridge-name    bridge-id          STP  enabled  interfaces  
    -----------------------------------------------------------------------------
    xenbr0             8000.feffffff       no        vif13.0
    xenbr1             8000.ffffefff       yes       pddummy0
    xenbr2             8000.ffffffef       no        vif0.0
    
    # brctl showmacs xenbr0
    
    port-no           mac-addr                  local?       aging timer
    
    1                 fe:ff:ff:ff:ff:           yes            0.00
    2                 fe:ff:ff:fe:ff:           yes            0.00
    
    
    # brctl showstp xenbr0
    xenbr0 
    bridge-id              8000.fefffffffff
    designated-root        8000.fefffffffff
    root-port              0                   path-cost             0
    max-age                20.00               bridge-max-age        20.00
    hello-time             2.00                bridge-hello-time     2.00
    forward-delay          0.00                bridge-forward-delay  0.00
    aging-time            300.01
    hello-timer            1.43                tcn-timer             0.00
    topology-change-timer  0.00                gc-timer              0.02
    
以下の一覧では、Red Hat Enterprise Linux 5 上の仮想化のトラブルシューティングの為の その他の役立つコマンドを表示しています。ここで言及してある全てのユーティリティは Red Hat Enterprise Linux 5 の Server レポジトリ内で見ることが できます。
  • strace は他のプロセスで受信されて使用されたシステムコールと イベントを追跡するコマンドです。
  • vncviewer: connect to a VNC server running on your server or a virtual machine. Install vncviewer using the yum install vnc command.
  • vncserver: 使用するサーバー上でリモートデスクトップを 開始します。そしてユーザーがリモートセッションを通じて virt-manager などのグラフィカル ユーザーインターフェイスを実行できるようにします。vncserver の インストールには、yum install vnc-server コマンドを使用します。

34.2. ログファイルの概要

When deploying Red Hat Enterprise Linux 5 with Virtualization into your network infrastructure, the host's Virtualization software uses many specific directories for important configuration, log files, and other utilities. All the Xen logs files are standard ASCII files, and accessible with a text editor:
  • Xen の設定ファイルディレクトリは /etc/xen/ です。 このディレクトリには、xend デーモンと他の仮想マシン設定ファイルが含まれています。ネットワークスクリプトファイルは scripts ディレクトリ内に存在します。
  • 全ての Xen ログファイルは /var/log/xen ディレクトリに 格納してあります。
  • 全てのファイルベースイメージ用のデフォルトディレクトリは /var/lib/libvirt/images ディレクトリです。
  • Xen カーネル情報は /proc/xen/ ディレクトリに格納して あります。

34.3. ログファイルの説明

Xen は xend デーモンと qemu-dm プロセスを特長とします。これらの二つのユーティリティは複数ログファイルを /var/log/xen/ ディレクトリに書き込みます:
  • xend.logxend デーモンにより収集された通常のシステムイベント、又はオペレータ先導のアクションのどちらでも、全てのデータを含むログファイルです。全ての仮想マシン運用 (作成、シャットダウン、破棄など) はこのログに現われます。 xend.log は通常、ユーザーがイベントやパフォーマンス問題を追跡する時に調査する最初の場所です。ここには、エラーメッセージの 詳細なエントリと状況が含まれています。
  • xend-debug.logxend と Virtualization サブシステム (フレームバッファ、Python スクリプトなど) からのイベントエラーの記録を含むログファイルです。
  • xen-hotplug-log は、hotplug イベントからのデータを含むログファイルです。デバイス、又はネットワークのスクリプトがオンラインに出ない場合はイベントはここに表示されます。
  • qemu-dm.[PID].log は各完全仮想化ゲスト用の qemu-dm プロセスで作成されたログファイルです。このログファイルを使用する時には、仮想マシン上の qemu-dm プロセスを隔離する為のプロセス引数を検査するのに ps コマンドを使用することで任意の qemu-dm プロセス PID を取り込む必要があります。この [PID] シンボルは実際の PID qemu-dm プロセスで入れ換えることに注意して下さい。
仮想マシンマネージャでなんらかの問題に遭遇した場合、/.virt-manager ディレクトリ内にある virt-manager.log ファイルの生成データで確認することができます。仮想マシンマネージャを開始する度に既存のログファイル内容は書き変えられることに注意して下さい。システムエラーの後では、 仮想マシンマネージャを再起動する前に virt-manager.log をバックアップすることを忘れないで下さい。

34.4. 重要ディレクトリの場所

Xen でエラー追跡をしたり問題のトラブルシュートをしたりする時、認識しておくべき 他のユーティリティやログファイルがあります:
  • 仮想ゲストイメージは /var/lib/libvirt/images ディレクトリ内にあります。
  • xend デーモンを再開始する場合、それは /var/lib/xen/xend-db ディレクトリにある xend-database を更新します。
  • 仮想マシンダンプ (xm dump-core コマンドで実行) は/var/lib/xen/dumps ディレクトリにあります。
  • /etc/xen ディレクトリには、システムリソースの管理に使用する設定ファイルが含まれています。xend デーモン設定ファイルは /etc/xen/xend-config.sxp です。このファイルを編集して システム全体の変更を実装し、そしてネットワーキングを設定することができます。しかし、 /etc/xen/ フォルダ内でファイルを手動で編集することは推奨 できません。
  • proc フォルダは、ユーザーがシステム情報を取得できるようにするもう1つのリソースです。以下の proc エントリは /proc/xen ディレクトリにあります:
/proc/xen/capabilities
/proc/xen/balloon
/proc/xen/xenbus/

34.5. ログを使用したトラブルシューティング

When encountering installation issues with Xen, refer to the host system's two logs to assist with troubleshooting. The xend.log file contains the same basic information as when you run the xm log command. This log is found in the /var/log/ directory. Here is an example log entry for when you create a domain running a kernel:
[2006-12-27 02:23:02 xend] ERROR (SrvBase: 163) op=create: Error creating domain: (0, 'Error')
Traceback (most recent call list)
File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvBase.py" line 107 in_perform val = op_method (op,req)
File
"/usr/lib/python2.4/site-packages/xen/xend/server/SrvDomainDir.py line 71 in op_create
raise XendError ("Error creating domain: " + str(ex))
XendError: Error creating domain: (0, 'Error')
もう1つのログファイル、 xend-debug.log は、システム管理者に非常に役に立ちます。これには、 xend.log 以上の詳細情報が含まれています。以下に同じカーネルドメイン作成問題についての同じエラーデータを示します:
ERROR: Will only load images built for Xen v3.0
ERROR: Actually saw: GUEST_OS=netbsd, GUEST_VER=2.0, XEN_VER=2.0; LOADER=generic, BSD_SYMTAB'
ERROR: Error constructing guest OS
カスタマサポートに連絡する場合、技術サポートスタッフと通信する時に常にこれらの両方のログファイルコピーを含めて下さい。

34.6. シリアルコンソールを使用したトラブルシューティング

The serial console is helpful in troubleshooting difficult problems. If the Virtualization kernel crashes and the hypervisor generates an error, there is no way to track the error on a local host. However, the serial console allows you to capture it on a remote host. You must configure the host to output data to the serial console. Then you must configure the remote host to capture the data. To do this, you must modify these options in the grub.conf file to enable a 38400-bps serial console on com1 /dev/ttyS0:
title Red Hat Enterprise Linux (2.6.18-8.2080_xen0)
	root (hd0,2)
	kernel /xen.gz-2.6.18-8.el5 com1=38400,8n1 
	module /vmlinuz-2.618-8.el5xen ro root=LABEL=/rhgb quiet console=xvc console=tty xencons=xvc 	
	module /initrd-2.6.18-8.el5xen.img
sync_console は非同期の hypervisor コンソール出力でハングの原因となる問題の判定の手助けになります。そして "pnpacpi=off" はシリアルコンソール上で入力を破損する問題を回避します。パラメータ "console=ttyS0" "console=tty" はカーネルエラーが通常の VGA コンソールと シリアルコンソールの両方でログされることを意味します。それから、 ttywatch をインストール及び設定をして、標準の null-modem ケーブルで接続されたリモートホスト上でデータをキャプチャすることができます。例えば、リモートホスト上で以下のように入力します:

Itanium シリアルコンソールのトラブルシューティング

To access the hypervisor via a serial console on the Itanium® architecture you must enable the console in ELILO. For more information on configuring ELILO, refer to 29章ELILO の設定.
ttywatch --name myhost --port /dev/ttyS0
これが /dev/ttyS0 からの出力をファイル /var/log/ttywatch/myhost.log にパイプします。

34.7. Para-virtualized ゲストコンソールのアクセス

Para-virtualized guest operating systems automatically has a virtual text console configured to transmit data to the host operating system. Connect to a guest's virtual console with the following command:
# virsh console [guest name, ID or UUID]
You can also use virt-manager to display the virtual text console. In the guest console window, select Serial Console from the View menu.

34.8. 完全仮想化ゲストコンソールのアクセス

Fully virtualized guest operating systems automatically has a text console configured for use, but the difference is the kernel guest is not configured. To enable the guest virtual serial console to work with the Full Virtualized guest, you must modify the guest's grub.conf file, and include the 'console =ttyS0 console=tty0' parameter. This ensures that the kernel messages are sent to the virtual serial console (and the normal graphical console). To use the guest's serial console, you must edit the libvirt configuration file configuration file. On the host, access the serial console with the following command:
# virsh console
You can also use virt-manager to display the virtual text console. In the guest console window, select Serial Console from the View menu.

34.9. 一般的な Xen の問題

xend サービスを開始しようとして、何も起こらない場合、virsh list と入力して、以下の情報を受けます:
Error: Error connecting to xend: Connection refused. Is xend running?
手動で xend start の実行を試みて、他のエラーも受理します:
Error: Could not obtain handle on privileged command interfaces (2 = No such file or directory)
Traceback (most recent call last:)
File "/usr/sbin/xend/", line 33 in ?
from xen.xend.server. import SrvDaemon
File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvDaemon.py" , line 26 in ?
from xen.xend import XendDomain
File "/usr//lib/python2.4/site-packages/xen/xend/XendDomain.py" , line 33, in ?
		
from xen.xend import XendDomainInfo
File "/usr/lib/python2.4/site-packages/xen/xend/image.py" , line37, in ?
import images
File "/usr/lib/python2.4/site-packages/xen/xend/image.py" , line30, in ?
xc = xen.lowlevel.xc.xc ()
RuntimeError: (2, 'No such file or directory' )
ここで、最も発生した可能性のあることは、ユーザーが kernel-xen 以外のカーネルでホストを再起動したことです。これを修正するには、起動時に kernel-xenカーネルを選択することです(又はそれを grub.conf ファイル内でデフォルトのカーネルにセットします)。

34.10. ゲスト作成のエラー

ゲストを作成しようとしている時に、"Invalid argument" のエラーメッセージが出ることがあります。これは通常、ブートしようとしているカーネルイメージが hypervisor に不適合と言う意味です。例として、PAE のみの FC6 hypervisor で非 PAE FC5 カーネルを実行しようとすると、この状況が出ます。
yum の更新をして、新規カーネルを取得したとします。すると grub.conf デフォルトのカーネルは Virtualization カーネルではなく、生のままのカーネルに戻ることになります。
To correct this problem you must modify the default kernel RPM that resides in the /etc/sysconfig/kernel/ directory. You must ensure that kernel-xen parameter is set as the default option in your grub.conf file.

34.11. シリアルコンソールを使用したトラブルシューティング

Linux カーネルは情報をシリアルポートへ出力できます。これは、カーネルパニックや、 ビデオデバイス又はヘッドレスサーバーでのハードウェア問題のデバッグに役立ちます。 このセクションのサブセクションでは、Red Hat Enterprise Linux virtualization カーネルと それらの仮想化ゲストを実行しているマシン用のシリアルコンソール出力のセットアップに ついて説明していきます。

34.11.1. Xen 用のシリアルコンソール出力

By default, the serial console for the Xen hypervisor is disabled and no data is output from serial ports.
シリアルポート上でカーネル情報を受信するには、適切なシリアルデバイスパラメータを 設定することにより /boot/grub/grub.conf ファイルを修正します。
使用するシリアルコンソールが com1 にある場合は、 以下に示した位置に、com1=115200,8n1 の行、 console=tty0 の行、及び console=ttyS0,115200 の 行を挿入することにより /boot/grub/grub.conf を変更します。
title Red Hat Enterprise Linux 5 i386 Xen (2.6.18-92.el5xen)
	root (hd0, 8)
	kernel /boot/xen.gz-2.6.18-92.el5 com1=115200,8n1
	module /boot/vmlinuz-2.6.18-92.el5xen ro root=LABEL=VG_i386 console=tty0
				console=ttyS0,115200
	module /boot/initrd-2.6.18-92.el5xen.img
使用するシリアルコンソールが com2 にある場合は、 以下に示してある位置に com2=115200,8n1 console=com2L 行、 console=tty0 行、及び console=ttyS0,115200 行を挿入することにより、/boot/grub/grub.conf を 変更します。
title Red Hat Enterprise Linux 5 i386 Xen (2.6.18-92.el5xen)
	root (hd0, 8)
	kernel /boot/xen.gz-2.6.18-92.el5 com2=115200,8n1 console=com2L
	module /boot/vmlinuz-2.6.18-92.el5xen ro root=LABEL=VG_i386 console=tty0
	console=ttyS0,115200
	module /boot/initrd-2.6.18-92.el5xen.img
その変更を保存してホストを再起動します。そうすると、先のステップで選択したシリアル上(com1, com2 など)に hypervisor がシリアルデータを出力します。
com2 ポートを使用している例では、パラメータ console=ttyS0vmlinuz 行上で使用されています。console=ttyS0 として 使用されている各ポートの動作は標準の Linux 動作ではありません。これは Xen 環境特有の 動作です。

34.11.2. para-virtualized ゲストからの Xen シリアルコンソール出力

このセクションでは、Red Hat Enterprise Linux para-virtualized ゲスト用に 仮想化シリアルコンソールの設定方法を説明しています。
para-virtualized ゲストからのシリアルコンソール出力は "virsh console" の 使用で取り込むか、あるいは virt-manager の "シリアル" ウィンドウ内に取り込めます。以下の手順を使用して仮想シリアルコンソールのセットアップを します:
  1. para-virtualized ゲストへログイン
  2. /boot/grub/grub.conf を以下のように編集します:
    Red Hat Enterprise Linux 5 i386 Xen (2.6.18-92.el5xen)
    	root (hd0, 0) kernel /boot/vmlinuz-2.6.18-92.el5xen ro root=LABEL=VG_i386 console=xvc0 
    	initrd /boot/initrd-2.6.18-92.el5xen.img
    
  3. para-virtualized ゲストを再起動
ここで virt-manager の "Serial Console" と "virsh console" にカーネルメッセージを 受け取るはずです。
para-virtualized ドメインのシリアルコンソール出力のログ
Xen デーモン (xend) を設定することで para-virtualized ゲストのシリアルコンソールからの出力をログすることができます。
xend を設定するには、/etc/sysconfig/xend を編集します。以下のようにエントリを変更します:
# Log all guest console output (cf xm console)
#XENCONSOLED_LOG_GUESTS=no
to:
# Log all guest console output (cf xm console)
XENCONSOLED_LOG_GUESTS=yes
ゲストのシリアルコンソール出力のロギングをアクティブにするために再起動します。
ゲストシリアルコンソールからのログは /var/log/xen/console ファイルに格納されています。

34.11.3. 完全仮想化ゲストからのシリアルコンソール出力

このセクションでは、完全仮想化ゲスト用のシリアルコンソール出力を 有効にする方法を説明します。
完全仮想化ゲストのシリアルコンソール出力は "virsh console" コマンドを使用して見ることができます。
完全仮想化ゲストのシリアルコンソールはいくつかの制限を持つことに注意して 下さい。現在の制限には以下が含まれます:
  • xend を使用した出力のログは利用できません。
  • 出力データは欠如するか、混乱しているかも知れません。
シリアルポートは Linux で ttyS0、又は Windows で COM1 と呼ばれます。
仮想シリアルポートに情報を出力するには、仮想化オペレーティングシステムを設定する 必要があります。
完全仮想化 Linux ゲストからのカーネル情報をドメインに出力するには、 "console=tty0 console=ttys0,115200" と言う行を 挿入することで /boot/grub/grub.conf ファイルを修正します。
title Red Hat Enterprise Linux Server (2.6.18-92.el5)
	root (hd0,0)
	kernel /vmlinuz-2.6.18-92.el5 ro root=/dev/volgroup00/logvol00
	console=tty0 console=ttys0,115200
	initrd /initrd-2.6.18-92.el5.img
ゲストを再起動します。
"virsh console" コマンドを使用するとシリアルコンソールの メッセージを見ることができます。

注記

完全仮想化ドメインからのシリアルコンソールメッセージは、para-virtualized ゲストとは 異なり、/var/log/xen/console にはログされていません。

34.12. Xen 設定ファイル

When you create guests with the virt-manager or virt-install tools on Red Hat Enterprise Linux 5, the guests configuration files are created automatically in the /etc/xen directory.

Warning

Red Hat advises users not to manually edit Xen configuration files. Xen configuration files have limited error checking and many unsupported variables. Editing Xen configuration files may damage your guests, make guests unbootable or cause data loss.
The example below is a typical a para-virtualized guest configuration file:
name = "rhel5vm01"
memory = "2048"
disk = ['tap:aio:/var/lib/libvirt/images/rhel5vm01.dsk,xvda,w',]
vif = ["type=ieomu, mac=00:16:3e:09:f0:12 bridge=xenbr0', 
"type=ieomu, mac=00:16:3e:09:f0:13 ]
vnc = 1
vncunused = 1
uuid = "302bd9ce-4f60-fc67-9e40-7a77d9b4e1ed"
bootloader = "/usr/bin/pygrub"
vcpus=2
on_reboot = "restart"
on_crash = "restart"
serial="pty" は設定ファイル用のデフォルトであることに注意して下さい。この設定ファイルの例は、完全仮想化ゲスト用です:
name = "rhel5u5-86_64"
builder = "hvm"
memory = 500
disk = ['/var/lib/libvirt/images/rhel5u5-x86_64.dsk.hda,w']
vif = [ 'type=ioemu, mac=00:16:3e:09:f0:12, bridge=xenbr0', 'type=ieomu, mac=00:16:3e:09:f0:13, bridge=xenbr1']
uuid = "b10372f9-91d7-ao5f-12ff-372100c99af5'
device_model = "/usr/lib64/xen/bin/qemu-dm"
kernel = "/usr/lib/xen/boot/hvmloader/"
vnc = 1
vncunused = 1
apic = 1
acpi = 1
pae = 1
vcpus =1
serial ="pty" # enable serial console
on_boot = 'restart'

Xen 設定ファイル

Xen 設定ファイルの編集はサポートされていません。そのため、virsh dumpxmlvirsh create (又は virsh edit) を使用して libvirt 設定ファイル (xml ベース) を編集して 下さい。これらはエラーチェックとセイフティチェック機能も持っています。

34.13. Xen エラーメッセージの解釈

次のようなエラー表示があるとします:
failed domain creation due to memory shortage, unable to balloon domain0
RAM が充分にないと、ドメインは失敗する可能性があります。Domain0 は、新規作成のゲスト用に領域を提供する為に縮小はしません。このエラーについては xend.logファイルを確認することになります:
[2006-12-21] 20:33:31 xend 3198] DEBUG (balloon:133) Balloon: 558432 Kib free; 0 to scrub; need 1048576; retries: 20
[2006-12-21] 20:33:31 xend. XendDomainInfo 3198] ERROR (XendDomainInfo: 202
Domain construction failed
xm list Domain0 コマンドを使うと domain0 が使用しているメモリーの量をチェックできます。domain0 が縮小しなければ、コマンド virsh setmem dom0 NewMemSize を使用してメモリーをチェックできます。
次のようなエラー表示があるとします:
wrong kernel image: non-PAE kernel on a PAE
このメッセージは、ユーザーが Hypervisor 上でサポートされていないゲストカーネルイメージを実行しようとしていることを示すものです。これは、Red Hat Enterprise Linux 5 ホスト上ので 非 PAE の para-virtualized ゲストカーネルを起動しようとする時に発生します。Red Hat kernel-xen パッケージは PAE と 64bit アーキテクチャを 持つゲストカーネルのみをサポートします。
次のコマンドを入力します:
# xm create -c va-base

Using config file "va-base"
Error: (22, 'invalid argument')
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] ERRORs
(XendDomainInfo:202) Domain construction failed

Traceback (most recent call last)
File "/usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 195 in create vm.initDomain()
File " /usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 1363 in initDomain raise VmError(str(exn))
VmError: (22, 'Invalid argument')
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] DEBUG (XenDomainInfo: 1449]
XendDlomainInfo.destroy: domain=1
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] DEBUG (XenDomainInfo: 1457]
XendDlomainInfo.destroy:Domain(1)
32 bit 非-PAE カーネルを実行する必要がある場合は、使用中のゲストを完全仮想化の仮想マシンとして実行する必要があります。para-virtualized のゲストの為に 32bit PAE ゲストを実行する必要がある場合は、32bit PAE hypervisor が必要となります。para-virtualized のゲストの為に、64bit PAE ゲストを実行する必要がある場合は、64bit PAE hypervisor が必要となります。完全仮想化のゲスト用には、64bit hypervisor を持つ 64bit ゲストを実行しなければなりません。Red Hat Enterprise Linux 5 i686 に 同梱してある 32bit PAE hypervisor は 32bit PAE para-virtualized ゲスト OS と 32 bit の完全仮想化ゲスト OS の実行のみをサポートします。64bit hypervisor は 64bit para-virtualized のゲストのみをサポートします。
これは、完全仮想化の HVM ゲストを Red Hat Enterprise Linux 5 システムに移動する時に 発覚します。ユーザーのゲストは起動に失敗する可能性があり、コンソール画面にエラーが出るでしょう。設定ファイル内の PAE エントリをチェックして、pae=1 であることを確認します。32bit のディストリビューションを使用する必要があります。
次のようなエラー表示があるとします:
Unable to open a connection to the Xen hypervisor or daemon
これは、virt-manager アプリケーションが起動に失敗した時に発生します。このエラーは/etc/hosts 設定ファイル内にローカルホストのエントリがない場合に起こります。そのファイルをチェックして、ローカルホストが有効であるかどうか確認します。以下に間違えたローカルホストのエントリ例を示します:
# Do not remove the following line, or various programs
# that require network functionality will fail.
localhost.localdomain localhost
以下に正しいローカルホストエントリの例を示します:
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
localhost.localdomain. localhost
以下のエラーが表示されます ( xen-xend.logfile 内で) :
Bridge xenbr1 does not exist!
This happens when the guest's bridge is incorrectly configured and this forces the Xen hotplug scripts to timeout. If you move configuration files between hosts, you must ensure that you update the guest configuration files to reflect network topology and configuration modifications. When you attempt to start a guest that has an incorrect or non-existent Xen bridge configuration, you will receive the following errors:
# xm create mySQL01

Using config file " mySQL01"
Going to boot Red Hat Enterprise Linux Server (2.6.18.-1.2747 .el5xen)
kernel: /vmlinuz-2.6.18-12747.el5xen
initrd: /initrd-2.6.18-1.2747.el5xen.img
Error: Device 0 (vif) could not be connected. Hotplug scripts not working.
更には、xend.log は次のエラーを表示します:
[2006-11-14 15:07:08 xend 3875] DEBUG (DevController:143) Waiting for devices vif
[2006-11-14 15:07:08 xend 3875] DEBUG (DevController:149) Waiting for 0
[2006-11-14 15:07:08 xend 3875] DEBUG (DevController:464) hotplugStatusCallback

/local/domain/0/backend/vif/2/0/hotplug-status

[2006-11-14 15:08:09 xend.XendDomainInfo 3875] DEBUG (XendDomainInfo:1449) XendDomainInfo.destroy: domid=2
[2006-11-14 15:08:09 xend.XendDomainInfo 3875] DEBUG (XendDomainInfo:1457) XendDomainInfo.destroyDomain(2)
[2006-11-14 15:07:08 xend 3875] DEBUG (DevController:464) hotplugStatusCallback

/local/domain/0/backend/vif/2/0/hotplug-status
To resolve this problem, open the guest's configuration file found in the /etc/xen directory. For example, editing the guest mySQL01
# vim /etc/xen/mySQL01
Locate the vif entry. Assuming you are using xenbr0 as the default bridge, the proper entry should resemble the following:
# vif = ['mac=00:16:3e:49:1d:11, bridge=xenbr0',]
次のような python depreciation エラーを受け取ります:
# xm shutdown win2k3xen12
# xm create win2k3xen12

Using config file "win2k3xen12".

/usr/lib64/python2.4/site-packages/xenxm/opts.py:520: Deprecation Warning:
Non ASCII character '\xc0' in file win2k3xen12 on line 1, but no encoding
declared; see http://www.python.org/peps/pep-0263.html for details

execfile (defconfig, globs, locs,)
Error: invalid syntax 9win2k3xen12, line1)
Python は、無効な(又は間違えた) 設定ファイルがある場合にこれらのメッセージを生成します。この問題を解決するには、間違えた設定ファイルを修正するか、又は新しいものを生成します。

34.14. ログディレクトリのレイアウト

Red Hat Enterprise Linux 5 Virtualization 環境内の基本的なディレクトリ構成は 以下のようになります:
/etc/xen/ ディレクトリは以下を含みます
  • xend デーモンで使用される 設定ファイル
  • Virtualization ネットワーキング用のスクリプトを含んでいる scripts ディレクトリ
/var/log/xen/
  • 全ての Xen 関連のログファイルを保有しているディレクトリ
/var/lib/libvirt/images/
  • 仮想マシンイメージファイル用のデフォルトディレクトリ
  • 仮想マシンイメージ用に異なるディレクトリを使用している場合は、そのディレクトリを 確実に SELinux ポリシーに追加して、インストールを開始する前にそれを再ラベルします。
/proc/xen/
  • /proc ファイルシステム内の xen 関連の情報

第35章 トラブルシューティング

この章では、Red Hat Enterprise Linux 仮想化での一般的な問題とその解決策を説明しています。

35.1. 利用可能なストレージとパーティションを判別する

ブロックドライバーがロードされたことと、デバイスとパーティションがゲストに 利用可能であることを確証します。これは、以下に示すように "cat /proc/partitions" を実行することで達成できます。
# cat /proc/partitions
major minor  #blocks   name 
 202    16  104857600  xvdb
   3     0    8175688  hda

35.2. Xen ベースのゲストを再起動した後にコンソールはフリーズ

Occasionally, a Xen guest's console freezes when the guest boots. The console still displays messages but the user cannot log in.
この問題を修復するには、以下の行を /etc/inittab ファイルに 追加します:
1:12345:respawn:/sbin/mingetty xvc0
ファイルを保存したら再起動します。コンソールセッションはこれで期待どおりに 対話型になるはずです。

35.3. 仮想化イーサネットデバイスはネットワーキングツールでは見付からない。

ネットワーキングツールは、ゲストオペレーティングシステム内の Xen Virtual Ethernet ネットワーキングを識別できません。これは以下を実行することにより 確証できます(Red Hat Enterprise Linux 4 及び Red Hat Enterprise Linux 5 用):
cat /etc/modprobe.conf
又は (Red Hat Enterprise Linux 3 用):
cat /etc/modules.conf
その出力は、各追加のインターフェイス用に次の行とそれに似た行を含んでいる はずです。
alias eth0 xen-vnif
この問題を修復するには、エイリアス化の行(例えば、alias eth0 xen-vnif)を ゲストの各 para-virtualized インターフェイスに追加する必要があります。

35.4. ループデバイスエラー

ファイルベースのゲストイメージを使用する場合、設定済みのループデバイスの数量を増加する必要があるかも知れません。デフォルト設定では、8つのループデバイス までがアクティブになる許可があります。もし、8つ以上のファイルベースのゲスト、又はループデバイスを必要とするならば、設定済みのループデバイスの数量は /etc/modprobe.conf で 調節できます。/etc/modprobe.conf を編集して、以下の行を追加します:
                options loop max_loop=64
この例では 64 を使用していますが、他の数字を指定して最大ループ値を設定することができます。また、システム上でループデバイスで支持されているゲストも実装する必要があるかも知れません。para-virtualized ゲスト用にループデバイス支持のゲストを適用するには、phy: block device tap:aio コマンドを使用します。完全仮想化システム用にループデバイス支持のゲストを使用するには、phy: devicefile: file コマンドを使用します。

35.5. メモリー不足によるドメイン作成の失敗

This may cause a domain to fail to start. The reason for this is there is not enough memory available or dom0 has not ballooned down enough to provide space for a recently created or started guest. In your /var/log/xen/xend.log, an example error message indicating this has occurred:
[2006-11-21 20:33:31 xend 3198] DEBUG (balloon:133) Balloon: 558432 KiB free;
	0 to scrub; need 1048576; retries: 20.
[2006-11-21 20:33:52 xend.XendDomainInfo 3198] ERROR (XendDomainInfo:202) Domain construction failed
You can verify the amount of memory currently used by dom0 with the command “xm list Domain-0”. If dom0 is not ballooned down you can use the command “xm mem-set Domain-0 NewMemSize” where NewMemSize should be a smaller value.

35.6. 間違えたカーネルイメージのエラー

Para-virtualized ゲストは kernel-xen カーネルを使用できません。para-virtualized ゲストには、標準のカーネルのみを使用してください。
Attempting to boot any kernel other than the Xen kernel as a para-virtualized guest results in the following error message:
# xm create testVM
Using config file "./testVM".
Going to boot Red Hat Enterprise Linux Server (2.6.18-1.2839.el5)
kernel: /vmlinuz-2.6.18-1.2839.el5
initrd: /initrd-2.6.18-1.2839.el5.img
Error: (22, 'Invalid argument')
In the above error you can see that the kernel line shows that the system is trying to boot a non kernel-xen kernel. The correct entry in the example is ”kernel: /vmlinuz-2.6.18-1.2839.el5xen”.
解決策として、使用するゲストに本当に kernel-xen をインストールしたことを 確認して、それがブートするために /etc/grub.conf 設定ファイル内で デフォルトカーネルになっていることを確認することです。
使用するゲストに kernel-xen をインストールしている場合は、 以下のようにしてゲストを開始できます:
xm create -c GuestName
Where GuestName is the name of the guest. The previous command will present you with the GRUB boot loader screen and allow you to select the kernel to boot. You will have to choose the kernel-xen kernel to boot. Once the guest has completed the boot process you can log into the guest and edit /etc/grub.conf to change the default boot kernel to your kernel-xen. Simply change the line “default=X” (where X is a number starting at '0') to correspond to the entry with your kernel-xen line. The numbering starts at '0' so if your kernel-xen entry is the second entry you would enter '1' as the default,for example “default=1”.

35.7. 間違えたカーネルイメージのエラー:PAE プラットフォーム上に非 PAE カーネル

If you to boot a non-PAE kernel, para-virtualized guest the error message below will display. It indicates you are trying to run a guest kernel on your Hypervisor which at this time is not supported. The Xen hypervisor presently only supports PAE and 64 bit para-virtualized guest kernels.
# xm create -c va-base 
Using config file "va-base".
Error: (22, 'Invalid argument')
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] ERROR (XendDomainInfo:202) Domain construction failed
Traceback (most recent call last):
File "/usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", 
	line 195, in  create vm.initDomain()
File "/usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", 
	line 1363, in initDomain raise VmError(str(exn))
VmError: (22, 'Invalid argument')
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] DEBUG (XendDomainInfo:1449) XendDomainInfo.destroy: domid=1
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] DEBUG (XendDomainInfo:1457) XendDomainInfo.destroyDomain(1)
If you need to run a 32 bit or non-PAE kernel you will need to run your guest as a fully-virtualized virtual machine. The rules for hypervisor compatibility are:
  • para-virtualized のゲストは、使用する hypervisor のアーキテクチャタイプに一致 しなければなりません。32 bit PAE のゲストを実行するには、32 bit PAE hypervisor が 必要になります。
  • 64 bit para-virtualized のゲストを実行するには、Hypervisor も 64 bit の バージョンでなければなりません。
  • 完全仮想化のゲストでは、32 bit ゲスト用に hypervisor は 32 bit か 64 bit の どちらかになります。32 bit 又は 64 bit hypervisor 上で、32 bit (PAE と 非-PAE) の ゲストを実行できます。
  • 64 bit の完全仮想化のゲストを実行するには、使用する hypervisor も 64 bit で ある必要があります。

35.8. 完全仮想化 64 bit ゲストが起動失敗

If you have moved the configuration file to a Red Hat Enterprise Linux 5 causing your fully-virtualized guest to fail to boot and present the error, Your CPU does not support long mode. Use a 32 bit distribution. This problem is caused by a missing or incorrect pae setting. Ensure you have an entry “pae=1” in your guest's configuration file.

35.9. ローカルホストエントリの欠如が virt-manager の失敗原因

virt-manager アプリケーションが起動を失敗して、 “Unable to open a connection to the Xen hypervisor/daemon” と言うようなエラーメッセージを 表示する可能性があります。これは、通常 /etc/hosts ファイル内に localhost エントリが欠如していることが 原因です。実際に localhost エントリが あることを確認して、それが /etc/hosts 内に存在しない場合は、 新規のエントリを挿入します。不正な /etc/hosts の例として以下のような 状態があります:
# Do not remove the following line, or various programs
# that require network functionality will fail.
localhost.localdomain localhost
正しいエントリは以下に似たものになるはずです:
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1               localhost.localdomain localhost
localhost.localdomain localhost

35.10. ゲスト起動時の Microcode エラー

During the boot phase of your virtual machine you may see an error message similar to:
Applying Intel CPU microcode update: FATAL: Module microcode not found.
ERROR: Module microcode does not exist in /proc/modules
As the virtual machine is running on virtual CPUs there is no point updating the microcode. Disabling the microcode update for your virtual machines will stop this error:
/sbin/service microcode_ctl stop
/sbin/chkconfig --del microcode_ctl

35.11. 仮想マシン開始時での Python 低評価警告メッセージ

Python は、時に以下のようなメッセージを生成します。これらのメッセージは無効な,又は不正な 設定ファイルが原因で起こります。非 ascii 文字を含んだ設定ファイルもこれらのエラーになります。 解決策としては、間違えた設定ファイルを修正するか、又は新しいものを生成します。
もう1つの原因は、現在の作業ディレクトリ内の間違えた設定ファイルです。 “xm create” は 作業ディレクトリ内で設定ファイルを 見て、それから /etc/xen で見ます。
# xm shutdown win2k3xen12
# xm create win2k3xen12
Using config file "win2k3xen12".
/usr/lib64/python2.4/site-packages/xen/xm/opts.py:520: DeprecationWarning:
Non-ASCII character '\xc0' in file win2k3xen12 on line 1, but no encoding
declared; see http://www.python.org/peps/pep-0263.html for details
execfile(defconfig, globs, locs)
Error: invalid syntax (win2k3xen12, line 1)

35.12. BIOS 内で、Intel VT と AMD-V の仮想化ハードウェア拡張を有効にする

このセクションでは、ハードウェア仮想化拡張を識別して、無効になっている場合は それらを BIOS 内で有効にする方法を説明しています。
Intel VT 拡張は、BIOS 内で無効にできます。特定のラップトップ製造元は その CPU 内で、デフォルトとして Intel VT 拡張を無効にしています。
仮想化拡張は、AMD-V 用には BIOS 内で無効に出来ません。
The virtualization extensions are sometimes disabled in BIOS, usually by laptop manufacturers. Refer to 「BIOS 内で、Intel VT と AMD-V の仮想化ハードウェア拡張を有効にする」 for instructions on enabling disabled virtualization extensions.
仮想化拡張が BIOS 内で有効になっていることを確認します。Intel® VT 又は AMD-V 用の BIOS 設定は、通常 チップセット 又は プロセッサ メニュー内にあります。メニューの名前は、このガイドとは異なるかも知れませんが、 仮想化拡張の設定は セキュリティ設定 か、他の非標準的なメニュー名内に あるでしょう。
手順35.1 BIOS 内で仮想化拡張を有効にする
  1. Reboot the computer and open the system's BIOS menu. This can usually be done by pressing the delete key, the F1 key or Alt and F4 keys depending on the system.
  2. Select Restore Defaults or Restore Optimized Defaults, and then select Save & Exit.
  3. マシンの電源を切って電源供給を止めます。
  4. Enabling the virtualization extensions in BIOS

    Note: BIOS steps

    Many of the steps below may vary depending on your motherboard, processor type, chipset and OEM. Refer to your system's accompanying documentation for the correct information on configuring your system.
    1. Power on the machine and open the BIOS (as per Step 1).
    2. Open the Processor submenu The processor settings menu may be hidden in the Chipset, Advanced CPU Configuration or Northbridge.
    3. Enable Intel Virtualization Technology (also known as Intel VT) or AMD-V depending on the brand of the processor. The virtualization extensions may be labeled Virtualization Extensions, Vanderpool or various other names depending on the OEM and system BIOS.
    4. Enable Intel VTd or AMD IOMMU, if the options are available. Intel VTd and AMD IOMMU are used for PCI passthrough.
    5. Select Save & Exit.
  5. マシンの電源を切って電源供給を止めます。
  6. cat /proc/cpuinfo | grep vmx svm を実行します。 このコマンドが出力を出せば、仮想化拡張はこれで有効になっています。出力が ない場合は、そのシステムに仮想化拡張が存在しない、又は正しい BIOS 設定が 有効でないことになります。

35.13. KVM ネットワーキングパフォーマンス

デフォルトで、KVM 仮想マシンは仮想 Realtek 8139 (rtl8139) NIC (network interface controller) に 割り当てられています。
rtl8139 仮想化 NIC は ほとんどの環境で正常に機能します。しかし、このデバイスは 一部のネットワーク上(例えば、10 Gigabit Ethernet ネットワーク)でパフォーマンス 劣化問題を被る可能性があります。
回避策としては、仮想化 NIC の異なるタイプに切り替えることです。例えば、 Intel PRO/1000 (e1000) や、あるいは、virtio(para-virtualized ネットワークドライバー)。
e1000 ドライバーに切り替えるには:
  1. ゲストオペレーティングシステムをシャットダウンします。
  2. Edit the guest's configuration file with the virsh command (where GUEST is the guest's name):
    # virsh edit GUEST
    virsh edit コマンドは $EDITOR シェル変数を使用して使用するエディタを決定します。
  3. 設定内でネットワークインターフェイスセクションを見つけます。このセクションは、 以下の snippet に似ています:
    <interface type='network'>
      [output truncated]
      <model type='rtl8139' />
    </interface>
    
  4. Change the type attribute of the model element from 'rtl8139' to 'e1000'. This will change the driver from the rtl8139 driver to the e1000 driver.
    <interface type='network'>
      [output truncated]
      <model type='e1000' />
    </interface>
    
  5. 変更を保存してテキストエディタを終了します。
  6. ゲストオペレーティングシステムを再スタートします。
別の方法では、異なるネットワークドライバーを使用して、新しい仮想化ゲストを インストールする方法があります。ネットワーク接続でゲストのインストールが 難しい場合に、この方法が必要になるかも知れません。この方法では、ユーザーが 既に作成済の仮想化マシンを少なくとも1つ持っていて(多分、CD か DVD でインストール済み) それをテンプレートとして使用することが要求されます。
  1. 既存の仮想マシンから XML テンプレートを作成します:
    # virsh dumpxml GUEST > /tmp/guest.xml
    
  2. XML ファイルをコピーして編集により、特有のフィールドを更新します: 仮想マシン名、 UUID、ディスクイメージ、MAC アドレス、他の特有なパラメータ。UUID と MAC アドレスの 行を削除すると、virsh が UUID と MAC アドレスを生成します。
    # cp /tmp/guest.xml /tmp/new-guest.xml
    # vi /tmp/new-guest.xml
    
    ネットワークインターフェイスセクションにモデルの行を追加します:
     <interface type='network'>
      [output truncated]
      <model type='e1000' />
    </interface>
    
  3. 新しい仮想マシンを作成します:
    # virsh define /tmp/new-guest.xml
    # virsh start new-guest
    
e1000 or virtio ドライバーを使用した方がネットワークパフォーマンスは良くなります。 (BZ#517181)

第36章 Xen para-virtualized ドライバーのトラブルシューティング

この章では、para-virtualized ドライバーを使用する Xen ホストと完全仮想化の Red Hat Enterprise Linux ゲストで遭遇する可能性のある問題を取り扱います。

36.1. Red Hat Enterprise Linux 5 仮想化のログファイルとディレクトリ

/var/log/xen/
xend デーモンと qemu-dm プロセスで生成される 全てのログファイルを保持するディレクトリです。
xend.log
  • このログファイルは、通常のシステムイベントか、オペレータ由来のイベントで 生成された全てのイベントをログするために xend で使用されます。
  • create、shutdown、又は destroy などの仮想マシン操作は全てこの ログファイルにログされます。
  • 通常、このログファイルは問題が発生した時に最初に見るべき場所です。多くの 場合、ログファイルを眺めていき、実際のエラーメッセージの直前にログされた エントリを再確認することにより根本にある原因を識別することができます。
xend-debug.log
  • xend とそのサブシステム(フレームバッファと Python スクリプト)からの エラーイベントを記録します
xen-hotplug.log
  • hotplug イベントからのイベントをログします。
  • オンラインに来ないデバイスや、オンライン上にないネットワークブリッジからの イベント通知はこのファイルにログされます。
qemu-dm.PID.log
  • このファイルは、各完全仮想化のゲストの為に開始した qemu-dm プロセスによって作成されます。
  • PID は、関連した qemu-dm プロセスの プロセス PID で入れ替えるべきものです。
  • 任意の qemu-dm プロセスの PID を 取り込むには、ps コマンドを使用して、qemu-dm が 所属する仮想マシンを識別できるプロセスの引数を見ることで達成できます。
If you are troubleshooting a problem with the virt-manager application you can also review the logfile generated by it. The logfile for virt-manager will be in a directory called .virt-manager in the user's home directory whom ran virt-manager. This directory will usually be ~/.virt-manager/virt-manager.

注記

このログファイルは virt-manager を開始する度に 上書きされます。virt-manager での問題をトラブルシューティング している場合は、エラーが発生した後で、virt-manager を再起動 する前にログファイルを保存することを忘れないで下さい。
/var/lib/libvirt/images/
ファイルベースゲストイメージ用の標準ディレクトリ
/var/lib/xen/xend-db/
デーモンが再開始される度に生成される xend データベースを保持するディレクトリです。
/etc/xen/
Xen hypervisor 用に多くの設定ファイルを格納します。
  • /etc/xen/xend-config.sxp は xend デーモン用の主要設定ファイルです。 xend-config.sxp ファイルは、libvirt で設定されていない他の機能と移行を有効/無効にすることができます。 それ以外の全ての機能には libvirt ツールを使用して下さい。
/var/lib/xen/dump/
仮想マシンで生成されたり、xm dump-core コマンドを 使用した時に生成されるダンプを保管します。
/proc/xen/
以下のファイル内に xen-kernel 情報を格納します:
  • /proc/xen/capabilities
  • /proc/xen/privcmd
  • /proc/xen/balloon
  • /proc/xen/xenbus
  • /proc/xen/xsd_port
  • /proc/xen/xsd_kva

36.2. Para-virtualized ゲストは、Red Hat Enterprise Linux 3 のゲストオペレーティング システム上ではロードに失敗。

Red Hat Enterprise Linux 3 はプロセッサアーキテクチャ特有のカーネル RPM を 使用するため 、para-virtualized ドライバー RPM がインストールされているカーネル アーキテクチャに適合しない場合、para-virtualized ドライバーはロードに 失敗する可能性があります。
When the para-virtualized driver modules are inserted, a long list of unresolved modules will be displayed. A shortened excerpt of the error can be seen below.
# insmod xen-platform-pci.o 
Warning: kernel-module version mismatch
xen-platform-pci.o was compiled for kernel version 2.4.21-52.EL
while this kernel is version 2.4.21-50.EL
xen-platform-pci.o: unresolved symbol __ioremap_R9eac042a
xen-platform-pci.o: unresolved symbol flush_signals_R50973be2
xen-platform-pci.o: unresolved symbol pci_read_config_byte_R0e425a9e
xen-platform-pci.o: unresolved symbol __get_free_pages_R9016dd82
[...]
The solution is to use the correct RPM package for your hardware architecture for the para-virtualized drivers.

36.3. Red Hat Enterprise Linux 3 に para-virtualized ドライバーをインストールする時点に 警告メッセージ。

Red Hat Enterprise Linux 3 に para-virtualized ドライバーをインストールしている時点に、 2.4.21-52 より以前のカーネルでは、「実行中のカーネルよりも新しいバージョンで モジュールがコンパイルされました。」と言う警告メッセージが表示されるようになるでしょう。
以下に示してあるような、このメッセージは無視しても安全です。
Warning: kernel-module version mismatch
xen-platform-pci.o was compiled for kernel version 2.4.21-52.EL
while this kernel is version 2.4.21-50.EL
Warning: loading xen-platform-pci.o will taint the kernel: forced load
See http://www.tux.org/lkml/#export-tainted for information about tainted modules
Module xen-platform-pci loaded, with warnings
上記メッセージの重要な部分は最後の行であり、これはモジュールが警告付きで ロードされたことを述べています。

36.4. para-virtualized ドライバーを手動でロードする

なんらかの理由で、ブートプロセス中に para-virtualized ドライバーが自動的に ロードを失敗する場合は、手動でそれをロードする試みができます。
これにより、ユーザーはネットワークやストレージエンティティを再設定したり、 あるいは、最初にロード失敗した理由を識別することができるようになります。 以下の手順で、para-virtualized ドライバーモジュールをロードできるはずです。
先ず、システム上で para-virtualized ドライバーモジュールの位置を判定します。
# cd /lib/modules/`uname -r`/
# find . -name 'xen_*.ko' -print
その場所の記録を取り、モジュールを手動でロードします。{LocationofPV-drivers} の 部分を上記コマンドの出力から得た正しい場所で入れ替えます。
# insmod \
/lib/modules/'uname -r'/{LocationofPV-drivers}/xen_platform_pci.ko
# insmod /lib/modules/'uname -r'/{LocationofPV-drivers}/xen_balloon.ko
# insmod /lib/modules/'uname -r'/{LocationofPV-drivers}/xen_vnif.ko
# insmod /lib/modules/'uname -r'/{LocationofPV-drivers}/xen_vbd.ko

36.5. para-virtualized ドライバーが正常にロードされたことを確認

実行すべき最初のタスクの1つは、ドライバーが実際にシステム内にロード されたことを確認することです。
After the para-virtualized drivers have been installed and the guest has been rebooted you can verify that the drivers have loaded. First you should confirm the drivers have logged their loading into /var/log/messages
# grep -E "vif|vbd|xen" /var/log/messages
                    xen_mem: Initialising balloon driver
                    vif vif-0: 2 parsing device/vif/0/mac
                    vbd vbd-768: 19 xlvbd_add at /local/domain/0/backend/vbd/21/76
                    vbd vbd-768: 19 xlvbd_add at /local/domain/0/backend/vbd/21/76
                    xen-vbd: registered block device major 202
You can also use the lsmod command to list the loaded para-virtualized drivers. It should output a list containing the xen_vnif, xen_vbd, xen_platform_pci and xen_balloon modules.
# lsmod|grep xen
xen_vbd                19168  1 
xen_vnif               28416  0 
xen_balloon            15256  1 xen_vnif
xen_platform_pci       98520  3 xen_vbd,xen_vnif,xen_balloon,[permanent]

36.6. システムは、para-virtualized ドライバーではスループットに制限があります

If network throughput is still limited even after installing the para-virtualized drivers and you have confirmed they are loaded correctly (refer to 「para-virtualized ドライバーが正常にロードされたことを確認」). To fix this problem, remove the 'type=ioemu' part of 'vif=' line in your guest's configuration file.

Glossary

この語彙集はインストールガイドで使用されている用語を定義する為の ものです。
dom0
Also known as the host or host operating system.
dom0 refers to the host instance of Red Hat Enterprise Linux running the Xen hypervisor. Domain0 facilitates virtualized devices and virtualization for the guest operating systems. Dom0 runs on and manages the physical hardware and resource allocation for itself and the guest operating systems.
Domains
domU and dom0 are both domains. A domain is a term for a guest or virtual machine on the Xen hypervisor. The term domains has a similar meaning to virtual machines and the two are technically interchangeable.
domU
domU refers to the guest operating systems which run on the host system (the dom0 domain).
Hardware Virtual Machine
See Full virtualization.
Hypervisor
The hypervisor is the software layer that abstracts the hardware from the operating system permitting multiple operating systems to run on the same hardware. The hypervisor runs on a host operating system allowing other virtualized operating systems to run on the host's hardware.
The Kernel-based Virtual Machine (KVM) and Xen) hypervisors are provided with Red Hat Enterprise Linux 5.
I/O
入力/出力(input/output)の短縮形です(発音:アイオー)。I/O と言う用語は データをコンピュータと周辺機器との間で転送する全てのプログラム、操作、あるいは デバイスを示します。全ての転送は1つのデバイスからの出力であり、別のデバイスへの 入力となります。キーボードやマウスなどのデバイスは入力のみのデバイスであり、プリンター などのデバイスは出力のみとなります。書き込み可能な CD ROM は入力と出力両方のデバイス です。
Itanium®
Intel Itanium® プロセッサアーキテクチャ
Kernel SamePage Merging
Kernel SamePage Merging (KSM) モジュールは、KVM ゲストが同一のメモリーページ群を共有 できるようにする KVM hypervisor によって使用されます。共有されるページは通常、共通の ライブラリか、又は他の同一の使用頻度の高いデータです。KSM は各種のゲストと 増加続けるゲスト密集のためにキャッシュ内にこれらのライブラリを維持することにより、 特定のゲストのパフォーマンスを増強できます。
Kernel-based Virtual Machine
KVM (Kernel-based Virtual Machine) is a Full virtualization solution for Linux on AMD64 and Intel 64 hardware. VM is a Linux kernel module built for the standard Red Hat Enterprise Linux kernel. KVM can run multiple, unmodified virtualized guest Windows and Linux operating systems. KVM is a hypervisor which uses the libvirt virtualization tools (virt-manager and virsh).
KVM は Linux カーネルモジュールの集合であり、デバイス、メモリー、及び Hypervisor モジュール自身の為の API 管理を管理します。仮想化ゲストは これらのモジュールに制御される Linux のプロセスとスレッドとして実行 されます。
LUN
LUN(Logical Unit Number)は論理ユニット(SCSI プロトコルエンティティ)に 割り当てられた番号です。
MAC アドレス
MAC(Media Access Control)アドレスはネットワークインターフェイスコントローラの ハードウェアアドレスです。仮想化のコンテキストでは、MAC アドレスは、ローカルドメイン上の 各 MAC が特有である状態で仮想ネットワークインターフェイス用に生成されなければなりません。
Para-virtualization
Para-virtualization uses a special kernel, sometimes referred to as the Xen kernel or the kernel-xen package. Para-virtualized guest kernels are run concurrently on the host while using the host's libraries and devices. A para-virtualized installation can have complete access to all devices on the system which can be limited with security settings (SELinux and file controls). Para-virtualization is faster than full virtualization. Para-virtualization can effectively be used for load balancing, provisioning, security and consolidation advantages.
Fedora 9 の時点で、特別なカーネルはもう必要なくなりました。このパッチが 基幹の Linux ツリーに受け入れられてから、このバージョン以降の全ての Linux カーネルは para-virtualization 認識ができて利用可能になっています。
Para-virtualized
See Para-virtualization.
Para-virtualized のドライバー
Para-virtualized のドライバーとは、完全仮想化の Linux ゲスト上で 動作するデバイスドライバーです。これらのドライバーは完全仮想化の ゲスト用にネットワークとブロックデバイスのパフォーマンスを大幅に 向上します。
PCI passthrough
KVM and Xen hypervisors support attaching PCI devices on the host system to virtualized guests. PCI passthrough allows guests to have exclusive access to PCI devices for a range of tasks. PCI passthrough allows PCI devices to appear and behave as if they were physically attached to the guest operating system.
phy device
The phy device parameter allows guest's to access physical disks. Physical disks includes:
  • LVM volumes (for example, /dev/VolGroup00/LogVol02),
  • disk partitions (for example, /dev/sda5), and
  • whole block devices (for example, /dev/sda).
Physical mode provides the best performance as the hypervisor bypasses extra layers of software on the host at the price of slightly less flexibility in managing the device.
Security Enhanced Linux
Security Enhanced Linux の省略名である、SELinux は LSM (Linux Security Modules) を Linux カーネル内で使用して、セキュリティポリシーに必要な各種の最低限特権を提供します。
tap:aio
The tap:aio parameter sets the Xen hypervisor to use an advanced access mode designed for safety and performance. File-based, are accessed using a kernel thread and a user-space process. The tap:aio method respects guest flush requests which makes it safer than the file driver. The virtualization tools use tap:aio by default for accessing file-based guest disks on the Xen Hypervisor.
Universally Unique Identifier
UUID (Universally Unique Identifier) とは、分散型コンピューティング環境の中で デバイス、システム、及び特定のソフトウェアオブジェクトの為の標準化した番号付け 手段です。仮想化の中での UUID のタイプとしては、ext2ext3 のファイルシステムの識別子、 RAID デバイス識別子、iSCSI と LUN の識別子、MAC アドレスと仮想マシンの識別子が あります。
Virtualized CPU
システムは、物理プロセッサコアの数に比較して数多くの仮想 CPU (VCPU) を持ちます。 仮想 CPU の数量は有限であり、ゲスト仮想マシンに割り当て可能な仮想 CPU の 全数を示します。
Xen
Red Hat Enterprise Linux supports the Xen hypervisor and the KVM hypervisor. Both hypervisors have different architectures and development approaches. The Xen hypervisor runs underneath a Red Hat Enterprise Linux operating system which acts as a host managing system resources and virtualization APIs. The host is sometimes referred to as dom0, or Domain0.
ゲストシステム
Also known as guests, virtual machines, virtual servers or domU.
ベアメタル
The term bare-metal refers to the underlying physical architecture of a computer. Running an operating system on bare-metal is another way of referring to running an unmodified version of the operating system on the physical hardware. Examples of operating systems running on bare metal are dom0 or a normally installed operating system.
ホスト
The host operating system, also known as dom0.
The host operating system environment runs the virtualization software for Fully Virtualized and Para virtualized guest systems.
仮想マシン
仮想マシンとは、物理マシンのソフトウェア実装、あるいはプログラミング 言語です(例えば、Java ランタイム環境や LISP)。仮想化のコンテキストでは、仮想マシンは仮想化したハードウェア上で稼働しているオペレーティングシステムと 言う意味になります。
仮想化
Virtualization is a broad computing term for running software, usually operating systems, concurrently and isolated from other programs on one system. Most existing implementations of virtualization use a hypervisor, a software layer on top of an operating system, to abstract hardware. The hypervisor allows multiple operating systems to run on the same physical system by giving the guest operating system virtualized hardware. There are various methods for virtualizing operating systems:
  • Hardware-assisted virtualization is the technique used for full virtualization with Xen and KVM.
  • Para-virtualization is a technique used by Xen to run Linux guests.
  • ソフトウェア仮想化、又は模倣。ソフトウェア仮想化はバイナリトランスレーションと 他の模倣技術を使用して無修正のオペレーティングシステムを実行します。ソフトウェア 仮想化はハードウェア支援の仮想化や para-virtualization よりもかなり遅くなります。 ソフトウェア仮想化は、QEMU の形式であり、Red Hat Enterprise Linux ではサポートが ありません。
Red Hat Enterprise Linux 5 supports hardware-assisted, full virtualization with the Xen and KVM hypervisors and software para-virtualization with the Xen hypervisor for hosting Red Hat Enterprise Linux guests.
完全仮想化
Xen and KVM can use full virtualization. Full virtualization uses hardware features of the processor to provide total abstraction of the underlying physical system (bare metal) and create a new virtual machine in which the guest operating systems can run. No modifications are needed in the guest operating system. The guest operating system and any applications on the guest are not aware of the virtualized environment and run normally. Para-virtualization requires a modified version of the Linux operating system.
完全仮想化した
See Full virtualization.
移行
移行(Migration)とは、仮想化ゲストを1つのホストから別のホストに移動する プロセスの呼び名です。移行はオフラインでも実施できます(ゲストは休止してそれから 移動)。又はライブでも可能です(ゲストは休止せずに移動)。Xen 完全仮想化ゲスト、 Xen para-virtualized ゲスト、及び KVM 完全仮想ゲストは全て移行できます。
移行は仮想化の基幹機能です。ここではソフトウェアが完全にハードウェアから 分離されています。移行は以下の部分で役に立ちます:
  • ロードバランシング:ホストがロード超過になった時点で、ゲストは使用度の低い 別のホストへと移動されます。
  • ハードウェアフェイルオーバー:ホスト上のハードウェアデバイスがスタートに 失敗すると、ゲストは移動してホストが安全に停止と修理をできるようになります。
  • 節電:低使用の期間にはゲスト群は他のホスト群に分配できるため、主ホストシステムは 電力を落として、節電とコスト低減ができます。
  • 地域的な移行:より少ない遅延の為や、重大な事態の場合にはゲストは他の 場所に移動できます。
共有のネットワークストレージがゲストイメージの保存に使用されます。共有 ストレージ無しでは移行は不可能です。
オフライン移行はゲストを休止して、それからゲストのメモリーのイメージを 移動先のホストに移動します。ゲストは移動先ホスト上で再開始されて、移動前の ホスト上でゲストが使用したメモリーは開放されます。
オフライン移行にかかる時間はネットワークのバンド幅と遅延により変化します。 2GB のメモリーを持つゲストは、1 Gbit のイーサネットリンク上で数秒かかる でしょう。
A live migration keeps the guest running on the source host and begins moving the memory without stopping the guest. All modified memory pages are monitored for changes and sent to the destination while the image is sent. The memory is updated with the changed pages. The process continues until the amount of pause time allowed for the guest equals the predicted time for the final few pages to be transfer. KVM estimates the time remaining and attempts to transfer the maximum amount of page files from the source to the destination until KVM predicts the amount of remaining pages can be transferred during a very brief time while the virtualized guest is paused. The registers are loaded on the new host and the guest is then resumed on the destination host. If the guest cannot be merged (which happens when guests are under extreme loads) the guest is paused and then an offline migration is started instead.
ライブ移行にかかる時間はネットワークのバンド幅と遅延度と、更にはゲスト上の 活動にも影響されます。ゲストがかなりの量の I/O 又は CPU を使用している場合、 移行にはより時間がかかります。

その他のリソース

仮想化と Red Hat Enterprise Linux についての詳細を見るには、以下のリソースを 参照して下さい。

A.1. オンラインリソース

  • http://www.cl.cam.ac.uk/research/srg/netos/xen/ Red Hat kernel-xen パッケージの抽出元である Xen™ para-virtualization マシンマネージャの プロジェクトウェブサイトです。このサイトはアップストリームの xen プロジェクトバイナリとソース コードを維持し、また xen とその関連技術に関する情報、アーキテクチャ概要、ドキュメント、及び 関連リンクも含んでいます。
  • Xen コミュニティウェブサイト
  • http://www.libvirt.org/libvirt 仮想化 API の為の正式ウェブサイトです。
  • http://virt-manager.et.redhat.com/ 仮想マシンの管理用のグラフィカルアプリケーションである 仮想マシンマネージャ(Virtual Machine Manager) (virt-manager)のプロジェクト WEB サイトです。

A.2. インストール済みドキュメント

  • /usr/share/doc/xen-<version-number>/ このディレクトリには、Xen para-virtualization hypervisor と設定の参考例、ハードウェア特有の情報、現在の Xen のアップストリームユーザードキュメントなどを含む、関連した管理ツールに関する豊富な情報が含まれています。
  • man virsh/usr/share/doc/libvirt-<version-number> — には、virsh 仮想マシン管理ユーティリティ用のサブコマンドと オプションと、更には libvirt 仮想化ライブラリ API に関する 総括的な情報が含まれています。
  • /usr/share/doc/gnome-applet-vm-<version-number> — ローカルで実行している仮想マシンを監視して管理するGNOME グラフィカルパネルアプレット用のドキュメントがあります。
  • /usr/share/doc/libvirt-python-<version-number>libvirt ライブラリ用の Python バインディングについての詳細を提供します。libvirt-python パッケージにより、Python の開発者は libvirt virtualization 管理ライブラリを持つインターフェイスのプログラムを作成することが出来るようになります。
  • /usr/share/doc/python-virtinst-<version-number>virt-install コマンドに関するドキュメントを提供します。このコマンドは仮想マシン内の Fedora と Red Hat Enterprise Linux 関連のディストリビューションのインストール開始を援助するものです。
  • /usr/share/doc/virt-manager-<version-number> — 仮想マシンマネージャに関するドキュメントを提供します。仮想マシンマネージャは仮想マシン管理用のグラフィカルツールです。

Colophon

このマニュアルは DocBook XML v4.3 形式で書かれています。
This book is based on the work of Jan Mark Holzer, Chris Curran and Scott Radvan.
その他の著作クレジット:
  • Don Dutile は para-virtualized ドライバーセクションの技術編集に貢献。
  • Barry Donahue は para-virtualized ドライバーセクションの技術編集に貢献。
  • Rick Ring は仮想マシンマネージャセクションの技術編集に貢献。
  • Michael Kearey は virsh 及び 仮想化フロッピードライブでの XML 設定ファイル使用に関する セクションの 技術編集に貢献。
  • Marco Grigull は ソフトウエア互換性とパフォーマンスセクションの技術編集に貢献。
  • Eugene Teo は virsh セクションでのゲスト管理の技術編集に貢献。
このマニュアルを作成した発行ツール、Publican は Jeffrey Fearn によって 書かれました。
Red Hat ローカリゼーションチームは以下の人々で構成されています:
  • 簡体中国語
    • Leah Wei Liu
  • 繁体中国語
    • Chester Cheng
    • Terry Chuang
  • 日本語
    • Kiyoto Hashida
  • 韓国語
    • Eun-ju Kim
  • フランス語
    • Sam Friedmann
  • ドイツ語
    • Hedda Peters
  • イタリア語
    • Francesco Valente
  • ブラジル系ポルトガル語
    • Glaucia de Freitas
    • Leticia de Lima
  • スペイン語
    • Angela Garcia
    • Gladys Guerrero
  • ロシア語
    • Yuliya Poyarkova