vSphere 6.0環境の構築～ESXi～
VCAP6-DCV Deployの試験対策用に、英語版でvSphere6.0を構築しました。
ESXiについては6.5ともほぼ変わりないと思いますが、vCSAについては構築方法がかなり違います。もっというと5.5以前とは全然違いました。vCSA6.0の構築方法については次の記事で書こうと思います。
【ESXi6.0の構築(ほぼスクリーンショットだけ)】
スクリーンショットではキーボードが「Japanese」になってますが、念のため「US」にしました。
構築自体はこれで完了です。
IPを固定にしたい、ホスト名を変更したいなど、各種ネットワーク設定を変更する場合は
「Configure Management Network > IPv4 Configuration」
に設定があるため、必要に応じて変更します。
[Open the VMware Host Client]のリンクをクリックすると、ログイン画面を表示されます。
以上で構築作業は完了です。
VCAP6-DCV Deployの合宿にいってきました！
VCAP6-DCV Deployの合宿にいってきました！
VCAP6-DCV Deployの合宿 って何をするかというと、VCAP6-DCV Deployに合格するために、五日間、リゾートでカンヅメになります。
座学だけでなく、ラボ環境にRDP接続してトラブルシュートなども行えるため、一度も試験を受けていない人にとっては、試験内容のイメージがなんとなくつかめるほか、合格までの具体的で効率的なステップを教えていただける、といった感じです。
ブループリントは範囲が大きいのと何をしたらいいのかがさっぱりなので…。あと、インターネットで探しても体験談とか、問題例とか、圧倒的に少ないので、何したらいいかわからない！って人におすすめかも。
それにしてもVCAP6-DCV Designの合宿のときにも思いましたが、相変わらず綺麗なところでした。カンヅメなのであまり関係ありませんが…。でもやっぱり綺麗なところの方がモチベーションはあがります。あと信玄餅おいしいです。
とりあえず合宿にいったからには受からねば…！ということで、現在VCAP合格に向けて試験対策環境を構築中です。
仮想環境でメモリが足りなくなったときの状態について自分的メモ
一台の物理サーバで複数のサーバを稼働させることができるようになった仮想マシンは、CPUやメモリなどのリソースを共有しています。
そういったときは仮想マシンの
「監視タブ＞使用率」の「ゲストメモリ」の枠に
共有→バルーン済み→圧縮済み→スワップ済み
といった順で現れます。
ちなみにゲストOSのパフォーマンスへの影響としては以下です。
共有＜バルーン済み＜圧縮済み＜スワップ済み
なぜスワップ済みのメモリが発生する方がバルーン済みのメモリが発生するよりもゲストOSへの影響が大きいかというと、バルーン済みメモリはゲストOSに影響がなさそうな部分のメモリを回収していくわけですが、スワップ済みメモリの方はそんなん関係ないとばかりに一切配慮なく回収していくため、今まさに使っているメモリを奪っていく可能性が高いからです。
以下、わかりやすく説明してくださっているサイトです。マニュアルだとよくわからなかったので、ここで勉強しました。
vCenterで確認できるメモリ情報の見方について
vCenterで確認できるメモリ情報の見方について
あと、蛇足です。バージョンによって表記が違う件で。
表記注意(vSphere 5.5の表示→vSphere6.5の表示)
「ホストメモリ」 → 「仮想マシンのメモリ」
「消費」→「消費された仮想マシン」
「オーバーヘッド」→「消費された仮想マシン オーバーヘッド」
"親リソース プールで使用可能なグラフィック リソース量が、この操作に対して不足しています。"が出たときの解決法
NVIDIA GRID vGPUを使用するにあたって、以下のエラーが出たときの解決方法を書きます。
"親リソース プールで使用可能なグラフィック リソース量が、この操作に対して不足しています。"
"the amount of Graphics resources available in the parent resource pool is Insufficient"
これは適切な設定が行われていない場合にも発生しますが(ホストグラフィック設定とサービス等)、設定が行われているにも関わらずこのエラーが出たときは、共有可能な仮想マシン数が上限に達している可能性が高いです。
仮想マシン構成メモ
・GRID K2のグラフィックボードを搭載したESXiで動作している仮想マシン
・GPUプロファイル：grid_k220q
しかし「Physical GPUs」列に記載されている通り、GRID K2にはGPUが2つあるため、"全ての仮想マシンをgrid_k220q で構成した場合は"「16」台の仮想マシンでGPUを共有できます。
イメージとしては以下の画像における緑の構成は可能ですが、赤の構成はだめです。
NVIDIA GRID vGPUを使用する前に気を付けないといけないこと
しかし、vSphere 6.0からはNVIDIA GRID vGPUがサポートされ、ハードウェアアクセラレーショングラフィックスが使用できるようになり、GPUを複数の仮想マシンで共有できるようになりました。
雑に説明すると、CPUやメモリと同じようにグラフィックボードもリソースの共有ができるようになりました。vSphere 6.0以前は占有でした。
ちなみにNVIDIA GRID vGPUを仮想マシンに追加し、ドライバをインストールするとコンソール画面は見えなくなるため、スナップショットを取得していなかったり、リモートデスクトップ接続を許可していないと悲しいことになります。
↓悲しいことになった結果
・画面解像度の設定※
・リモートデスクトップ接続を許可する
・スナップショットを取得する
(※View AgentインストールしてHorizon Clientで接続したら後でも変更可能)
なお、上記をやらずに以下の状態になった際の救済策として、もしドメインに参加していたならグループポリシーでリモートデスクトップ接続を許可する方法もあります。
仮想マシンの構成ファイルにある拡張子がhlogのファイル
データストアの仮想マシン構成ファイルを見ていたところ、"hlog"というファイルを見つけました。
仮想マシンの構成ファイルについてはVCPなどでも出たと思いますが、これは見たことなかったです。
あまり頻繁に見る個所ではないためか、今回初めて発見したのでちょっと調べてみたところ、以下のことが判明しました。
"データストア移行タスクが開始すると、仮想マシン名のハッシュに基づくホスト ログ (.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を変更する方法」の記事をご参照ください。
このカスタマイズ仕様ですが、途中以下のような設定があり、ここで「仮想マシン名を使用」としたときには気をつけなければいけないことがあります。
それは仮想マシン名に"_"を入れないことです。
あと記号やら日本語やら、色々と仮想マシン名は設定できますが、望ましくはない設定であるものの、それをコンピュータ名にしない限りはまだいいかなと。
上記カスタマイズ仕様を使って、クローンの仮想マシン名に"_"を入れるとどうなるかというと、以下のようなエラーがでて、カスタマイズに失敗します。
"指定されたパラメータが正しくありません: spec.identity.userData.computerName"
このエラーを回避するには、仮想マシン名に"_"を使用することをやめるか、カスタマイズ仕様の設定を変更し、コンピュータ名に"_"が入らないようにします。
そしてこの事象ですが、vSphereに限った話だけではなく、コンピュータ名に"_"を入れるといろんな問題があるみたいです。
Customizing desktops with sysprep fails with the error: a specified parameter was not correct: \nspec.identity.userData.computerName (2009820)
