KMSキーを使ったWindows 7のアクティべーション
仮想デスクトップ環境でKMSホストによるライセンスアクティベーションの環境を構築してみました。
KMSに関する情報はあまり出ていなくて、手探り状態で構築したのですが、メモ書きとして残しておきたいと思います。
(内容の正確性については保証できませんので、悪しからず・・・。)
■KMSって何？
KMSとは、1つのライセンスキーで複数のWindowsクライアントのライセンスアクティベーションを行うサービスです。
■KMSを使うためには何が必要？
「KMSホスト」と「KMSクライアント」が必要です。
「KMSホスト」は、ライセンスアクティベーションを行う司令塔のような役割を担います。通常は1台でOKです。
「KMSクライアント」は、ライセンスアクティベーションを要求するWindowsクライアントです。
KMSホストにアクティベーションを要求します。
■KMSホストの構築に必要なものは？
まずは、KMSホストに導入するOSです。
どのOSでKMSホストを構築したかによって、認証可能なKMSクライアントのOSが決まります。
Windows 7の認証を行いたい場合は、KMSホストに「Windows 7」もしくは「Windows Server 2008 R2」を導入する必要があります。
マイクロソフト ボリューム ライセンス - 製品のライセンス認証
http://www.microsoft.com/ja-jp/licensing/existing-customers/product-activation-faq.aspx
さらに、「KMSキー」と呼ばれるプロダクトキーが必要です。
この「KMSキー」は、KMSホストに導入したOS用のキーが必要です。(KMSクライアント用のKMSキーではありません。)
例えばKMSホストをWindows 7で構築した場合は、Windows 7のKMSキーが必要です。
KMSホストをWindows Server 2008 R2で構築した場合は、Windows Server 2008 R2のKMSキーが必要です。
なお、Office 2010製品をKMSで認証したい場合は、Office 2010のKMSキーをKMSホストに導入する必要があります。
■KMSホストとKMSクライアントの構築手順は？
普通にOSを導入いただき、KMSキーを適用するだけです。
手順については、下記のドキュメントに記載されています。
ボリューム アクティベーション 2.0 展開ガイド
http://technet.microsoft.com/ja-jp/library/cc303280.aspx
■KMSクライアントがKMSの仕組みで認証されない！
まずは下記の制限に引っかかってないか、ご確認ください。
ネットワーク上に、一定台数のKMSクライアントが存在していないと認証が開始されません。
・Windows Server 2008 および Windows Server 2008 R2のライセンス認証には最低 5 台のコンピューターが必要
・Windows Vista および Windows 7 ライセンス認証には最低 25 台のコンピューターが必要。
・Office 2010、Project 2010、および Visio 2010 ライセンス認証には最低 5 台のコンピューターが必要。
また、そもそもクライアント側がKMSクライアントになっていないという可能性もあります。
slmgr.vbs -dlv コマンドを実行し、KMSクライアントになっているかどうか確認してください。
MAKクライアントの場合は、クライアント上で以下に記載されているプロダクトキーを入力することで、KMSクライアントに変更できます。
KMS Client Setup Keys
http://technet.microsoft.com/en-us/library/ff793421.aspx
Troubleshoot volume activation for Office 2010
http://technet.microsoft.com/en-us/library/ee624355.aspx#section2_3
KMSに関する情報はあまり出ていなくて、手探り状態で構築したのですが、メモ書きとして残しておきたいと思います。
(内容の正確性については保証できませんので、悪しからず・・・。)
■KMSって何？
KMSとは、1つのライセンスキーで複数のWindowsクライアントのライセンスアクティベーションを行うサービスです。
■KMSを使うためには何が必要？
「KMSホスト」と「KMSクライアント」が必要です。
「KMSホスト」は、ライセンスアクティベーションを行う司令塔のような役割を担います。通常は1台でOKです。
「KMSクライアント」は、ライセンスアクティベーションを要求するWindowsクライアントです。
KMSホストにアクティベーションを要求します。
■KMSホストの構築に必要なものは？
まずは、KMSホストに導入するOSです。
どのOSでKMSホストを構築したかによって、認証可能なKMSクライアントのOSが決まります。
Windows 7の認証を行いたい場合は、KMSホストに「Windows 7」もしくは「Windows Server 2008 R2」を導入する必要があります。
マイクロソフト ボリューム ライセンス - 製品のライセンス認証
http://www.microsoft.com/ja-jp/licensing/existing-customers/product-activation-faq.aspx
さらに、「KMSキー」と呼ばれるプロダクトキーが必要です。
この「KMSキー」は、KMSホストに導入したOS用のキーが必要です。(KMSクライアント用のKMSキーではありません。)
例えばKMSホストをWindows 7で構築した場合は、Windows 7のKMSキーが必要です。
KMSホストをWindows Server 2008 R2で構築した場合は、Windows Server 2008 R2のKMSキーが必要です。
なお、Office 2010製品をKMSで認証したい場合は、Office 2010のKMSキーをKMSホストに導入する必要があります。
■KMSホストとKMSクライアントの構築手順は？
普通にOSを導入いただき、KMSキーを適用するだけです。
手順については、下記のドキュメントに記載されています。
ボリューム アクティベーション 2.0 展開ガイド
http://technet.microsoft.com/ja-jp/library/cc303280.aspx
■KMSクライアントがKMSの仕組みで認証されない！
まずは下記の制限に引っかかってないか、ご確認ください。
ネットワーク上に、一定台数のKMSクライアントが存在していないと認証が開始されません。
・Windows Server 2008 および Windows Server 2008 R2のライセンス認証には最低 5 台のコンピューターが必要
・Windows Vista および Windows 7 ライセンス認証には最低 25 台のコンピューターが必要。
・Office 2010、Project 2010、および Visio 2010 ライセンス認証には最低 5 台のコンピューターが必要。
また、そもそもクライアント側がKMSクライアントになっていないという可能性もあります。
slmgr.vbs -dlv コマンドを実行し、KMSクライアントになっているかどうか確認してください。
MAKクライアントの場合は、クライアント上で以下に記載されているプロダクトキーを入力することで、KMSクライアントに変更できます。
KMS Client Setup Keys
http://technet.microsoft.com/en-us/library/ff793421.aspx
Troubleshoot volume activation for Office 2010
http://technet.microsoft.com/en-us/library/ee624355.aspx#section2_3
VMware HA の 「ホスト隔離時の対応」 パラメーター
VMware HAに、「ホスト隔離時の対応」という設定パラメータがあります。
管理ネットワークの切断など、ホスト隔離が発生したと判断されると、このパラメータで指定された処理を仮想マシンに対して行います。
設定可能なパラメータは、以下の3種類です。
①パワーオフ
②シャットダウン
③パワーオンのまま
なぜ今回のエントリーでこのパラメータを取り上げたかというと、vSphere 4.0 と vSphere 5.0 で、このパラメータのデフォルト値が異なるからです。
それぞれのデフォルト値は、以下のとおりです。
vSphere 4.0 : 「シャットダウン」
vSphere 5.0 : 「パワーオンのまま」
実はこのパラメータは、vSphereのバージョンが変わるたびに、デフォルト値がころころ変わっています。
なので、新たに提供されたvSphere 5.0でデフォルト値が変わっている点についても、「またか・・・」という感じがします。
なお、上記のデフォルト値は新規に作成したHAクラスターに設定されます。
既存のHAクラスターに含まれているESXやvCenterをアップグレードした場合は、すでに設定されているパラメーターが適用されます。(当たり前ですが。。。)
なぜvSphere 5.0でデフォルト値が変わったか、という点については、明確な理由はないようです。
書籍「vSphere 5.0 Clustering Technical Deep Dive」によると、『多くのCustomerから「パワーオンのまま」という設定の方がよいというフィードバックがあったから』、という理由が書かれています。
個人的には、「シャットダウン」でも「パワーオンのまま」でも、それほど大差はないと考えています。
あえて違いを挙げるとすれば、「何らかの理由で管理ネットワークが切断されているが、共有ストレージへのアクセスや仮想マシンが使用するネットワークには影響がない」という場合のみ、挙動が少し異なります。
この場合、「シャットダウン」に設定している場合はVMのシャットダウンが発生し、他のESXホストでVMの再起動が発生します。
「パワーオンのまま」の場合は、VMの再起動は発生せず、VMのダウンタイムを回避できます。(共有ストレージへのアクセスができるためVMDKファイルがロックされており、再起動ができないからです。)
なお、ESXの旧バージョンでは、iSCSIやNFSでストレージ装置に接続しており、かつ「パワーオンのまま」を設定している場合は、Split-brainが発生するという問題があったようですが、今は回避できるようになっています。
しかしながら、VMware HAによって保護する障害内容としては「ESXホストの全面ダウン」を真っ先に想定するでしょう。
このような障害の場合は、どちらもVMの再起動が発生します。
VMware HAはかなり奥が深い機能であり、かつトラブルが発生しやすい部分でもあるので、vSphere 5.0のVMware HAについては、時間を見つけて把握しておきたいです。
管理ネットワークの切断など、ホスト隔離が発生したと判断されると、このパラメータで指定された処理を仮想マシンに対して行います。
設定可能なパラメータは、以下の3種類です。
①パワーオフ
②シャットダウン
③パワーオンのまま
なぜ今回のエントリーでこのパラメータを取り上げたかというと、vSphere 4.0 と vSphere 5.0 で、このパラメータのデフォルト値が異なるからです。
それぞれのデフォルト値は、以下のとおりです。
vSphere 4.0 : 「シャットダウン」
vSphere 5.0 : 「パワーオンのまま」
実はこのパラメータは、vSphereのバージョンが変わるたびに、デフォルト値がころころ変わっています。
なので、新たに提供されたvSphere 5.0でデフォルト値が変わっている点についても、「またか・・・」という感じがします。
なお、上記のデフォルト値は新規に作成したHAクラスターに設定されます。
既存のHAクラスターに含まれているESXやvCenterをアップグレードした場合は、すでに設定されているパラメーターが適用されます。(当たり前ですが。。。)
なぜvSphere 5.0でデフォルト値が変わったか、という点については、明確な理由はないようです。
書籍「vSphere 5.0 Clustering Technical Deep Dive」によると、『多くのCustomerから「パワーオンのまま」という設定の方がよいというフィードバックがあったから』、という理由が書かれています。
個人的には、「シャットダウン」でも「パワーオンのまま」でも、それほど大差はないと考えています。
あえて違いを挙げるとすれば、「何らかの理由で管理ネットワークが切断されているが、共有ストレージへのアクセスや仮想マシンが使用するネットワークには影響がない」という場合のみ、挙動が少し異なります。
この場合、「シャットダウン」に設定している場合はVMのシャットダウンが発生し、他のESXホストでVMの再起動が発生します。
「パワーオンのまま」の場合は、VMの再起動は発生せず、VMのダウンタイムを回避できます。(共有ストレージへのアクセスができるためVMDKファイルがロックされており、再起動ができないからです。)
なお、ESXの旧バージョンでは、iSCSIやNFSでストレージ装置に接続しており、かつ「パワーオンのまま」を設定している場合は、Split-brainが発生するという問題があったようですが、今は回避できるようになっています。
しかしながら、VMware HAによって保護する障害内容としては「ESXホストの全面ダウン」を真っ先に想定するでしょう。
このような障害の場合は、どちらもVMの再起動が発生します。
VMware HAはかなり奥が深い機能であり、かつトラブルが発生しやすい部分でもあるので、vSphere 5.0のVMware HAについては、時間を見つけて把握しておきたいです。
vSphere 5.0 の Network I/O Control その2
前回のエントリーで、Network I/O Control（NIOC)について書きました。
NIOCには、以下の特徴があります。
・ネットワークリソースプールのシェア値による帯域制御は、ESXからの送信トラフィックのみに適用
・Enterprise Plusライセンスが必須
・vSphere Distributed Switch (vDS) が必須
第一の特徴については、例えば仮想マシンからのトラフィックを例に挙げると、仮想マシンから外部ネットワークに対して流れるトラフィックが帯域制御の対象になる、という意味になります。
したがって、外部ネットワークから仮想マシンに対して流れてくるトラフィックについては、シェア値による帯域制御が適用されません。
NIOCはカーネル内部のスケジューラーでトラフィックをコントロールしているため、外部から流れてくるトラフィックを調整するのは難しいのでしょう。
（まさか、パケットを破棄したり、バッファのように貯めておくわけにもいかないですし。。。）
ちなみに、ネットワークの帯域を制限する機能として、VMwareには古くからトラフィックシェーピングという機能が提供されていました。
これは、NIOCとは別の機能であり、仮想スイッチのポートグループ単位でトラフィックの制限を行います。
vDSを使用する場合に限り、トラフィックシェーピング機能によって、送受信双方のトラフィックに対して帯域制限を設定することが可能です。
ただし、NIOSとは異なり、ネットワークの輻輳とは関係なく、常に帯域が制限されます。
したがって、「帯域の有効利用」という観点では、NIOCよりも見劣りしますね。
個人的には、送受信双方のトラフィックに対して帯域を制限するのであれば、VMwareの機能を使用するよりも、ハードウェアの機能を使用したほうがよいのでは？と考えています。
送受信双方のトラフィックについて帯域を制限できるだけでなく、vDSやEnterprise Plusライセンスのみに制限されるということもないからです。
最近のNICアダプターやネットワークスイッチ製品には、仮想的にポートを分割して帯域を制限するような機能が存在します。
例えば、HPのFlex-10テクノロジーや、IBMのVirtual Fabric Adapterが有名ですね。
これらのテクノロジーは、実際に物理的に搭載されているNICポートを仮想的な論理ポートに分割し、各仮想ポートに対して帯域を設定することができます。
また、SR-IOVと呼ばれる新しいテクノロジーもあるそうです。
SR-IOVについては知らないことが多いので、じっくりと勉強してみたいと思います。
ネットワーク関連のテクノロジーについては、VMwareも力を入れているようですし、仮想スイッチ製品を提供しているCiscoや、上記に記載したハードウェアベンダーも新しいテクノロジーを提供しています。
10Gbネットワークの導入実績が増えるにつれて、テクノロジーもますます進化しそうですね。
NIOCには、以下の特徴があります。
・ネットワークリソースプールのシェア値による帯域制御は、ESXからの送信トラフィックのみに適用
・Enterprise Plusライセンスが必須
・vSphere Distributed Switch (vDS) が必須
第一の特徴については、例えば仮想マシンからのトラフィックを例に挙げると、仮想マシンから外部ネットワークに対して流れるトラフィックが帯域制御の対象になる、という意味になります。
したがって、外部ネットワークから仮想マシンに対して流れてくるトラフィックについては、シェア値による帯域制御が適用されません。
NIOCはカーネル内部のスケジューラーでトラフィックをコントロールしているため、外部から流れてくるトラフィックを調整するのは難しいのでしょう。
（まさか、パケットを破棄したり、バッファのように貯めておくわけにもいかないですし。。。）
ちなみに、ネットワークの帯域を制限する機能として、VMwareには古くからトラフィックシェーピングという機能が提供されていました。
これは、NIOCとは別の機能であり、仮想スイッチのポートグループ単位でトラフィックの制限を行います。
vDSを使用する場合に限り、トラフィックシェーピング機能によって、送受信双方のトラフィックに対して帯域制限を設定することが可能です。
ただし、NIOSとは異なり、ネットワークの輻輳とは関係なく、常に帯域が制限されます。
したがって、「帯域の有効利用」という観点では、NIOCよりも見劣りしますね。
個人的には、送受信双方のトラフィックに対して帯域を制限するのであれば、VMwareの機能を使用するよりも、ハードウェアの機能を使用したほうがよいのでは？と考えています。
送受信双方のトラフィックについて帯域を制限できるだけでなく、vDSやEnterprise Plusライセンスのみに制限されるということもないからです。
最近のNICアダプターやネットワークスイッチ製品には、仮想的にポートを分割して帯域を制限するような機能が存在します。
例えば、HPのFlex-10テクノロジーや、IBMのVirtual Fabric Adapterが有名ですね。
これらのテクノロジーは、実際に物理的に搭載されているNICポートを仮想的な論理ポートに分割し、各仮想ポートに対して帯域を設定することができます。
また、SR-IOVと呼ばれる新しいテクノロジーもあるそうです。
SR-IOVについては知らないことが多いので、じっくりと勉強してみたいと思います。
ネットワーク関連のテクノロジーについては、VMwareも力を入れているようですし、仮想スイッチ製品を提供しているCiscoや、上記に記載したハードウェアベンダーも新しいテクノロジーを提供しています。
10Gbネットワークの導入実績が増えるにつれて、テクノロジーもますます進化しそうですね。
vSphere 5.0 の Network I/O Control その1
最近10Gbpsのネットワークが仮想化環境で使われるようになってきているようです。
仮想化環境で10Gbネットワークを使うと、1つの物理NICの上を、さまざまなトラフィックが流れることになります。
例えばVMware環境の場合、仮想マシンのトラフィック、vMotionのトラフィック、NFSのトラフィック、などなど。
1Gbネットワークの場合は、物理NICの数が多いため、これらのトラフィックに対して専用の物理NICを割り当てるようなネットワーク設計が可能です。
ところが10Gbネットワークになると、1Gbネットワークの場合と比べて物理NICの数が少なくなるため、複数のトラフィックが混在するようなネットワーク設計が多くなることが予想されます。
そこで、VMwareはNetwork I/O Controlと呼ばれる帯域制御の仕組みを実装しています。
一言で言えば、「ネットワークに輻輳が発生した際、あらかじめ設定した優先順位に応じて、各トラフィックの帯域を制御する仕組み」になります。
「輻輳が発生した際」、「あらかじめ設定した優先順位」といった点がポイントです。
輻輳が発生していない場合は、特に帯域を制御する必要はないため、各トラフィックが必要な分だけ帯域を使うことができます。
しかしながら、輻輳が発生した場合は、ネットワークの交通整理を行って、優先順位の高いトラフィックに対して優先的に帯域を与えるように帯域制御を行います。
Network I/O Control は、vSphere 4.1から登場した機能です。
vSphere 5.0では、いくつか機能拡張が行われています。
最も大きい機能拡張は、「ネットワークのリソースプールを自由に定義できるようになった」という点でしょう。
vSphere 4.1では、以下の6種類のネットワークリソースプールがシステム上で定義されており、優先順位はこの6種類に対してのみ設定可能でした。
・NFSトラフィック
・iSCSIトラフィック
・vMotionトラフィック
・管理トラフィック
・FTトラフィック
・VMトラフィック
したがって、仮想マシンのトラフィックは全て「VMトラフィック」として扱われ、仮想マシンの重要度に応じて帯域を制御する、といった運用はできませんでした。
vSphere 5.0では、上記のようなシステムで定義済みのトラフィックに加えて、ユーザーが自由にネットワークリソースプールを定義することができます。
そして、定義したリソースプールは、仮想スイッチ上のポートグループと紐付けることが可能です。
これにより、輻輳が発生した場合に、ネットワークI/Oが重要な仮想マシン群に対して優先的に帯域を割り当て、それほどネットワークI/Oが重要ではない仮想マシンには帯域を制限する、といった設計が可能になりました。
このようなNetowork I/O Control の機能拡張を利用することで、
「ネットワークリソースによって仮想マシンのサービスレベルを定義する」、といったことがクラウド環境で実現できるかもしれません。
VMwareも、クラウド環境を意識して、このような機能拡張を行ったのではないかと思います。
とはいえ、Network I/O Control も万能ではありません。
他の機能と同様に、いくつか制限事項が存在します。
次回以降のエントリーで、もう少し細かく見ていきたいと思います。
仮想化環境で10Gbネットワークを使うと、1つの物理NICの上を、さまざまなトラフィックが流れることになります。
例えばVMware環境の場合、仮想マシンのトラフィック、vMotionのトラフィック、NFSのトラフィック、などなど。
1Gbネットワークの場合は、物理NICの数が多いため、これらのトラフィックに対して専用の物理NICを割り当てるようなネットワーク設計が可能です。
ところが10Gbネットワークになると、1Gbネットワークの場合と比べて物理NICの数が少なくなるため、複数のトラフィックが混在するようなネットワーク設計が多くなることが予想されます。
そこで、VMwareはNetwork I/O Controlと呼ばれる帯域制御の仕組みを実装しています。
一言で言えば、「ネットワークに輻輳が発生した際、あらかじめ設定した優先順位に応じて、各トラフィックの帯域を制御する仕組み」になります。
「輻輳が発生した際」、「あらかじめ設定した優先順位」といった点がポイントです。
輻輳が発生していない場合は、特に帯域を制御する必要はないため、各トラフィックが必要な分だけ帯域を使うことができます。
しかしながら、輻輳が発生した場合は、ネットワークの交通整理を行って、優先順位の高いトラフィックに対して優先的に帯域を与えるように帯域制御を行います。
Network I/O Control は、vSphere 4.1から登場した機能です。
vSphere 5.0では、いくつか機能拡張が行われています。
最も大きい機能拡張は、「ネットワークのリソースプールを自由に定義できるようになった」という点でしょう。
vSphere 4.1では、以下の6種類のネットワークリソースプールがシステム上で定義されており、優先順位はこの6種類に対してのみ設定可能でした。
・NFSトラフィック
・iSCSIトラフィック
・vMotionトラフィック
・管理トラフィック
・FTトラフィック
・VMトラフィック
したがって、仮想マシンのトラフィックは全て「VMトラフィック」として扱われ、仮想マシンの重要度に応じて帯域を制御する、といった運用はできませんでした。
vSphere 5.0では、上記のようなシステムで定義済みのトラフィックに加えて、ユーザーが自由にネットワークリソースプールを定義することができます。
そして、定義したリソースプールは、仮想スイッチ上のポートグループと紐付けることが可能です。
これにより、輻輳が発生した場合に、ネットワークI/Oが重要な仮想マシン群に対して優先的に帯域を割り当て、それほどネットワークI/Oが重要ではない仮想マシンには帯域を制限する、といった設計が可能になりました。
このようなNetowork I/O Control の機能拡張を利用することで、
「ネットワークリソースによって仮想マシンのサービスレベルを定義する」、といったことがクラウド環境で実現できるかもしれません。
VMwareも、クラウド環境を意識して、このような機能拡張を行ったのではないかと思います。
とはいえ、Network I/O Control も万能ではありません。
他の機能と同様に、いくつか制限事項が存在します。
次回以降のエントリーで、もう少し細かく見ていきたいと思います。
vMA5.0 にSSHで接続する
vSphere5.0がリリースされて、vMAも5.0が登場しました。
vMA5.0では、vi-loggerコマンドの削除など、いくつか変更点があります。
早速使ってみたのですが、リモートPCからSSHで接続するのに手間取りました。。。
結論から言うと、vMA上で下記の設定を行う必要があります。
①sudo vi /etc/hosts.allow を実行する
②/etc/hosts.allowを編集します。
下記の一行を追加します。
sshd : ALL : ALLOW
③sudo service sshd restart を実行し、sshdデーモンを再起動します。
以上の手順で、リモートPCからSSHでvMA5.0に対して接続できるようになりました。
こういう地味なTipsは、なかなか情報が見つからないので苦労させられます・・・。
同じような問題でお困りの方がいらっしゃいましたら、上記を試してみてください。
vMA5.0では、vi-loggerコマンドの削除など、いくつか変更点があります。
早速使ってみたのですが、リモートPCからSSHで接続するのに手間取りました。。。
結論から言うと、vMA上で下記の設定を行う必要があります。
①sudo vi /etc/hosts.allow を実行する
②/etc/hosts.allowを編集します。
下記の一行を追加します。
sshd : ALL : ALLOW
③sudo service sshd restart を実行し、sshdデーモンを再起動します。
以上の手順で、リモートPCからSSHでvMA5.0に対して接続できるようになりました。
こういう地味なTipsは、なかなか情報が見つからないので苦労させられます・・・。
同じような問題でお困りの方がいらっしゃいましたら、上記を試してみてください。