多くのシステム管理者にとって悩みの種の1つは、ベースオペレーティングシステムの新しいバージョンが導入されたときに必要となる大掛かりなテストと認定作業です。新しいソフトウェアの利点は、大部分のアプリケーションにはほとんど関係ありませんが、特定のアプリケーションや特定の新しいハードウェアオプションに対応するために必要となるような場合もあります。

仮想化は、こうした問題からの回避手段を提供します。既存のスタックは、仮想マシン内のゲストとして引き続きそのまま実行できます。一方、新しいハードウェアは最新のhypervisorによってサポートされ、信頼性とパフォーマンスも向上します。新しいバージョンのオペレーティングシステムを必要とするいくつかのアプリケーションは、最新バージョンの別の仮想マシン上で実行できます。

つまり、アップグレードを実行する必要があるのは、システム管理者が望んだときだけです。コストのかかる、計画外のソフトウェアアップグレードを強制されることはもうありません。

システムが特定のアプリケーション専用であれば厳重に保護できますが、今日の多くのシステムは共有アクセスを行っているため、プライバシを保証することが重要です。

仮想化を利用すると、各アプリケーションとデータセットを別々の仮想マシンに配置できます。これには、ハードウェアを増やすことなく各物理システムを保護できる多くの利点があります。仮想化ではゲストがそれぞれ分離されているため、各ゲストは望ましくない共有の影響をはるかに受けにくくなります。攻撃が成功した場合でも、その影響は侵入された1つのゲストに限られます。SELinuxおよびRed Hat Identity Managementと組み合わせれば、ユーザごとに独立したサーバを用意しなくても、高度なユーザおよびデータ分離を実現できます。

ソフトウェア開発には、コーディング、デバッグ、およびテストを何度も繰り返す長いサイクルが必要です。以前は、デバッグとテストに多くの個別システムが必要になることがよくありました。テストに必要とされる大規模なネットワークとデータセットを作り上げることには困難が伴いました。仮想化は、多くのソリューションを提供します。

開発者には、互いに影響を与えることなく起動、停止が可能な、個人用の仮想マシンを割り当てることができます。開発者に個人用の物理マシンはもう必要ありません。これによって、カーネルコードを含めたコードのデバッグが大きく改善されます。

仮想マシンは容易にすばやく起動、停止、および変更できるため、多数のリグレッションテストを自動化することが可能です。さまざまなバージョンのアプリケーションとオペレーティングシステムについてスクリプトを準備し、既知のデータセットでそれらを実行し、結果をプロットおよびレポートできます。システムがダウンした場合はスクリプトで検出できます。これは、ベースのDOM 0ではなくゲストがクラッシュするだけです。

多数のシステムを使用する必要があるときは、少数の物理サーバで複数のネットワーク接続ゲストを立ち上げ、大規模な物理ネットワークをシミュレートできます。これによって、現在はほとんど行われていないスケーラビリティテストが可能になります。実は、低負荷の時間帯に、使用されていない実稼働マシンを投入すれば、各ゲストがセキュリティ機能とファイアウォールで保護されているため、安全にテストを行うことができます。

ライブ移行を実施すれば、ネットワーク経由で1つの物理サーバから別のサーバへ、Red Hat Enterprise Linuxバージョン5上のパラバーチャリゼーションゲストを移行できます。ゲストが（標準のRed Hat enterprise Linux管理ツールを使用するシステム管理者、またはプログラムによって）移動を強制されると、「from」システム上のhypervisorは「to」システム上のhypervisorと連携して、移行ゲストの収容に十分なメモリを準備します。次に、メモリがネットワーク経由でコピーされ、「ホット」メモリだけが残ります。「from」マシン上のゲストは依然として動作し、ゲストにサービスを提供しているため、「ホット」メモリをその使用するメモリとして定義します。

さらに、「from」hypervisorはそのゲストを停止し、残りのホットメモリをコピーします。その後、「to」マシン上のhypervisorはそのゲストを動作させます。コピーされたメモリ内でネットワークおよびI/O接続がすべて維持されるため、これらの接続はすべて永続的であり、ごく短時間（200ミリ秒未満）停止するだけで、ジョブはお客様へのサービス提供を継続します。ただし、ネットワークソケットが持続するためには、各システムが同一サブネットに属している必要があり、開かれたファイルを維持するには、ストレージが共有されている必要があります。ロックマネージャは不要であり、iSCSI、GNDB、または任意のSANが問題なく機能します。

ライブ移行が行われる理由は数多くあります。

1. あるゲストの利用率が高くなった場合、そのゲストを新しいマシンに移行するか、そのマシン上の他のゲストを退去させて、負荷の高いゲストに追加のリソースを提供します。
2. あるシステムがメモリ内のソフトエラーの警告、過熱の警告、またはその他の障害発生を予告する警告を発行し始めます。シャットダウンする前にゲストを退避させれば、そのサーバは解放され、メンテナンスを行うことができます。
3. ERPや金融システムによく見られる大規模なバッチストリームを実行する場合は、事前にゲストをサーバから退去させて容量を準備できます。また、ゲストを数台のマシンに統合することによって、過剰な容量を削減して消費電力を節約することもできます。

多数のゲストを作成し、ゲスト単位で機能を実行することの大きな理由は、クラッシュが発生した場合のドミノ効果を最小限に抑えることです。多くの場合、大規模なSMPシステム上の1つのジョブがクラッシュすると、そのシステム上のすべてのハブがクラッシュまたはハングします。Red Hatの仮想化では、各機能を専用のゲスト内に配置できます。

そうすれば、障害やセキュリティ問題が発生しても、異常は外部に波及せず、影響はそのゲストのみにとどまります。移行とHAクラスタソフトウェアをうまく利用すれば、いずれかのゲストまたは作業負荷に問題が発生した場合に備えて、すぐに実行可能なインスタンスを他のマシン上に待機させておくことも容易です。