仮想マシンの構成ファイルにある拡張子が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)
VDIのテンプレートに必ず入れて欲しい設定(Windows)
仮想マシンを利用者側から簡単にぶっ壊す方法があります。
それを回避するためにも、この設定はVDIに限らず一般ユーザ(定義が難しいですが具体的に言うとUSBを引っこ抜く前の作業は知っているけど、SCSIとかNICとかはわからない人)が使用する仮想マシンには入れて欲しいです。
Windowsをお使いの方であれば、画面右下(タスクバーの位置にもよりますが)の「∧」マークを見たことがあると思います。
「∧」 をクリックするとウイルスバスターやらOneDriveやら、起動中のサービスが表示されます。
その中にUSBのアイコンがあり、ここをクリックすることでUSBを安全に取り外せます。
今回の趣旨とは異なりますが、Windows10 でこの操作を行わないとUSBがぶっ壊れることがあります。ちなみに私は一回やらかしました。
そしてこの「∧」ですが、物理マシンだと接続しているUSBの一覧が表示されますが、仮想マシンだとやばいものが表示されます。
以下の画像をご覧ください。
しっくりこない方もいらっしゃるかもしれませんが、すごく説明をはしょると、上記のものを取り外すと仮想マシンが正常に動かなくなります。
一番下の[vmxnet3]あたりはNICなので外されても復旧できると思いますが、上二つはぞっとします。
今回タイトルにVDIの文字を入れたのは、VDIの環境によってはUSB接続を許可するような場合は、通常の仮想マシンよりもずっと「∧」をクリックする機会が多いと思ったからです。
そしてVDIの利用者は様々ですが、コンピュータ関連に精通していない人が多いかなと…。
実際「∧」押してずらっとなんかでてきたら全部外しそうな方とかいそうな気が…。
前置きが長くなりましたが、設定方法について記載します。
方法としては二つあります。どちらの方法も仮想マシンのシャットダウンが必要です。
(1)vSphere ClientもしくはvSphere Web Clientで仮想マシンの[設定の編集]画面を使用する方法
(2)仮想マシンの構成ファイルに直接設定を書き込む方法
おすすめは(1)で、今回記載する方法も(1)です。
これを回避する設定については次の記事で記載します。
意外と知られていない「スワップ済み」メモリの解放方法
これが起こると、仮想マシンの動作が遅くなります。
そして厄介なことに、この「スワップ済み」ファイルは仮想環境でメモリが足りない状況が改善されても、自動的に解放されません。
つまり、以下のような状況になります。
「システム遅いんだけど」→「調査します！」→「メモリが競合している模様です。今使っていない仮想マシンを落として一時対応します」→「あの、遅いままなんですが…」→「え、でもクラスタ内のメモリには十分余裕がありますよ」
で、なんやかんやで「仮想マシン再起動してください」みたいな話をふられて再起動してみると問題が解消しているわけです。
"Swapメモリは仮想マシンと同じデータストアに配置"する設定にしていたので、もしかしたらStorage vMotionでSwapファイルが移行する際に解放されるかなぁとも思ったんのですが、結果が以下の画像です。
(Storage vMotion前の画像は間違って消してしまった…)
はい。解放されませんでした。
実は、「バルーン済み」メモリも発生していたのですが、そちらについてはStorage vMotionで解放されました。
思いついたのですが、メモリ予約をMAXにしたら仮想マシンを再起動しなくても解放されるのでは…？
ちょっとまた時間あるときに競合を起こして確認したいと思います。
SIDの確認方法とSIDが持つ数字の意味について
【SIDの確認コマンド】
> whoami /user
実行結果例(クローン元)
※一部数値を塗りつぶしています。
クローン元とクローンで確かにSIDは違うんですが、同じところも多いです。
クローン元のSID：S-1-5-21-3097704385-4090854038-3386600129-500
クローンのSID： S-1-5-21-2250159906-4095572251-131081047-500
※実際の数値に変更を加えています。
具体的には「S-1-5-21-……-500」の部分がクローン元とクローンで変わっていないことがわかります。
この「S-1-5-21-……-500」の部分は下記サイトで、
と紹介されています。
どういうことかというと、SIDはOSに一つではなくユーザ数分存在するということです。
本記事の最後にSIDを確認したときのログをのせますが、SIDの確認コマンドを実行した際、ユーザ名もともに表示されます。
以前の記事と同様の手順でSIDの変更を伴う仮想マシンのクローンを行った場合、変更されるのは下図における赤枠の部分だけということになります。
なお、「S-1-5-21-……-500」の部分がユーザの種類によってどう変わるのかは、先述の参照URLに記載されています。
忘れていなかったら、複数ユーザが作成されている環境での「whoami /user」実行結果を本記事にのせたいと思います。
仮想マシンのクローン作成時にSIDを変更する方法
途中までは通常のクローン作成と同じのため、説明は割愛します。
ここで、「オペレーティングシステムのカスタマイズ」にチェックを入れます。
赤丸の部分をクリックするとカスタマイズ仕様の新規作成ウィザードが表示されます。
あとは適宜、必要個所への入力を行います。
Customizing desktops with sysprep fails with the error: a specified parameter was not correct: \nspec.identity.userData.computerName (2009820)
管理者パスワードが変更できるのはクローン元となる仮想マシンの管理者パスワードがカラのときだけです。
タイムゾーンのデフォルトは日本になっていないため、注意が必要です。
(例)
ユーザー名:administrator@***.com
NetBIOS名にしたり、@以降を省略するのはおすすめしません。
ドメイン参加等がうまくいかない恐れがあります。
現バージョンでは確認していませんがバージョン５の時代にはそんなのもありました。
当時はなんでかわからなかったのですが、以下の方の記事で知りました。
そ、そうだったのか～…って感じです。
そういうこともあってカスタマイズ仕様は一時、全然使ってなかったです。
vSphere 5.0時代はNetBIOS名で失敗
ここにチェックが入っていることを必ず確認してください。
「完了」をクリックすると、新規カスタマイズ仕様の作成は完了です。
あとは、今作成したカスタマイズ仕様を選択した状態で「次へ」をクリックします。
「完了」をクリックするとクローン作成が始まります。
「監視」タブの「タスクおよびイベント」に「仮想マシン〇〇のカスタマイズが成功しました。」と表示されたことを確認してからログインしてください。
何か問題があった場合はログを確認します。ファイルパスは上記画像に記載されている通りです。
以下はログ内容の一部例です。
SIDが本当に変更されたかどうかの確認方法、およびSIDの命名？規則については次の記事で書きます。
Windowsの仮想マシンをクローンする際に気を付けること
WindowsOSはSID(Security Identifier)と呼ばれている一意のIDで管理されています。
SIDの存在を知らなければ、大体みんなひっかかる感じです。かかりました。
でも、実際問題が発生しないと気付かなかったりとか、不意に「SIDの重複神話」なんていうのを見つけて焦るんですよね…。焦りましたよ。
SIDの重複については問題のあるなし等、いろいろな情報がネット上に転がっていますが、私としてはやっぱり変えた方がいいと思ってます。
なんか怖いので…というのは理由になっていないため、ソースをのっけます。
あと、もうソース見つからなくて微妙な記憶なのですが、確かバージョン5.5U2でかつWindows Server 2012 R2？無印？を使用していたとき、かつvmxnet3を使用していたときにネットワークが再起動する(しかもいつ起こるかわからない)現象があったような…。
≪マイクロソフト≫
マシン SID の重複神話
「SIDの重複」の章をご参照ください。
≪VMware≫
"Windows が元の仮想マシンと同一のセキュリティ ID（SID）を持つ新しい仮想マシンまたはテンプレートを割り当てないように設定できます。これらのコンピュータが 1 つのドメイン内にあり、ドメイン ユーザー アカウントのみが使用される場合、SID が重複していても問題が発生することはありません。しかし、これらのコンピュータがワークグループの一部であったり、ローカル ユーザー アカウントを使用したりする場合、SID が重複しているとファイル アクセス コントロールが危険にさらされる場合があります。詳細は、Microsoft Windows オペレーティング システムのドキュメントを参照してください。"
参照元：http://pubs.vmware.com/vsphere-65/topic/com.vmware.vsphere.vm_admin.doc/GUID-1330EEEE-12D1-42FE-B647-E731A01B1A7D.html
次回は、クローン展開時にSIDを変更する方法を書きたいと思います。
