vSphere 5.1へのP2VとConverter Standalone
4/25付けで、vCenter Converter Standalone 5.1がリリースされました。
VMware vCenter Converter Standalone Release Notes
以下、リリースノートの「What's New」からの抜粋です。
The VMware vCenter Converter Standalone 5.1 includes the following new functionality:
・Support for virtual machine hardware version 9
・Guest operating system support for Microsoft Windows 8 and Microsoft Windows Server 2012
・Guest operating system support for Red Hat Enterprise Linux 6
・Support for virtual and physical machine sources with GUID Partition Table (GPT) disks
・Support for virtual and physical machine sources with Unified Extensible Firmware Interface (UEFI)
・Support for EXT4 file system
また、このバージョンでようやくvSphere 5.1がサポートされました。
vSphere 5.1の環境にConverterでP2Vを行う場合、この新しいバージョンでないとサポートされない、ということになります。
旧バージョンはvSphere 5.0までのサポートなので、注意が必要ですね。
VMware vCenter Converter Standalone Release Notes
以下、リリースノートの「What's New」からの抜粋です。
The VMware vCenter Converter Standalone 5.1 includes the following new functionality:
・Support for virtual machine hardware version 9
・Guest operating system support for Microsoft Windows 8 and Microsoft Windows Server 2012
・Guest operating system support for Red Hat Enterprise Linux 6
・Support for virtual and physical machine sources with GUID Partition Table (GPT) disks
・Support for virtual and physical machine sources with Unified Extensible Firmware Interface (UEFI)
・Support for EXT4 file system
また、このバージョンでようやくvSphere 5.1がサポートされました。
vSphere 5.1の環境にConverterでP2Vを行う場合、この新しいバージョンでないとサポートされない、ということになります。
旧バージョンはvSphere 5.0までのサポートなので、注意が必要ですね。
Site Recovery Managerの注意点①
VMware の災害対策ソリューションといえば、Site Recovery Manager (SRM) です。
いろいろと調べて得た知識を、まとめていきたいと思います。
今回は、SRMと組み合わせて使うストレージ製品の選定に関する注意点です。
SRMでレプリケーションを行う場合、「アレイベース」もしくは「vSphere Replication」の2パターンの方法があります。
「アレイベース」のレプリケーションは、ストレージ製品が持つ遠隔レプリケーション機能を利用する方法です。
「vSphere Replication」は、vSphereが持つレプリケーション機能を利用する方法です。
SRMで「アレイベース」のレプリケーションを使用する場合、使用可能なストレージ製品が制限されます。
具体的には、VMware Compatibility Guideに掲載されているストレージ製品に限られます。
サポートされるストレージ製品は、以下の画像のように、VMware Compatibility Guideで検索対象を「SIte Recovery Manager」に切り替えることで検索可能です。
ただし、検索結果として表示されるのは具体的なストレージ製品ではなく、SRAの名前である点に注意してください。
検索結果に表示されるSRAを選択すると、具体的なストレージ製品名や接続プロトコル、ファームウェアのバージョンといった詳細情報が表示されます。
例えば、以下の画像では、SRM 5.0 Update 2でサポートされているストレージ製品名(DS3500など)が表示されています。
ちなみに、SRAというのはSRMがストレージ製品と連携するために必要となるコンポーネントです。
SRMは、このSRAを通じて、ストレージ装置に対していろいろな命令を実行しています。
なお、SRAの開発元はVMware社ではなく、各ストレージベンダーになります。
提案するストレージ製品が上記のVMware Comatibility Guideに掲載されていない、という場合はストレージベンダーに問い合わせましょう。
次回のエントリーでは、SRM環境の構築に必要な各種コンポーネントについて整理したいと思います。
VMware View 5.1.2 の仮想デスクトップ展開時のエラー
すっかりご無沙汰してしまいましたが、VMware ViewでView Composerを使って仮想デスクトップを展開するときに、以下のようなエラーが出る場合があります。
"Failed to activate software license (xxxx seconds)"
VMwareからは、以下のようなKBが公開されていて、KMSライセンスが必要であるという点について書かれています。
VMware KB: Provisioning View desktops fails with error: View Composer Agent initialization error (16): Failed to activate software license.
ただ、検証環境でKMSサーバーを立てるのは、かなり大変なんですよね・・・。
KMSサーバーを立てたくないけど、Viewの検証は行いたい、という場合にどうするか？
このような場合は、マスターとなる仮想デスクトップWindowsイメージのレジストリを少しいじればOKです。
①マスターのWindowsでレジストリエディタを開き、以下のキーを探します。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmware-viewcomposer-ga
②「SkipLicenseActivation」というレジストリー値を「1」に変更します。
(デフォルトは「0」です)。
この状態で、マスターのWindowsのスナップショットを取り、仮想デスクトップのプロビジョニングを実行してください。
前述のエラーは出なくなるはずです。
その他、仮想デスクトップの展開時に出るエラーで悩んでいる方は、以下のKBも参考にしてください。
VMware KB: View Composer linked clones fail to finish customizing
"Failed to activate software license (xxxx seconds)"
VMwareからは、以下のようなKBが公開されていて、KMSライセンスが必要であるという点について書かれています。
VMware KB: Provisioning View desktops fails with error: View Composer Agent initialization error (16): Failed to activate software license.
ただ、検証環境でKMSサーバーを立てるのは、かなり大変なんですよね・・・。
KMSサーバーを立てたくないけど、Viewの検証は行いたい、という場合にどうするか？
このような場合は、マスターとなる仮想デスクトップWindowsイメージのレジストリを少しいじればOKです。
①マスターのWindowsでレジストリエディタを開き、以下のキーを探します。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmware-viewcomposer-ga
②「SkipLicenseActivation」というレジストリー値を「1」に変更します。
(デフォルトは「0」です)。
この状態で、マスターのWindowsのスナップショットを取り、仮想デスクトップのプロビジョニングを実行してください。
前述のエラーは出なくなるはずです。
その他、仮想デスクトップの展開時に出るエラーで悩んでいる方は、以下のKBも参考にしてください。
VMware KB: View Composer linked clones fail to finish customizing
Hyper-Vレプリカとライブマイグレーションの併用
Windows Server 2012のHyper-Vでは、新たに以下の機能が実装されました。
・Hyper-Vレプリカ
・シェアードナッシングライブマイグレーション (共有ストレージなしのライブマイグレーション)
「この2つの機能を併用することは可能か？」というのが、本エントリーの主旨です。
まず、以下のような環境を想定します。
・Hyper-Vのホストが2台
・共有ストレージはなし
・Hyper-Vレプリカを構成
Hyper-Vレプリカで仮想マシンに対してレプリケーションを有効にすると、上図のように、他方のHyper-Vホスト上でレプリカVMが自動的に作成されます。
このような状態でライブマイグレーションを実行することで、プライマリサーバ上の仮想マシンをレプリカサーバに移行できるか？
ということですが、結論から言うと、以下のようなエラーが表示され、移行できませんでした。
どうやら、「移行先にも同じ仮想マシンIDを持った仮想マシン(レプリカVM）が存在する」、という理由で失敗しているようです。
したがって、今回の例のように2台のホストでHyper-Vを構成する場合、Hyper-Vレプリカとライブマイグレーションの併用は難しそうです。
ライブマイグレーションによる移行とは異なりますが、Hyper-Vレプリカの「計画フェールオーバー」を実行することで、レプリカVMを起動することは可能です。
ただし、「計画フェールオーバー」は仮想マシンの停止が前提となっている点に注意が必要です。
ライブマイグレーションのようなダウンタイムなしの移行とは異なります。
最後に今回取り上げた構成例のように、共有ストレージがなく、かつ2台のサーバでHyper-V環境を構築する場合、「Hyper-Vレプリカとライブマイグレーションのどちらを使用すべき？」という点について、考えたいと思います。
ぱっと思いつくメリット/デメリットとしては、以下のような感じでしょうか。
■Hyper-Vレプリカを使用する場合
◯ サーバ障害時における仮想マシンのダウンタイムを最小化できる (フェールオーバーの実行でレプリカVMを迅速に起動可能)
☓ サーバメンテナンス時のように、障害以外の理由でサーバを停止しなければならない場合、仮想マシンのダウンタイムが発生する
■ライブマイグレーションを使用する場合
◯ 仮想マシンのダウンタイムなしで、サーバメンテナンスを行うことが可能
☓ サーバ障害時のダウンタイムが大きい。(クラスタを構成できないため)
共有ストレージがない環境ではフェールオーバークラスタを構成できないため、どうしても可用性が低くなってしまいます。
なかなか難しいところですが、仮想マシンの用途に併せて、どちらの機能を使用するか選択したいですね。
※ちなみに、現時点では回避策が見つかっていないだけで、Hyper-Vレプリカとライブマイグレーションを併用する方法が存在する可能性はあります。
そのような回避策が判明した場合、本内容もアップデートしたいと思います。
・Hyper-Vレプリカ
・シェアードナッシングライブマイグレーション (共有ストレージなしのライブマイグレーション)
「この2つの機能を併用することは可能か？」というのが、本エントリーの主旨です。
まず、以下のような環境を想定します。
・Hyper-Vのホストが2台
・共有ストレージはなし
・Hyper-Vレプリカを構成
Hyper-Vレプリカで仮想マシンに対してレプリケーションを有効にすると、上図のように、他方のHyper-Vホスト上でレプリカVMが自動的に作成されます。
このような状態でライブマイグレーションを実行することで、プライマリサーバ上の仮想マシンをレプリカサーバに移行できるか？
ということですが、結論から言うと、以下のようなエラーが表示され、移行できませんでした。
どうやら、「移行先にも同じ仮想マシンIDを持った仮想マシン(レプリカVM）が存在する」、という理由で失敗しているようです。
したがって、今回の例のように2台のホストでHyper-Vを構成する場合、Hyper-Vレプリカとライブマイグレーションの併用は難しそうです。
ライブマイグレーションによる移行とは異なりますが、Hyper-Vレプリカの「計画フェールオーバー」を実行することで、レプリカVMを起動することは可能です。
ただし、「計画フェールオーバー」は仮想マシンの停止が前提となっている点に注意が必要です。
ライブマイグレーションのようなダウンタイムなしの移行とは異なります。
最後に今回取り上げた構成例のように、共有ストレージがなく、かつ2台のサーバでHyper-V環境を構築する場合、「Hyper-Vレプリカとライブマイグレーションのどちらを使用すべき？」という点について、考えたいと思います。
ぱっと思いつくメリット/デメリットとしては、以下のような感じでしょうか。
■Hyper-Vレプリカを使用する場合
◯ サーバ障害時における仮想マシンのダウンタイムを最小化できる (フェールオーバーの実行でレプリカVMを迅速に起動可能)
☓ サーバメンテナンス時のように、障害以外の理由でサーバを停止しなければならない場合、仮想マシンのダウンタイムが発生する
■ライブマイグレーションを使用する場合
◯ 仮想マシンのダウンタイムなしで、サーバメンテナンスを行うことが可能
☓ サーバ障害時のダウンタイムが大きい。(クラスタを構成できないため)
共有ストレージがない環境ではフェールオーバークラスタを構成できないため、どうしても可用性が低くなってしまいます。
なかなか難しいところですが、仮想マシンの用途に併せて、どちらの機能を使用するか選択したいですね。
※ちなみに、現時点では回避策が見つかっていないだけで、Hyper-Vレプリカとライブマイグレーションを併用する方法が存在する可能性はあります。
そのような回避策が判明した場合、本内容もアップデートしたいと思います。
VMDKとRDMの比較
年明けから手抜きなエントリーですが・・・
VMDKとRDM(Raw Device Mapping)の比較検証を行った結果が、以下のブログで公開されています。
vSphere 5.1 – VMDK versus RDM
結果だけを見ると、パフォーマンスの観点で、両者に大きな違いはないようです。
ゲストOS同士のクラスター構成など、RDMが必須となるケースを除いて、大半はVMDKを使うという方針で問題ないですね。
VMDKとRDM(Raw Device Mapping)の比較検証を行った結果が、以下のブログで公開されています。
vSphere 5.1 – VMDK versus RDM
結果だけを見ると、パフォーマンスの観点で、両者に大きな違いはないようです。
ゲストOS同士のクラスター構成など、RDMが必須となるケースを除いて、大半はVMDKを使うという方針で問題ないですね。