On-Disk フォーマット更新時のサービス影響は?

CJです。

vSphere 5.5の End of General Support (2018/09/19) が近づいていることもあり、このタイミングでの移行やそれに伴うバージョンアップを検討されるケースは多くあるのではないでしょうか。 特にバージョンアップの際に実際仮想マシンへの影響度合いも気になるかと思います。

今回は、vSAN基盤のバージョンアップ (ESXi 6.0U3 → 6.5U1) を行う中で、On-Disk フォーマットというプロセスが発生します。Diskに関するところでサービス (仮想マシンの通信)影響が発生するか否かについて共有したいと思います。

ちなみに、On-Disk フォーマットについてはこちらを参照してください。

テストイメージ図

上記のように、同一の vSAN環境 (vsanDatastore) 上で稼動している仮想マシン(CJ01、CJ02)間の疎通 (ping) を行いつつ、On-Diskフォーマットを更新して結果を確認したいと思います。

vSAN設定画面 (更新前)

vCenter > vSAN Cluster > 設定 > vSAN > 全般 > オンディスクフォーマットのバージョン

こちらの画面で “アップグレードの事前チェック” ボタンをクリックする、vSAN内部で更新ができるかどうかをチェックしてくれます。

アップグレード

事前チェックが正常に完了した後、”アップグレード” ボタンをクリック。すると、

アップグレード開始確認画面が表示されるので、”はい” で次へ。

※冗長性の低下を許可を選択すると、更新がなんらかの理由で失敗した場合にデーター損失につながる可能性がありますので、各自の環境に合わせて注意してお使いいただければと思います。

進行内容は以下の通りとなります。

0 ~     5%:クラスタのチェック。
5 ~   10%:ディスク グループのアップグレード。
10 ~ 15%:オブジェクトの再編成。
15 ~ 95%:ディスク グループの削除および再フォーマット。
95~100%:最終的なオブジェクト バージョンのアップグレード。

vSAN設定画面 (更新後)

ご覧のように、ディスクフォーマットのバージョンが更新 (3.0 → 5.0) されていることがわかります。

サービス(通信)影響は?

パケットロスゼロのサービス(通信)影響はありませんでした。

vSAN基盤を更新する上で、忘れがちなところでもある On-Diskフォーマットですが既存フォーマットの違いを理解した上で必要に応じて忘れず更新いただければと思います。

TIP (RVC : 更新ステータス確認方法)

vsan.upgrade_status /localhost/[DATACENTER]/computers/[CLUSTER]

RVCにログイン上、上記コマンドにて更新ステータスが確認できます。

vsan.upgrade_status -r [秒] /localhost/[DATACENTER]/computers/[CLUSTER]

また、秒指定 (min 60秒) をすると、ユーザーが “Ctrl + c” で抜けない限り画面上更新情報を指定秒間出力してくれます。

運用上、ぜひRVCモードもご活用ください。

 

[参考情報]

vSAN ディスク フォーマットについて

https://docs.vmware.com/jp/VMware-vSphere/6.5/com.vmware.vsphere.virtualsan.doc/GUID-08728A9E-88E0-4CEB-9764-E828719DA927.html

Disk format change going from 6.x to vSAN 6.6?

Disk format change going from 6.x to vSAN 6.6?

vCenter 配下の VM数を把握するには?

CJです。

vSphere基盤を運用する上で、以下の内容について確認したことありませんか?

・Cluster 配下のホスト数

・Cluster 配下のVM数

・PowerOn のVM数

・PowerOff のVM数

そうです、このような内容は計画メンテナンスを行う上で、一度確認したことがあるかと思います。vSphere Web Client を通して GUI でみたり、VMリストをコピーしてメモ帳で行数を把握して VMの数を数えるなどいくつか簡単な方法がありますが、今回は PowerCLIを使った適切・簡単な方法を共有したいと思います。

PowerCLIを起動した後に、以下のコマンドにて現在 vCenter 配下に VMがどれだけあるかみてみましょう。

Get-VM

自分の環境には、上記のように合計 6台のVMが動いている状態です。

では、早速 vCenter 配下で Clusterごとの Host、PowerOn状態の VM の数も以下のコマンドにて確認してみましょう。

Get-Cluster | Select Name, @{N=”Host Count”; E={($_ | Get-VMHost).Count}}, @{N=”VM Count”; E={($_ | Get-VM | Where-Object {$_.PowerState -eq “PoweredOn”}).Count}}

ごらんのように、Clusterごとの Host数および VM数が確認できることがわかります。

PowerOff のVM数を確認するには、以下のコマンドを使います。

Get-Cluster | Select Name, @{N=”Host Count”; E={($_ | Get-VMHost).Count}}, @{N=”VM Count”; E={($_ | Get-VM | Where-Object {$_.PowerState -eq “PoweredOff”}).Count}}

get-vm コマンドで確認したように、自分のテスト環境においては稼働中のVM 6台のみが vCenter 配下にある状態です。本当に PowerOff のVM数も拾えるかどうかを確認するため、VM1台を停止します。

Stop-VM CJVM

VMが停止したので、再度 PowerOn / Off のVM数を確認してみましょう。

きちんと、電源状態に合わせた VMの数が確認できました。

ぜひ、計画メンテナンス時などでご活用ください。

 

[参照情報]

Powercli Script to measure the count of Host and its Vm’s in a each clusters

https://communities.vmware.com/thread/514432

PowerCLI Reference / PowerState – Enum
https://code.vmware.com/docs/5060/cmdlet-reference#/doc/PowerState.html

 

VCS to VCSA : Windows版 vCenter から 仮想アプライアンス版 vCenterへの移行手順

CJです。

多く使われている Windows版 vCenter Server (以下、VCS)も次期 vSphereバージョンからはサポート外になるようです。現在、仮想アプライアンス版 vCenter Server (以下、VCSA)ではほとんどが VCSと変わらず使える状態ですが、マルチNICが正式サポートされていなかったり一部もの足りないところもあるのが現状です。しかし、いつか VCSAになること、ライセンス節約の観点からのメリットもあるので、各自の状況に合わせて移行をご検討いただければと思います。

今回は、この移行方法についてスクリーンショットとともに流れを共有したいと思います。

移行環境

VCS:Windows Server 2012 R2 / PSC組み込み / 別途 DBサーバー(SQL server)が存在 / vCenter 6.0 U2

VCSA: vCenter 6.5 U1

Client: Windows Server 2012 R2

移行イメージ図

移行手順

VCSAデプロイ手順

1.VCS上に、VCSA isoファイルより、”migration-assistant” フォルダをコピーし、VMware-Migration-Assistant アプリを実行する。

Tip: 移行前に、以下の内容を確認してください。

・DRS 無効化 / NTP 同期 / Default Gateway 設定 / もし、iptables 制御している方はそちらも要確認

2.Client PC (以下、Client) に、VCSAの isoファイルをマウントしてインストールファイルを実行。”CDROM : vcsa-ui-installer\win32\installer.exe”

3.移行を選択

4.VCSAのデプロイ / 次へ

5.エンドユーザー使用許諾契約書 / 同意にチェックを入れて 次へ

6.VCSの情報を入力して、次へ

サムプリントの検証画面が表示されたら、”はい” をクリック

7.デプロイ先の ESXi or vCenter 情報を入力 (ここでは ESXi 情報を入力しています。)

証明書に関する警告画面が表示されたら、”はい” をクリック

8.VCSA名と root パスワード情報を入力して、次へ

9.各自の環境に適した VCSAのサイズを選択して、次へ

10.データストアを選択して、次へ

11.ネットワーク構成情報を入力して、次へ

12.設定内容の確認ページが表示されるので、確認後問題なければ “終了” ボタンをクリック。そうすると、初期化された後デプロイが開始されます。

13.デプロイが完了されたら、次は VCSAへ接続します。

https://[VCSAのIPアドレス]:5480

ちなみに、デプロイされた VCSAのディスク構成はどうなっているでしょう。

小 (4 vCPU、16GB RAM)サイズでは、以下の構成となっていることがわかりました。

VCSA への移行手順

1.”Windows 上の vCenter Server インスタンスからの移行” を選択

2.上記手順 8 で設定した VCSAの root パスワードにてログイン

3.ステージ1が終わっている状態で、ステージ2になることを確認の上、次へ

4.VCSの情報を入力して、次へ

証明書に関する警告画面が表示されたら、”OK” をクリック

5.VCS上では、以下のように事前チェックが走っていることがわかります。

暫くすると、移行前チェックの結果が表示されます。

今回、VCS上では VMware Update Manager (以下、VUM)が使用中だったための警告が表示されていますが、スキップします。”閉じる”をクリック。

6.今回の移行では、設定のみ移行すればOKということで、次へ

7.CEIP 参加可否の画面が表示されますが、ここではチェックをOFFにして、次へ

8.設定の確認画面が表示されます。”ソースの vCenter Server をバックアップしました” のチェックボックスにチェックを入れて、終了。

シャットダウンの警告が表示されるので、”OK” をクリック。

VCSAは基本 VCSの情報を引き継ぐため、同一セグメントに置かれている VCSを起動前に止める動きとなっています。

9.VCSから VCSAへデーターコピーが行われます。(vSphere Web Client データのエクスポートなど)

10.VCSA の設定が行われます。

11.すべてのデーターが VCSAへインポートされてから、完了となります。

12.もし、以下のようなエラーが表示されたら、ブラウザのキャッシュをクリアしてみてください。

13.移行完了。

正常に vCenter 6.5 になっていることがわかります。

 

思ったより簡単に移行できそうではないでしょうか。

ぜひ、お試しください。

VCS (シャットダウン中)はそのまま残っている状態のため、もし移行が何らかの理由で途中失敗した場合でも簡単に切り戻しができるのもチャレンジしやすいところかと思います。

 

Tip:VCSでローカルアカウント設定を行っている場合は、移行前にユーザー権限を外してください。そうしないと、移行手順 9 のところ (vPostgres SQLあたり)で失敗する可能性があります。

 

[参考情報]

既知の制限事項

https://docs.vmware.com/jp/VMware-vSphere/6.5/com.vmware.vsphere.upgrade.doc/GUID-5E19B79A-AE4F-497A-9047-3E9AAC1D7767.html

vExpert 2018をいただきました。

CJです。

今朝の発表で、vExpert 2018をいただきました。

個人的には今まで取得してきた資格とは違う性質のもので、非常に光栄であり・嬉しく思っております。これからも得た知識・経験を極力わかりやすい形でシェアしていきたいと思います。

よろしくお願いします。

vSphere6.5環境で、データストアにファイルアップロードができない場合は?

CJです。

vSphere環境上、ISOファイルなどで仮想マシンを作成する場合、まずは ISOファイルをデータストア上にアップロードするかと思います。今まで (vSphere 6.0以下)は、普通にデータストアを参照して、ファイルのアップロードが簡単にできたと思いますが、vSphere6.5では、以下のようなエラーと共にアップロードに失敗することがあるようです。

今回は、このようなエラーに対する対策について共有したいと思います。

原因

今まではブラウザ側で vCenterサーバーの証明書を信頼するだけで十分だったのが、
vSphere6.5では、vCenter Serverの自己証明書が証明書ストアの “信頼されたルート証明機関”にないと、vSphere Web Clientが、vCenter Server とファイルを共有できない・仕組みの変更があるようです。

対策

以下の手順(例.Windows Server)にて、vCenter Serverの自己証明書を “信頼されたルート証明機関” に追加さればOKです。

1. vCenter Server [https://vCenter Server] へ接続し、右下の “信頼されたルート CA 証明書をダウンロード” をクリック

2. ダウンロードしたファイルを展開し、セキュリティ証明書をダブルクリックする

3. 証明書のインポートウィザードより、ローカルコンピューターを選択して次へ

4. 信頼されたルート証明機関を選択

5. 完了

6. 確認

 

[参考情報]

Uploading files to a vSphere service might fail (2147256)

https://kb.vmware.com/s/article/2147256

vCenter Server ルート証明書をダウンロードしてインストールして、Web ブラウザ証明書の警告を防ぐ方法 (2148936)

https://kb.vmware.com/s/article/2148936

vSphere 6.5 – Unable to upload files to Datastore or deploy OVAs

vSAN環境において異なる機種の混在は可能なのか?

CJです。

vSAN環境は安定したパフォーマンスを出すため、基本的に同一のもの (ハードウェア、vSphere version/build など) を使うことを推奨とされているようです。

しかし、使用中のハードウェア(Server)・ドライブ(SSD)が生産終了などを向かえ、購入できない状態になったらどうなんでしょうか。 やはり、ユーザーとしては安定した性能・サービスを使い続けたいわけです。

気になるこの問題について、確認してみました。

結論から言うと、混在は可能です!

VMwareさんの storagehubサイトに上記のような内容が掲載されています。

基本、VMware Compatibility Guideに登録されているものであれば、混在は可能です。ただし、注意事項としては 性能のばらつき・EVC対応可否によっては vMotionができなくなるなどのこともおきうるので、十分ご検討の上で進めてもらったほうが良いかと思います。

[参考情報]

vSAN FAQ > Architecture

https://storagehub.vmware.com/t/vmware-vsan/vsan-frequently-asked-questions-faq/architecture

Enhanced vMotion Compatibility (EVC) processor support 

https://kb.vmware.com/s/article/1003212

PowerCLI : VMが稼動しているホスト情報を確認するには?

CJです。

vSphere 基盤を運用していると、以下のケースにおいて簡単な情報を素早く確認したい時があります。

・特定のホスト上で稼動している VM リストを確認

・VMが稼動中のホストを確認

もちろん、このような情報は GUI (vSphere Web Client) 上からも確認は可能ですが、VM数が数百台の規模とかになると、やはり確認に時間がかかったり、GUI操作に不便を感じるかと思います。その際にはぜひ以下の PowerCLI コマンドを試してみてください。

テスト環境

VMware PowerCLI 6.5.1 build 5377412 です。

Get-PowerCLIVersion

特定のホスト上で稼動している VM リストを確認

 

少し工夫して “host1.cjnotes.com”ホスト上で稼動しているVMで、電源ONかつVM名に “CJ” が入っているVMリストを確認してみます。

Get-VM | Where {$_.Name -eq “host1.cjnotes.com”} | get-vm | Where {$_.PowerState -eq “PoweredOn” -and $_.Name -like “CJ*”} | sort

すると、このようにVM情報が簡単に確認できます。

VMが稼動中のホストを確認

こちらも同じくVMが電源ONであり、VM名に “CJ” が含まれているVMリストのホスト情報を確認してみます。

 

Get-VM | Where {$_.PowerState -eq “PoweredOn” -and $_.Name -like “CJ*”} | sort | select Name,PowerState,VMHost

すると、このように各VMが稼動中のホスト情報も確認できます。

 

 

今回は割愛させていただいていますが、上記コマンドを CSVファイルなどへエクスポートすることも可能です。 メンテナンスなど、作業前後の状態を取得するケースでも有効なコマンドかと思いますので、ぜひお試しください。

ESXiバージョン別の vSAN 性能を比較してみると?

CJです。

vSANは基本 ESXi バージョンアップに合わせて、様々な改善が行われます。

今年2月にも ESXi 6.0U3がリリースされ、以下のような vSAN性能改善が行われたことが知られています。

Virtual SAN のパフォーマンス:VMware ESXi 6.0 Update 3 リリースでは、I/O パスの最適化を実現するため、複数の修正が加えられています。これにより、オール フラッシュ構成およびハイブリッド構成の Virtual SAN のパフォーマンスが向上します。

リリースノートのこの文面だけでは、実際どれくらい性能が向上されたかがわかり難かったため、性能測定を行い、その結果を共有したいと思います。

テスト環境

いつもの大好きな RAID-6 (Erasure Coding) の vSAN環境となります。

性能測定方法

fio を利用して性能測定 (IOPS)

#同一条件で行ったため、細かいパラメータはスキップします。

テスト結果

1プロセッサーの場合 (1P)  / 4プロセッサーの場合 (4P)

いかがでしょうか。

リリースノートに書いてあったパフォーマンス向上の話は本当であり、かつ1行の説明で終わっているような感もしますが、実は測定結果の通りに大きな改善がありました。念のため、現時点の最新バージョンである ESXi 6.5U1 と比較してもそれほど変わらないこともわかります。これから vSANの使用をご検討の方、ESXi 6.0U3 より前のバージョンを使っている方はぜひ ESXi 6.0U3 以上の使用をご検討いただいたらいかがでしょうか。

 

vSAN 仮想マシンの容量が増えるにつれ、ObjectとComponentに起きる変化とは?

CJです。

先日、vSAN環境における RAID-6 にて “VM、Object、Components” の全体的な概要について共有しました。 今日は、その延長となる内容で実際仮想マシンのデータが増えるにつれ、VMの構成要素でもある Object と Component がどのように動作していくのかについて共有したいと思います。

では、早速確認していきましょう。

まず、検証環境はいつもの大好きな RAID-6 構成 (vSAN 6.2) となります。

 

VM作成前

vsan.obj_status_report /localhost/DCNAME/computers/CLUSTERNAME

RVC上で、こちらのコマンドを実行し、まず VM作成前の Object 数を確認してみました。

本環境には、現在 1 Object が存在し、その Object に 6 Components が存在しているのがわかります。 まだ本環境には VMが1台も存在していないのに、なぜか 1 Objectがすでに存在する状態です。 この 1 Object は vSAN 健全性とパフォーマンスオプションが有効になっていると vsanDatastore上で vsan.statsフォルダができますが、これの Object となります。

次は、1TBのディスク容量を持つ VMを作成してみました。

VM作成 (1TB / Thin)

すると、GUI (vSphere Web Client) 上からは、以下の通りに表示されていることがわかります。

#Object : VM ホーム

#Object : ハードディスク (VMDK)

CUI (RVC) からは、以下の通りに表示されます。

vsan.vm_object_info localhost/DCNAME/vms/VMNAME/

GUI上で表示されていた “VM ホーム” と “ハードディスク” のコンポーネント詳細が表示されます。また、こちらで各コンポーネントの容量も確認できます。

vsan.obj_status_report /localhost/DCNAME/computers/CLUSTERNAME

Object Status Report からも、VMDKや VMホームのコンポーネントが表示されたことがわかります。ところが、RAID-6なのになぜか 1 Object に対して 3 Components になっているものが存在しています。これは、VMを起動すると現れる SWAP object となります。 SWAP object は特別扱いで RAID-6 構成であっても、RAID-1の動き (1 コピー + 1 Witness) をするみたいです。

ここまでの整理

ここまでの状況を簡単に整理すると、以下の通りとなります。

VMを作成すると、

・3つの Object (VMDK、VMホーム、SWAP) ができ、

・各 Object はさらに Component に分割され、

・Componentは VMDKが12個、HOMEが6個、SWAPが3個

であることがわかりました。

VMDKの Component 数は、なぜ 12個?

vSAN仕様上、1つの Object は Component で構成されており、1 Component の最大サイズは 255GB となっています。

今回、1TBディスク (データ) を持つ、VMを作成しましたことを思い出してください。

1TB = 1024GB ですね。

255GB x 4 (Component : データ) = 1020GB となります。

この 1020GBをオーバーするため、不足している分 (1021~1024GB) の Component が増加 (6つ)する動きとなっています。

これを簡単な図で表したのが、次です。

仮想マシンの容量が増えるにつれ、Component のサイズはどうなるの?

仮想マシンの容量が増える (Guest OS 内のデータが増える)と、VMDK Object を構成している各 Component のサイズも均等に増加します。実際、Guest OS内のデータを増やして行く際の Component サイズの変化を表したのが、次です。

各 Component の容量が 127.5GB で均等に分散されているのがわかります。

また、vSANのRAID-6を使う場合に、ディスク使用量が 1.5倍になりますが、きちんと仕様通りの動きになっていることもわかります。#1530GB

Tip: 2TB のVMを作成すると?

Componentの数と容量が増えていることがわかります。

まとめ

いかがでしょうか。

VMの構成要素 (Object & Component) とそれらの増加タイミング、数、容量などの変化が起きる仕組みがお分かりになりました?vSAN ならではの仕様でもあるため、なんとなくわかっても綺麗に整理できなかった方々に本記事が少しでも役に立てればと思います。

 

[参考情報]

SWAP Object について

http://www.yellow-bricks.com/category/storage/page/2/

vSAN Objects and Component Placement

Understanding vSAN Rebuilds and Repairs

vSAN 暗号化機能を使うには?

CJです。

 

vSAN6.6で新たに暗号化機能が追加されたこと、知っていますか。

vSANでは、2つタイプの暗号化機能が追加されています。

そのひとつ目は、仮想マシンストレージポリシーを使って VMごとに適用することができる ” VM 暗号化”、二つ目は、トランジットが発生していない時に vsanDatastore 全体を暗号化する “vsanDatastore 暗号化” です。

今日はそのうち vsanDatastore 暗号化機能をどうやって有効化するかについて共有したいと思います。

テスト環境情報

・vSAN 6.6.1 (ESXi 6.5 U1)

・Key Management Server (以下、KMS): HyTrust KeyControl

 

1. まずは、VCGの確認から

暗号化機能を使うためには、KMSサーバーが必須となります。

もちろん、vSAN環境なので既存のパーツと同じく、KMSサーバー自体も VCGにて管理されています。 このリスト上に掲載されているものからお使いください。

自分は、VMworldなどでも紹介されたりした HyTrustさんの KMSサーバーを使うことにしました。

2. KMSサーバーのデプロィ

vCenter と同一のネットワーク上に、KMSサーバーをデプロィします。

HyTrustさんからは、OVA 形式で仮想アプライアンスが提供されており、自分はこちらを使っています。#ISO形式でも提供されています。

また、KMSサーバーのシステム要件としては Standard基準として以下が求められています。

・2cpu / 8GB RAM / 20GB HDD

このように、必要なパラメーターを入力して、KMS仮想アプライアンスをデプロィします。

3. KMSサーバーの構成

vCenter (Windows版)より、HyTrust KMSサーバーへIEより接続します。

初回はデフォルトの “secroot / secroot” にてアクセス可能です。

ログイン直後に、パスワード変更が求められますので、パスワードの更新を行ってください。

KMIP構成画面より、Stateの有効化および VCGに掲載されていた Versionに合わせて設定を行います。

KMIP構成後は、Users > Create User にてユーザーを作成してください。

※本手順ではユーザーのパスワード入力なしにしてあります。

ユーザー作成後は、Actions > Download Certificate にて証明書を保存してください。後ほど vCenter にKMSサーバーを登録する際に使います。

保存した zipファイルを展開すると、上記のように2つのファイルがあります。

このうち、後ほどvCenter側で使うのは左側のファイル (KMIPUser.pem)となります。

4. vCenter に KMSサーバーを登録

KMSサーバーの準備ができたため、次は vCenterサーバーに KMSサーバーの登録を行います。 vCenter > 設定 > 詳細 > キー管理サーバー > KMSの追加

この後、引き続き信頼の確立を行い、”証明書およびプライベートキーのアップロード”を選択してください。

証明書とプライベートキーをアップロードするところが表示されたら、事前に保存しておいたユーザー証明書・キーファイル (KMIPUser.pem) をアップロードしてください。

証明書登録後も、接続状態が “正常” にならない場合があります。

※その際は、”すべてのアクション”メニューより、証明書の信頼アクションを実施すると改善されます。

5. vSAN 暗号化の有効化

これですべての準備が完了しました。

最後は、vSANクラスタの暗号化機能を有効にするだけです。

クラスタ > 設定 > vSAN > 全般 > vSAN設定の編集 > 暗号化 : チェックイン

そうすると、ディスクフォーマットが動作し、ディスクグループの再作成が行われます。

終わった後は、以下の通りに暗号化機能が有効になっていることがわかります。

ちなみに、vsanDatastore の暗号化によるパフォーマンス影響はほとんどないようです。

#CPUの負荷としては、5~15%程度。

まとめ

いかがでしょうか。

上記の4ステップだけで、vSAN 暗号化機能が簡単に使えるようになります。

既存のハードウェア製暗号化ソリューションに比べて、vSAN上で簡単な設定を行うだけで、セキュリティを高めることができるのはとても嬉しいです。

ぜひ、一度 vSANの暗号化機能をお試しください。

※KMSサーバーおよび vSAN暗号化を有効にするためには、それぞれに該当する適切なライセンスを購入・適用してください。詳しくは各KMSベンダーへお問い合わせください。

 

[参考情報]

vSAN クラスタでの暗号化の使用

https://docs.vmware.com/jp/VMware-vSphere/6.5/com.vmware.vsphere.virtualsan.doc/GUID-F3B2714F-3406-48E7-AC2D-3677355C94D3.html

HyTrust KeyControl with VMware vSphere VM and VSAN Encryption

https://docs.hytrust.com/DataControl/Admin_Guide-4.0/Default.htm#Books/VMware-vSphere-VSAN-Encryption/aaTitle-KeyCtrl-for-vmware-encrypt.htm%3FTocPath%3DHyTrust%2520KeyControl%2520with%2520VMware%2520vSphere%2520VM%2520and%2520VSAN%2520Encryption%7C_____0