VM26*

VCIX取得を目指して勉強中

vSphere 6.0環境の構築~ESXi~

VCAP6-DCV Deployの試験対策用に、英語版でvSphere6.0を構築しました。
ESXiについては6.5ともほぼ変わりないと思いますが、vCSAについては構築方法がかなり違います。もっというと5.5以前とは全然違いました。vCSA6.0の構築方法については次の記事で書こうと思います。
 
【ESXi6.0の構築(ほぼスクリーンショットだけ)】
 

f:id:udon0418:20170714183850p:image

 

f:id:udon0418:20170714183855p:image

 

f:id:udon0418:20170714183901p:image

 

f:id:udon0418:20170714183905p:image

 
スクリーンショットではキーボードが「Japanese」になってますが、念のため「US」にしました。
 

f:id:udon0418:20170714183909p:image

 

f:id:udon0418:20170714183913p:image

 

f:id:udon0418:20170714183918p:image

 

f:id:udon0418:20170714183939p:image

 
構築自体はこれで完了です。
 
IPを固定にしたい、ホスト名を変更したいなど、各種ネットワーク設定を変更する場合は
「Configure Management Network > IPv4 Configuration」
に設定があるため、必要に応じて変更します。
 

f:id:udon0418:20170714183935p:image

 

f:id:udon0418:20170714183945p:image

 
設定が完了したら「https://[IPアドレスもしくはFQDN]/」にアクセスします。
 

f:id:udon0418:20170714183923p:image

 
[Open the VMware Host Client]のリンクをクリックすると、ログイン画面を表示されます。
 f:id:udon0418:20170714183928p:image
 
以上で構築作業は完了です。

VCAP6-DCV Deployの合宿にいってきました!

VCAP6-DCV Deployの合宿にいってきました!
 
場所は星野リゾートのリゾナー八ヶ岳です。
 

f:id:udon0418:20170712232845j:image

 
VCAP6-DCV Deployの合宿 って何をするかというと、VCAP6-DCV Deployに合格するために、五日間、リゾートでカンヅメになります。
座学だけでなく、ラボ環境にRDP接続してトラブルシュートなども行えるため、一度も試験を受けていない人にとっては、試験内容のイメージがなんとなくつかめるほか、合格までの具体的で効率的なステップを教えていただける、といった感じです。
 
ブループリントは範囲が大きいのと何をしたらいいのかがさっぱりなので…。あと、インターネットで探しても体験談とか、問題例とか、圧倒的に少ないので、何したらいいかわからない!って人におすすめかも。
 
それにしてもVCAP6-DCV Designの合宿のときにも思いましたが、相変わらず綺麗なところでした。カンヅメなのであまり関係ありませんが…。でもやっぱり綺麗なところの方がモチベーションはあがります。あと信玄餅おいしいです。
 
とりあえず合宿にいったからには受からねば…!ということで、現在VCAP合格に向けて試験対策環境を構築中です。

仮想環境でメモリが足りなくなったときの状態について自分的メモ

一台の物理サーバで複数のサーバを稼働させることができるようになった仮想マシンは、CPUやメモリなどのリソースを共有しています。
 
共有されたリソースはシェア値、予約、制限等、複数の設定で各仮想マシンに適切に割り振ることができ、その結果、メモリが十分に行き渡らない仮想マシンもでてきます。
 
そういったときは仮想マシン
「監視タブ>使用率」の「ゲストメモリ」の枠に
共有→バルーン済み→圧縮済み→スワップ済み
といった順で現れます。
 
ちなみにゲストOSのパフォーマンスへの影響としては以下です。
 
共有<バルーン済み<圧縮済み<スワップ済み
 

f:id:udon0418:20170620233128p:image

 
なぜスワップ済みのメモリが発生する方がバルーン済みのメモリが発生するよりもゲストOSへの影響が大きいかというと、バルーン済みメモリはゲストOSに影響がなさそうな部分のメモリを回収していくわけですが、スワップ済みメモリの方はそんなん関係ないとばかりに一切配慮なく回収していくため、今まさに使っているメモリを奪っていく可能性が高いからです。
 
そして奪われたメモリのところを使おうと思ったら仮想マシンはデータストアにあるスワップファイルを読み込むのですごく遅くなるわけです。
しかもこのスワップファイル、仮想マシンを再起動するまで解放されないという…辛い。
 
以下、わかりやすく説明してくださっているサイトです。マニュアルだとよくわからなかったので、ここで勉強しました。
 
VMwareテクニカルトレーナよりワンポイントアドバイスVMware vSphereにおけるCPU・メモリの考え方編~
 
vCenterで確認できるメモリ情報の見方について
 
vCenterで確認できるメモリ情報の見方について
 
あと、蛇足です。バージョンによって表記が違う件で。
 
表記注意(vSphere 5.5の表示→vSphere6.5の表示)
 「ホストメモリ」 → 「仮想マシンのメモリ」
 「消費」→「消費された仮想マシン
 「オーバーヘッド」→「消費された仮想マシン オーバーヘッド」

"親リソース プールで使用可能なグラフィック リソース量が、この操作に対して不足しています。"が出たときの解決法

NVIDIA GRID vGPUを使用するにあたって、以下のエラーが出たときの解決方法を書きます。
 
"親リソース プールで使用可能なグラフィック リソース量が、この操作に対して不足しています。"
"the amount of Graphics resources available in the parent resource pool is Insufficient"
 
これは適切な設定が行われていない場合にも発生しますが(ホストグラフィック設定とサービス等)、設定が行われているにも関わらずこのエラーが出たときは、共有可能な仮想マシン数が上限に達している可能性が高いです。
 
 

f:id:udon0418:20170619172542p:image

 
この共有可能な仮想マシン数というのは何かというと、具体例を出した方がわかりやすいため、以下に仮想マシンの編集画面を記載します。
 
 仮想マシン構成メモ
 ・GRID K2のグラフィックボードを搭載したESXiで動作している仮想マシン
 ・GPUプロファイル:grid_k220q
 

f:id:udon0418:20170619172637p:image

 
上記仮想マシンは"grid_k220q"を使用しているため、つまり「8」台の仮想マシンで"1つの"GPUを共有できます。
 

f:id:udon0418:20170619172710p:image

 
しかし「Physical GPUs」列に記載されている通り、GRID K2にはGPUが2つあるため、"全ての仮想マシンをgrid_k220q で構成した場合は"「16」台の仮想マシンGPUを共有できます。
 

f:id:udon0418:20170619172718p:image

 
ただ、全部同じGPUプロファイルで構成したら数え方が簡単なんですが、そうでないときもあると思います。こっちの仮想マシンだけは良いvGPU使わせたいとか。
 
その場合も上記の表を参照しながら設計するわけですが、気を付けなければいけないのは「1つの物理GPUに常駐する仮想GPUは、すべて同じタイプでなければならない」ということです。
 
イメージとしては以下の画像における緑の構成は可能ですが、赤の構成はだめです。
 

f:id:udon0418:20170619172643p:image

 

NVIDIA GRID vGPUを使用する前に気を付けないといけないこと

vSphere 6.0より前は、ホスト(ESXi)にグラフィックボードを搭載してもパススルーの設定だったため、GPU仮想マシンが一対一で接続され、占有の状態となっていました。
 
しかし、vSphere 6.0からはNVIDIA GRID vGPUがサポートされ、ハードウェアアクセラレーショングラフィックスが使用できるようになり、GPUを複数の仮想マシンで共有できるようになりました。
 
雑に説明すると、CPUやメモリと同じようにグラフィックボードもリソースの共有ができるようになりました。vSphere 6.0以前は占有でした。
 
ちなみにNVIDIA GRID vGPUを仮想マシンに追加し、ドライバをインストールするとコンソール画面は見えなくなるため、スナップショットを取得していなかったり、リモートデスクトップ接続を許可していないと悲しいことになります。
 
↓悲しいことになった結果

f:id:udon0418:20170614104529p:plain

 
NVIDIA GRID vGPUのドライバーをインストールする前にやるべきこと(Windows)】
 ・画面解像度の設定※
 ・リモートデスクトップ接続を許可する
 ・スナップショットを取得する
 
(※View AgentインストールしてHorizon Clientで接続したら後でも変更可能)
 
なお、上記をやらずに以下の状態になった際の救済策として、もしドメインに参加していたならグループポリシーでリモートデスクトップ接続を許可する方法もあります。

仮想マシンの構成ファイルにある拡張子がhlogのファイル

データストアの仮想マシン構成ファイルを見ていたところ、"hlog"というファイルを見つけました。
 
仮想マシンの構成ファイルについてはVCPなどでも出たと思いますが、これは見たことなかったです。
 

f:id:udon0418:20170601083156p:image

 
あまり頻繁に見る個所ではないためか、今回初めて発見したのでちょっと調べてみたところ、以下のことが判明しました。
 
"データストア移行タスクが開始すると、仮想マシン名のハッシュに基づくホスト ログ (.hlog ) ファイルがターゲット データストアで作成されます。このファイルは、移行の進行状況の追跡に使用されます。この問題は、ESXi ホスト管理エージェント hostd で「corexx xx.hlog 」という名前の移行進行状況ファイルがコア ファイルとして誤って分類されるために発生します。移行後に .hlog ファイルのファイル タイプがコア ファイルとしてマーク付けされ、そのファイルがデータストアに残ります。これによりこの仮想マシンの以降のストレージ移行は、.hlog ファイルがすでに存在するものとして作成できずに失敗します。"
 
名前が「core」で始まる仮想マシンのストレージ移行が次のエラーで失敗する:仮想マシン coreXX を再配置してください。ファイルまたはフォルダ coreXX-XXXXX.hlog がすでに存在しているため、操作を完了できない (2138084)
 
仮想マシン名「core」で始まってないんですが…。
 
ちなみにhlogの内容はこんな感じでした。
 
--------------------------------------------------
4c4c4544-0033-4a10-804b-b2c04f4b4732
4800307098053305244
success
none
invalid
0
Dir F "/vmfs/volumes/59117446-ea07a3d5-088a-1866daea86ea/comp01"
Disk F "/vmfs/volumes/59117446-ea07a3d5-088a-1866daea86ea/comp01/comp01.vmdk"
File F "/vmfs/volumes/59117446-ea07a3d5-088a-1866daea86ea/comp01/comp01.nvram"
Vm F "/vmfs/volumes/59117446-ea07a3d5-088a-1866daea86ea/comp01/comp01.vmx"
--------------------------------------------------
 
とりあえずStorage vMotionに失敗?したら残ってしまうファイルのようなので、試しにStorage vMotionしてみた結果が以下です。
 
 
--------------------------------------------------
4c4c4544-0033-4a10-804b-b2c04f4b4732
4800307964660600179
success
none
invalid
0
Dir F "/vmfs/volumes/587883b5-1bd4c77a-e0b9-1866daea86ea/comp01"
Disk F "/vmfs/volumes/587883b5-1bd4c77a-e0b9-1866daea86ea/comp01/comp01.vmdk"
File F "/vmfs/volumes/587883b5-1bd4c77a-e0b9-1866daea86ea/comp01/comp01.nvram"
File F "/vmfs/volumes/587883b5-1bd4c77a-e0b9-1866daea86ea/comp01/vmware-1.log"
File F "/vmfs/volumes/587883b5-1bd4c77a-e0b9-1866daea86ea/comp01/vmware.log"
Vm F "/vmfs/volumes/587883b5-1bd4c77a-e0b9-1866daea86ea/comp01/comp01.vmx"

 
データストアが変更されたため、パスが変わったのと、"log"ファイルの記載が追加されました。
あと二行目の数字も変更されています。
 
対処方法(暫定)としてはStorage vMotionに成功してるし、仮想マシンの構成には関係しない部分なので、 削除しても構わないのではないかなと。
試しにゲストOSをシャットダウンした後に削除してみましたが、仮想マシンには特に影響はありませんでした。
 
今回はテスト用なのでさくっとやってしまいましたが、今度発見したときは発生条件なども確認したいと思います。

カスタマイズ仕様で「コンピュータ名」を「仮想マシン名」と同じにするときに気を付けてほしいこと

カスタマイズ仕様とは、仮想マシンのクローンやVDIのデスクトッププールなどを作成する際に使用する設定です。
詳細は以前書いた「仮想マシンのクローン作成時にSIDを変更する方法」の記事をご参照ください。
 
このカスタマイズ仕様ですが、途中以下のような設定があり、ここで「仮想マシン名を使用」としたときには気をつけなければいけないことがあります。
 

f:id:udon0418:20170529104215p:image

 
それは仮想マシン名に"_"を入れないことです。
あと記号やら日本語やら、色々と仮想マシン名は設定できますが、望ましくはない設定であるものの、それをコンピュータ名にしない限りはまだいいかなと。
 
上記カスタマイズ仕様を使って、クローンの仮想マシン名に"_"を入れるとどうなるかというと、以下のようなエラーがでて、カスタマイズに失敗します。
 
"指定されたパラメータが正しくありません: spec.identity.userData.computerName"
 

f:id:udon0418:20170529104221p:image

 
このエラーを回避するには、仮想マシン名に"_"を使用することをやめるか、カスタマイズ仕様の設定を変更し、コンピュータ名に"_"が入らないようにします。
 
そしてこの事象ですが、vSphereに限った話だけではなく、コンピュータ名に"_"を入れるといろんな問題があるみたいです。
 
Customizing desktops with sysprep fails with the error: a specified parameter was not correct: \nspec.identity.userData.computerName (2009820)