VM26*

VCIX取得を目指して勉強中

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

一台の物理サーバで複数のサーバを稼働させることができるようになった仮想マシンは、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)

VDIのテンプレートに必ず入れて欲しい設定(Windows)

仮想マシンを利用者側から簡単にぶっ壊す方法があります。
 
それを回避するためにも、この設定はVDIに限らず一般ユーザ(定義が難しいですが具体的に言うとUSBを引っこ抜く前の作業は知っているけど、SCSIとかNICとかはわからない人)が使用する仮想マシンには入れて欲しいです。
 
Windowsをお使いの方であれば、画面右下(タスクバーの位置にもよりますが)の「∧」マークを見たことがあると思います。
 
「∧」 をクリックするとウイルスバスターやらOneDriveやら、起動中のサービスが表示されます。
その中にUSBのアイコンがあり、ここをクリックすることでUSBを安全に取り外せます。
 
今回の趣旨とは異なりますが、Windows10 でこの操作を行わないとUSBがぶっ壊れることがあります。ちなみに私は一回やらかしました。
 

f:id:udon0418:20170525114533p:image

 
そしてこの「∧」ですが、物理マシンだと接続しているUSBの一覧が表示されますが、仮想マシンだとやばいものが表示されます。
以下の画像をご覧ください。
 

f:id:udon0418:20170525114537p:image

 
しっくりこない方もいらっしゃるかもしれませんが、すごく説明をはしょると、上記のものを取り外すと仮想マシンが正常に動かなくなります。
一番下の[vmxnet3]あたりはNICなので外されても復旧できると思いますが、上二つはぞっとします。
 
今回タイトルにVDIの文字を入れたのは、VDIの環境によってはUSB接続を許可するような場合は、通常の仮想マシンよりもずっと「∧」をクリックする機会が多いと思ったからです。
そしてVDIの利用者は様々ですが、コンピュータ関連に精通していない人が多いかなと…。
実際「∧」押してずらっとなんかでてきたら全部外しそうな方とかいそうな気が…。
 
前置きが長くなりましたが、設定方法について記載します。
 
方法としては二つあります。どちらの方法も仮想マシンのシャットダウンが必要です。
 
(1)vSphere ClientもしくはvSphere Web Clientで仮想マシンの[設定の編集]画面を使用する方法
(2)仮想マシンの構成ファイルに直接設定を書き込む方法
 
おすすめは(1)で、今回記載する方法も(1)です。
(2)は仮想マシンをぶっ壊されないために仮想マシンをぶっ壊したとかいう展開になりかねないからです。
 
これを回避する設定については次の記事で記載します。
 

意外と知られていない「スワップ済み」メモリの解放方法

スワップ済み」メモリとは何かというと、仮想環境でメモリが足りなくなってきたときに、仮想マシンのメモリをデータストアにあるswapファイルで代用する方法です。
これが起こると、仮想マシンの動作が遅くなります。
 
そして厄介なことに、この「スワップ済み」ファイルは仮想環境でメモリが足りない状況が改善されても、自動的に解放されません。
つまり、以下のような状況になります。
 
「システム遅いんだけど」→「調査します!」→「メモリが競合している模様です。今使っていない仮想マシンを落として一時対応します」→「あの、遅いままなんですが…」→「え、でもクラスタ内のメモリには十分余裕がありますよ」
 
で、なんやかんやで「仮想マシン再起動してください」みたいな話をふられて再起動してみると問題が解消しているわけです。
 
これは、仮想マシンの再起動により「スワップ済み」メモリが解放されたからです。
 
この「スワップ済み」メモリですが、厄介なことに仮想マシンを再起動しないと解放されないと言われています。
 
"Swapメモリは仮想マシンと同じデータストアに配置"する設定にしていたので、もしかしたらStorage vMotionでSwapファイルが移行する際に解放されるかなぁとも思ったんのですが、結果が以下の画像です。
 

f:id:udon0418:20170523082416p:image

(Storage vMotion前の画像は間違って消してしまった…)
 
はい。解放されませんでした。
 
実は、「バルーン済み」メモリも発生していたのですが、そちらについてはStorage vMotionで解放されました。
 
思いついたのですが、メモリ予約をMAXにしたら仮想マシンを再起動しなくても解放されるのでは…?
 
ちょっとまた時間あるときに競合を起こして確認したいと思います。