KVM 仮想化を使用する

最新世代の Linux 仮想化技術である、カーネルベースの仮想マシンを使い始める

ほとんどの Linux システムでは、仮想マシン (VM) を作成およびサポートするためのデフォルトのオープンソース・メカニズムを、これまで使用していた Xen からカーネルベースの仮想マシン (KVM: Kernel-based Virtual Machine) へと大々的に置き換えています。こうした変化の背景にあるのは、技術に関する問題ではなく、主にビルドやサポートに関する問題ですが、仮想化に関心を持つ多くの企業の IT グループは現実問題として、KVM に使用される管理コマンドや制御ツールについて学ぶ必要があります。同様に、既に Xen 仮想化に投資をしていて KVM に移行しようとする IT 企業は、VM を作り直すのではなく、可能な限り既存の VM を KVM でサポートされるフォーマットに変換する必要があります。

William von Hagen, Systems Administrator, Writer, WordSmiths

William von Hagen は、1993年以来の Linux 支持者で、ライターおよび UNIX システム管理者としての経験は 20 年を超えます。Bill は、Ubuntu Linux、Xen 仮想化、GCC (GNU Compiler Collection)、SUSE Linux、Mac OS X、Linux ファイルシステム、SGML などに関する書籍の著者または共著者です。彼はまた、Linux および Mac OS X の出版物や Web サイトにも多数の記事を掲載しています。



2014年 4月 24日

今日の IT インフラストラクチャーでは、単一のサーバー・ハードウェア・プラットフォーム上で複数の仮想マシン (VM) を実行できると、コスト、システム管理、柔軟性の点でメリットがあります。単一のハードウェア・プラットフォーム上に複数の VM をホストすることで、ハードウェアにかかる経費が削減され、電力消費や冷房などのインフラストラクチャー・コストを最小限にすることができ、またオペレーションが異なるシステムを VM として単一のハードウェア・プラットフォーム上に統合すると、オープンソースの仮想化ライブラリー (libvirt) などの管理レイヤーや libvirt ベースのツール (グラフィカル VMM (Virtual Machine Manager) など) を利用して、これらのシステムの管理を単純化することができます。仮想化によって、今日のサービス指向かつ高可用の IT 運用に必要な、運用上の柔軟性が実現されます。例えば、ハードウェアまたは物理設備の問題で、稼働状態の VM をある物理ホストから別の物理ホストへマイグレーションすることが要求されたときにマイグレーションすることや、増大するプロセッサーおよびメモリーの要件に応じるため、あるいはロード・バランシングを通じて、パフォーマンスを増大することなどが可能になります。

オープンソースのデスクトップ仮想化アプリケーション (VirtualBox など) を利用すると、ユーザーさらには一部の小規模な企業 (中小規模のビジネスや中小企業) の環境では、単一の物理システム上で複数の VM を実行することができます。ただし VirtualBox などの仮想化環境は、デスクトップ・システムまたはサーバー・システム上のクライアント・アプリケーションとして実行されます。企業のコンピューティング環境として要求されるのは、ハイパフォーマンスでサーバー指向の仮想化環境で、物理ハードウェア (「ベアメタル」) に近く、VM を実行する際のオペレーティング・システムのオーバーヘッドが極めて小さい環境です。ベアメタル仮想化メカニズムは、ハードウェア・リソースをより適切に管理することができ、ほとんどの 64 ビット x86 プロセッサーや PowerPC プロセッサーに組み込まれた、ハードウェアとしての仮想化サポートを最も効果的に活用することができます。

ベアメタル仮想化メカニズムは、ハイパーバイザーとして知られる小規模なオペレーティング・システムを使用して VM と VM 関連リソースを管理、スケジューリングします。ベアメタル・ハイパーバイザーは、タイプ 1 ハイパーバイザーとして知られています (ハイパーバイザーに関する一般的な情報は、「参考文献」のリンクを参照)。オープンソースのベアメタル仮想化技術として最もよく使用されているのは KVM (Kernel Virtual Machine) と Xen です。Xen と KVM はどちらも優れた点があり、熱心な支持者がいますが、KVM の方がよく使用されて洗練されてきており、今やほとんどの Linux ディストリビューションで推奨されるデフォルト仮想化メカニズムとなっています。

KVM と Xen の比較

これまで Xen 仮想化環境 (「参考文献」のリンクを参照) は、Linux システム上で最高パフォーマンスのオープンソース仮想化技術を Linux システムに提供してきました。Xen はハイパーバイザーを使用して VM と VM 関連リソースを管理し、また準仮想化をサポートしています (準仮想化は、仮想化されていることを認識している VM 内で、より高いパフォーマンスを実現することが可能です)。Xen は、リソース管理と仮想管理、そしてスケジューリング専用のオープンソースのハイパーバイザーを備えています。Xen ハイパーバイザーは、ベアメタル物理ハードウェア上で起動されると、Domain0 または管理ドメインと呼ばれるプライマリー VM を起動し、この VM が、その物理ホスト上で実行される他のすべての VM (Domain1 から DomainN、または単純に Xen ゲストと呼ばれます) を集中管理します。

Xen とは異なり、KVM 仮想化は Linux カーネルをハイパーバイザーとして使用します。KVM 仮想化は、メインライン Linux カーネルの 2.6.20 リリース以降のバージョンではデフォルトでサポートされるようになっています。Linux カーネルをハイパーバイザーとして使用するという点は、KVM に対する批判の一番のポイントとなっています。これは、Linux カーネルは (デフォルトでは) タイプ 1 ハイパーバイザーに対する従来の定義 (「小規模のオペレーティング・システム」) を満たさないからです。この事実は、ほとんどの Linux ディストリビューションのデフォルト・カーネルに言えることですが、Linux カーネルをコンパイル後のサイズが小さくなるように構成することで、タイプ 1 ハイパーバイザーとして動作する上で必要な機能やドライバーのみが提供されるようにすることは簡単です。Red Hat 独自の Enterprise Virtualization ソリューションは、まさにそのような、特別に構成された比較的軽量の Linux カーネルを使用しています。しかしもっと重要なこととして、「小規模」という表現は相対的であり、何ギガバイトものメモリーを搭載している今日の 64 ビット・サーバーであれば、最新の Linux カーネルが必要とする数メガバイトのメモリーを十分に提供できる余裕があります。

ほとんどのエンタープライズ環境でオープンソースのベアメタル仮想化技術として、Xen よりも KVM が選択される理由はいくつかあります。

  • 2.6.20 リリース以降、KVM のサポートはすべての Linux カーネルに自動的に組み込まれています。リリース 3.0 以前の Linux カーネルでは、Xen サポートを統合するためには大がかりなパッチを当てる必要があり、たとえパッチを当てたとしても、考えられるすべてのハードウェア機器に対し、すべてのドライバーが Xen 環境で適切に動作すると保証されているわけではありません。
  • Xen をサポートするために必要なカーネル・ソース・コードのパッチは、特定のカーネル・バージョンに対してのみ提供されていました。そのため Xen 仮想化環境では、他のカーネル・バージョンのみで利用可能な新しいドライバー、サブシステム、カーネル修正、機能強化を利用することができませんでした。KVM は Linux カーネルに統合されているため、新しいバージョンの Linux カーネルに加えられた改善をすべて自動的に利用することができます。
  • Xen の場合、特別に構成された Linux カーネルが VM 用の物理サーバー上で稼働している必要があり、そのサーバーはサーバー上で実行されるすべての Xen VM に対する管理ドメインとして機能する必要があります。KVM は、その物理システム上で実行されている Linux VM の中で使用されているのと同じカーネルを、物理サーバー上で使用することができます。
  • Xen のハイパーバイザーは、Xen がホストするオペレーティング・システムからは独立したスタンドアロンのソース・コードになっており、そのオペレーティング・システムに存在する欠陥とは無関係の、Xen のハイパーバイザー独自の欠陥が存在します。KVM は Linux カーネルの一部として統合されているため、KVM を KVM ハイパーバイザーとして使用する場合に影響を及ぼす可能性があるのは、カーネルの欠陥のみです。

Xen は相変わらず KVM よりもハイパフォーマンスのベアメタル仮想化技術ですが、そのようにパフォーマンスが優れていることの価値よりも、KVM 仮想化の単純さや使いやすさが重視されることの方が多くなっています。


KVM と Xen に共通の管理ツール

KVM よりも成熟したベアメタル仮想化技術として、Xen には独自の特殊な管理コマンド・セットがあり、なかでも最も注目に値するのが xm コマンドライン・スイートです。他の技術に専用の管理コマンド・セットと同じく、xm ツールにはこのツール特有の学習曲線があり、Linux システム管理者の誰もが xm について知っているわけではありません。KVM は、初期管理インフラストラクチャーの大部分を QEMU から継承しています。Linux のエミュレーションおよび仮想化パッケージとして十分な実績がある QEMU は、xm ツールと同じように学習曲線があり、いくらか特殊な知識を必要とします。

ユニークな技術に独自のコマンド・セットがあるのは自然なことですが、仮想化技術の数が増えるにつれ、Linux ベンダーはそれらのすべてに使用できる 1 つの管理インターフェースを求め始めました。Red Hat がオープンソース企業として初の十億ドル規模の企業となったのにはそれなりの理由があり、Red Hat では複数の仮想化技術を管理するための開発ツールをサポートするために、libvirt 仮想化 API (Application Programming Interface) を開発する作業を主導しました。libvirt API がサポートする仮想化技術には、KVM、Xen、LXC コンテナー、OpenVZ、User-mode Linux、VirtualBox、Microsoft Hyper-V、その他多くの VMware 技術があります。

システム管理者は 1 つの技術とその関連コマンド・セットに賭けるのではなく、libvirt にフォーカスして、libvirt API を使用するコマンドラインのコマンドやグラフィカル・コマンドを 1 セット学びさえすれば、ベースとなる仮想化技術が変わっても、これらのツールを使い続けることができます。同様に、仮想化ツールのベンダーも libvirt API を直接使用することで同じメリットを享受することができます。

この後のいくつかのセクションでは、KVM ベースの仮想化サイトの一般的な管理タスクを libvirt ベースのツールで単純化する一般的な方法について説明します。これらのセクションでは、virsh コマンドと virt-install コマンドを使用するコマンドラインの例に焦点を絞りますが、これらのタスクはすべて libvirt ベースのグラフィカルな VMM (virt-manager) でも実行することができます。これらのコマンドはすべて、root ユーザーとして (または sudo コマンドを介して) 実行する必要があります。

この記事でこれから紹介する例では、皆さんの Linux ディストリビューションに適切なパッケージがインストールされており、KVM 仮想化がサポートされ、必要なツールが提供されているものとします。必要なパッケージは Linux プラットフォームによって異なります。例えば、Red Hat Enterprise Linux (RHEL) システム (または RHEL クローン) には、Virtualization、Virtualization Client、Virtualization Platform、Virtualization Tools の各パッケージ・グループがインストールされている必要があります。


ストレージ・プールを使用する

単純な KVM VM を作成する方法についての developerWorks の記事 (「参考文献」のリンクを参照) では、対象の VM をサポートするサーバーのローカル・ディスク・ストレージでディスク・イメージを作成し、そのイメージを使用して VM をインストールする方法を説明しています。ディスク・イメージとして機能する各ローカル・ファイルを手作業で作成する方法は、最初に VM を試す方法として一般的ですが、退屈で時間がかかり、管理が困難な作業になりがちです。

libvirt には、VM イメージやファイルシステムの場所を抽象化するための便利な機能が用意されており、この機能は「ストレージ・プール」として知られています。ストレージ・プールlibvirt が管理するローカル・ディレクトリー、ローカル・ストレージ・デバイス (物理ディスク、論理ボリューム、または SCSI ホスト・バス・アダプター (HBA) ストレージ)、NFS (Network File System)、またはブロック・レベルのネットワーク・ストレージであり、この中に 1 つまたは複数の VM イメージを作成、格納することができます。ローカル・ストレージは単純ですが、柔軟性がなく、エンタープライズ仮想化に最も必要な機能、つまり稼働中の VM をサーバー間でマイグレーションする、「ライブ・マイグレーション」として知られる機能をサポートすることができません。ライブ・マイグレーションを容易にサポートするには、VM のディスク・イメージは複数の VM ホストから利用可能な NFS、ブロック・レベルのネットワーク・ストレージ、または HBA ストレージの中になければなりません。

このセクションの例では virsh コマンドを使用します。virsh コマンドは libvirt ベースのコマンド・スイートであり、libvirt が使用するすべてのオブジェクトの作成、管理のための個々のサブコマンドが含まれています (これらのオブジェクトには、VM (ドメイン)、ストレージ・ボリューム、ストレージ・プール、ネットワーク、ネットワーク・インターフェース、デバイスなどがあります)。

デフォルトで libvirt ベースのコマンドは、初期ファイルシステム・ディレクトリー・ストレージ・プールとして、仮想化ホスト上の /var/lib/libvirt/images ディレクトリーを使用します。virsh pool-create-as コマンドを使用すると、新しいストレージ・プールを容易に作成することができます。例えば、以下のコマンドは NFS ベースの (netfs) ストレージ・プールを作成する際に指定しなければならない必須パラメーターを示しています。

virsh pool-create-as NFS-POOL netfs \
--source-host 192.168.6.238 \
--source-path /DATA/POOL \
--target /var/lib/libvirt/images/NFS-POOL

1 番目の引数 (NFS-POOL) は新しいストレージ・プールの名前を指定し、2 番目の引数は作成するストレージ・プールのタイプを指定します。--source-host オプションの引数は NFS を介してストレージ・プール・ディレクトリーをエクスポートするホストを指定します。--source-path オプションの引数は、そのホスト上でエクスポートされるディレクトリーの名前を指定します。--target オプションの引数は、ストレージ・プールへのアクセスに使用されるローカル・マウント・ポイントを指定します。

新しいストレージ・プールを作成すると、そのストレージ・プールは virsh pool-list コマンドの出力に表示されます。以下の例は、デフォルトのストレージ・プールと、上記の例で作成されたプールである NFS-POOL プールを示しています。

virsh pool-list --all --details
Name        State    Autostart  Persistent   Capacity  Allocation  Available
----------------------------------------------------------------------------
default     running  yes        yes          54.89 GB    47.38 GB    7.51 GB
NFS-POOL    running  no         no          915.42 GB   522.64 GB  392.78 GB

この出力例で注意すべき点は、新しいストレージ・プールが自動起動なしとマーキングされており (つまりこのストレージ・プールはシステム再起動後に自動的に使用可能になるわけではありません)、また永続的でもありません (つまりこのストレージ・プールは、システムの再起動後は定義されていない状態です)。ストレージ・プールが永続的となるのは、/etc/libvirt/storage ディレクトリーに置かれたそのストレージ・プールの XML 記述ファイルに明記されている場合のみです。ストレージ・プールについて記述する XML ファイルは (その XML ファイルと関連付けられる) ストレージ・プールと同じ名前を持ち、ファイル拡張子は .xml です。

手作業で定義されたストレージ・プール用の XML 記述ファイルを作成するには、virsh pool-dumpxml コマンドを使用し、XML 記述ファイルをダンプ出力するストレージ・プールの名前を最後の引数として指定します。このコマンドの結果は標準出力に出力されるため、この出力を適切なファイルにリダイレクトする必要があります。例えば、以下のコマンドは先ほど作成した NFS-POOL というストレージ・プールに対する適切な XML 記述ファイルを作成します。

cd /etc/libvirt/storage
virsh pool-dumpxml NFS-POOL > NFS-POOL.xml

ストレージ・プールを永続的なものとしてマーキングしたとしても、仮想化ホストが再起動されたときにプールが自動的に起動されるようにマーキングされるわけではありません。virsh pool-autostart コマンドを使用し、このコマンドの後にストレージ・プールの名前を指定することにより、ストレージ・プールが自動起動するように設定することができます。以下の例を見てください。

virsh pool-autostart NFS-POOL
Pool NFS-POOL marked as autostarted

ストレージ・プールが自動起動されるようにマーキングするということは、そのストレージ・プールは仮想化ホストが再起動されると必ず使用可能になるということです。技術的に言えば、そのストレージ・プールの XML 記述ファイルへのシンボリック・リンクが /etc/libvirt/storage/autostart ディレクトリーに含まれているということです。

ストレージ・プールを作成すると、そのプールに 1 つまたは複数の VM を作成することができます。これについては次のセクションで説明します。


VM を作成する

このセクションの例では、前のセクションで作成したストレージ・プールを使用しますが、今度は virt-install コマンドを使用します。virt-install コマンドは libvirt ベースのコマンドであり、名前からもわかるように、コマンドラインから VM を作成できるように設計されています。

以下の例では、virt-install コマンドを使用して RHEL-6.3-LAMP というハードウェア VM を作成します。この VM の名前からもわかるように、この VM は RHEL 6.3 を実行し、標準的な Linux Web サーバーとして使用されています。新しいディスク・プール・ボリュームを作成する際にはデフォルトで VM の名前が使用されるため、名前の選択には注意が必要です。VM の名前はローカルの命名規則に従うのが一般的であり、同僚の管理者が各 VM のタイプや目的を容易に理解できるように名前を付ける必要があります。

virt-install --name RHEL-6.3-LAMP \
--os-type=linux \
--os-variant=rhel6 \
--cdrom /mnt/ISO/rhel63-server-x86_64.iso \
--graphics vnc\
--disk pool=NFS-01,format=raw,size=20 \
--ram 2048 \
--vcpus=2 \
--network bridge=br0 \
--hvm \
--virt-type=kvm \

virt-install コマンドの他のオプションから、この VM が Linux および RHEL6 Linux ディストリビューション用に最適化されており (それぞれ --ostype--osvariant)、ISO イメージ /mnt/ISO/rhel63-server-x86_64.iso を使用して仮想 CD-ROM デバイス (--cdrom) としてインストールされることがわかります。仮想 CD-ROM ドライブからブートする場合、virt-install コマンドは VNC (Virtual Network Computing) プロトコルを使用して、グラフィカル・コンソール (--graphics) を作成して表示しようと試み、このコンソールの中でブート・プロセスやブート後のインストール・プロセスが実行されます。このコンソールへの接続方法は仮想化サーバーへの接続方法や、仮想化サーバーのグラフィカル機能の有無などに依存するため、この記事では説明を省略します。

--disk オプションの引数は、20GB のストレージに VM が作成されるように指定しており、この領域は先ほどのセクションで作成した NFS-POOL ストレージ・プールから自動的に割り当てられます。この VM のディスク・イメージは raw イメージ・フォーマットで作成されます。このフォーマットは大部分の仮想化技術やエミュレーション技術の間での移植性が高い単純なディスク・イメージ・フォーマットです。(サポートされている他のイメージ・フォーマットについては、「参考文献」に挙げた libvirt の「Storage Management」ページへのリンクを参照。)

virt-install コマンドの他の引数について説明すると、この新しい VM は、最初は 2GB のメモリー (--ram) と 2 つの仮想 CPU (--vcpus) で構成され、ネットワーク・ブリッジ br0 (--network) を介してネットワークにアクセスします。ネットワーク・ブリッジの作成方法については、「参考文献」に挙げた developerWorks の記事「KVM ベースの仮想サーバーを作成する」へのリンクを参照してください。

virt-install コマンドの最後の 2 つのオプションは、完全仮想化システムとして使用できるように VM を最適化し (--hvm)、新しい VM をサポートするハイパーバイザー (--virt-type) が KVM であることを示しています。この両方のオプションにより、VM 作成プロセスやオペレーティング・システムのインストール・プロセスの際に一定の最適化が行われます。実際、これらのオプションが指定されていない場合、これらのオプションがデフォルトの値になります。VM のインストールに関するコマンド・ログを保持する場合には、この 2 つのオプションを明示的に指定するのが適切なプラクティスです。そうすることで各 VM の仮想化環境に関する情報をログに記録できるからです。

上記と同じようなコマンドを使用して、VM に適切な名前を指定し、--cdrom--os-type--os-variant オプションの引数を適切に変更することにより、別のオペレーティング・システムを実行する VM を作成することができます。


まとめ

Linux ベースでオープンソースの仮想化技術は継続的に開発が行われています。KVM は使いやすく、開発も続けられていることから、オープンソースの Linux 仮想化技術の標準として、KVM よりも強力な潜在能力を持つ Xen 仮想化技術を置き換えるようになっています。どのような仮想化技術を選ぶかにかかわらず、こうした進化は、libvirt 仮想化 API が提供するような、標準的で技術に依存しない管理コマンドを使用する価値を際立たせています。

この記事では、libvirt ベースのコマンドを使用して VM へのストレージの割り当てや、そのストレージでの VM のインストールを単純化する方法についての例を挙げましたが、libvirt API や自由に使用できる libvirt ベースのコマンドによって提供される多くの管理機能のほんの一部を説明したにすぎません。

参考文献

学ぶために

製品や技術を入手するために

  • libvirt Virtualization API Web サイトは、この API についての詳細な情報や、この API がサポートする仮想化抽象化、さらにはこの API が使用する XML フォーマットについての詳細な情報を提供しています。
  • KVM のホームページは、KVM についての詳細な情報や、実にさまざまな種類の情報ソースおよび関連サイトへのリンクを提供しています。
  • Xen のホームページは、Xen ハイパーバイザーと関連する技術についての全般的な情報を提供しています。
  • VirtualBox のホームページは、ドキュメントへのリンクや、家庭および小規模のエンタープライズ・レベルの仮想化を対象とした VirtualBox ソフトウェアの最新版のダウンロードを提供しています。
  • IBM 製品の評価をご自分に最適な方法で行ってください。評価の方法としては、製品の評価版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。

議論するために

  • developerWorks コミュニティーに参加してください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者によるブログ、フォーラム、グループ、Wiki を調べることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=967831
ArticleTitle=KVM 仮想化を使用する
publish-date=04242014