読者です 読者をやめる 読者になる 読者になる

VM26*

VCIX取得を目指して勉強中

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にしたら仮想マシンを再起動しなくても解放されるのでは…?
 
ちょっとまた時間あるときに競合を起こして確認したいと思います。
 

SIDの確認方法とSIDが持つ数字の意味について

クローン元とクローンで確かに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の「……」の部分には、ドメインごとに異なる任意の数値列が入る"
 
と紹介されています。
 
どういうことかというと、SIDはOSに一つではなくユーザ数分存在するということです。
 
本記事の最後にSIDを確認したときのログをのせますが、SIDの確認コマンドを実行した際、ユーザ名もともに表示されます。
 
以前の記事と同様の手順でSIDの変更を伴う仮想マシンのクローンを行った場合、変更されるのは下図における赤枠の部分だけということになります。
 
なお、「S-1-5-21-……-500」の部分がユーザの種類によってどう変わるのかは、先述の参照URLに記載されています。
 
【SIDの確認コマンド】
 > whoami /user
 
実行結果例(クローン元)

f:id:udon0418:20170519003445p:image

※一部数値を塗りつぶしています。
 
忘れていなかったら、複数ユーザが作成されている環境での「whoami /user」実行結果を本記事にのせたいと思います。

仮想マシンのクローン作成時にSIDを変更する方法

仮想マシンをクローンする際にSIDがクローン元の仮想マシンと重複しないようにする方法について記載します。
 
クローン元の仮想マシンを右クリックし「クローン作成>仮想マシンにクローン作成」をクリックします。
 
途中までは通常のクローン作成と同じのため、説明は割愛します。
 

f:id:udon0418:20170516223404p:image

 

f:id:udon0418:20170516223410p:image

 

f:id:udon0418:20170516223407p:image

 
ここで、「オペレーティングシステムのカスタマイズ」にチェックを入れます。
 

f:id:udon0418:20170516223413p:image

 
赤丸の部分をクリックするとカスタマイズ仕様の新規作成ウィザードが表示されます。
 

f:id:udon0418:20170516223416p:image

 
あとは適宜、必要個所への入力を行います。
 

f:id:udon0418:20170516223332p:image

 

f:id:udon0418:20170516223420p:image

 
今回は[仮想マシン名を使用]を選択していますが、これを選択したときに気を付けてほしいのは、仮想マシン名に_を入れないことです。展開時にエラーになります。
 
Customizing desktops with sysprep fails with the error: a specified parameter was not correct: \nspec.identity.userData.computerName (2009820)
 

f:id:udon0418:20170516223335p:image

 

f:id:udon0418:20170516223423p:image

 
管理者パスワードが変更できるのはクローン元となる仮想マシンの管理者パスワードがカラのときだけです。
 
f:id:udon0418:20170516223339p:image
 
タイムゾーンのデフォルトは日本になっていないため、注意が必要です。
 

f:id:udon0418:20170516223342p:image

 

f:id:udon0418:20170516223349p:image

 

f:id:udon0418:20170516223346p:image

 
[Windowsサーバのドメイン名]と[ユーザ名]については必ず以下のように入力してください。
 
(例)
Windowsサーバのドメイン名:***.com
ユーザー名:administrator@***.com
 
NetBIOS名にしたり、@以降を省略するのはおすすめしません。
ドメイン参加等がうまくいかない恐れがあります。
現バージョンでは確認していませんがバージョン5の時代にはそんなのもありました。
 
当時はなんでかわからなかったのですが、以下の方の記事で知りました。
そ、そうだったのか~…って感じです。
そういうこともあってカスタマイズ仕様は一時、全然使ってなかったです。
 
vSphere 5.0時代はNetBIOS名で失敗
 

f:id:udon0418:20170516223429p:image

 
ここにチェックが入っていることを必ず確認してください。
 

f:id:udon0418:20170516223352p:image

 
「完了」をクリックすると、新規カスタマイズ仕様の作成は完了です。
 

f:id:udon0418:20170516223432p:image

 
あとは、今作成したカスタマイズ仕様を選択した状態で「次へ」をクリックします。
 

f:id:udon0418:20170516223355p:image

 
「完了」をクリックするとクローン作成が始まります。
 

f:id:udon0418:20170516223426p:image

 
クローンされた仮想マシンをパワーオン後は、しばらく待つと二回ほど仮想マシンが自動で再起動します。これは、登録情報を変更しているためです。
 
「監視」タブの「タスクおよびイベント」に「仮想マシン〇〇のカスタマイズが成功しました。」と表示されたことを確認してからログインしてください。
 

f:id:udon0418:20170516223358p:image

 
何か問題があった場合はログを確認します。ファイルパスは上記画像に記載されている通りです。
 
以下はログ内容の一部例です。
 

f:id:udon0418:20170516223402p:image

 
SIDが本当に変更されたかどうかの確認方法、およびSIDの命名?規則については次の記事で書きます。

Windowsの仮想マシンをクローンする際に気を付けること

WindowsOSはSID(Security Identifier)と呼ばれている一意のIDで管理されています。
 
しかし単純に仮想マシンをクローンするだけでは、全く同じSIDの仮想マシンが作成されてしまいます。
 
SIDの存在を知らなければ、大体みんなひっかかる感じです。かかりました。
 
でも、実際問題が発生しないと気付かなかったりとか、不意に「SIDの重複神話」なんていうのを見つけて焦るんですよね…。焦りましたよ。
 
SIDの重複については問題のあるなし等、いろいろな情報がネット上に転がっていますが、私としてはやっぱり変えた方がいいと思ってます。
 
なんか怖いので…というのは理由になっていないため、ソースをのっけます。
 
あと、もうソース見つからなくて微妙な記憶なのですが、確かバージョン5.5U2でかつWindows Server 2012 R2?無印?を使用していたとき、かつvmxnet3を使用していたときにネットワークが再起動する(しかもいつ起こるかわからない)現象があったような…。
 
マシン SID の重複神話
 
「SIDの重複」の章をご参照ください。
 
VMware
"Windows が元の仮想マシンと同一のセキュリティ ID(SID)を持つ新しい仮想マシンまたはテンプレートを割り当てないように設定できます。これらのコンピュータが 1 つのドメイン内にあり、ドメイン ユーザー アカウントのみが使用される場合、SID が重複していても問題が発生することはありません。しかし、これらのコンピュータがワークグループの一部であったり、ローカル ユーザー アカウントを使用したりする場合、SID が重複しているとファイル アクセス コントロールが危険にさらされる場合があります。詳細は、Microsoft Windows オペレーティング システムのドキュメントを参照してください。"
 
 
次回は、クローン展開時にSIDを変更する方法を書きたいと思います。

仮想マシンの互換性のアップグレード(手動)

仮想マシンの互換性のアップグレード手順はすごく少なくて簡単ですが、重要なことが二つあります。
 
(1)対象の仮想マシンは電源を落とす必要があること。
(2)作業前に対象の仮想マシンのバックアップを取得しておくこと。
 
(2)はどの作業でも必要ですが、この作業だと特にそうです。実際、VMware Toolsのアップグレードなどとは異なり、警告がでます。
 
以下に、手順を記載します。
 
対象となる仮想マシンを右クリックし、「互換性>仮想マシンの互換性のアップグレード...」を選択します。
 

f:id:udon0418:20170511231513p:image

冒頭でも述べたように、警告が表示されるため「はい」をクリックします。
(バックアップ取得済みであることが前提です)
 

f:id:udon0418:20170511231508p:image

 
今回この仮想マシンはバージョン6.0から6.5の環境に移行してきたもののため、「ESXi 6.5以降」が選択されていることを確認し「OK」をクリックします。
 

f:id:udon0418:20170511231509p:image

 
最近のタスク「仮想マシンの互換性をアップグレード」が「完了」しており、「互換性」の欄に「ESXi 6.5以降」と表示されていることが確認できれば、仮想マシンの互換性のアップグレードは完了です。
 
ただ、念のためパワーオンして正常に稼働するかどうか確認する必要はあります。
 

f:id:udon0418:20170511231511p:image

 
なお、現在パワーオン中で次回シャットダウンしたときにしたい場合は最初の画像の選択肢にある「仮想マシンの互換性のアップグレードのスケジュール設定」をクリックすれば可能です。
 
個人的な意見としては自動よりは手動で、確認できるときにやった方が安心できますが、また気が向いたらやってみようかなと思ってます。
 
…実際の運用でも自動じゃなくて手動を使うんだろうなぁ…。

VMware Toolsのアップグレード(Windows)

vSphere環境(vCSA、ESXi等)をバージョンアップした際、仮想マシンのサマリ画面に以下のような警告が表示されます。
 
vSphere環境をバージョンアップした際は、各仮想マシンにインストールしているVMware Toolsもバージョンアップする必要があります。
 
今回は手動で一台ずつバージョンアップする方法について記載しています。
 
本記事に記載しているのはバージョン6.0から6.5に移行した仮想マシンです。
 
以下の画像の「VMware Tools」の部分にバージョンと「利用可能なアップグレード」と表示されていることを確認し、黄色い枠の右端にある「VMware Toolsの更新」をクリックします。
 

f:id:udon0418:20170510230251p:image

 
今回は「対話形式のアップグレード」を選択し、「アップグレード」をクリックします。
 
なお、「自動アップグレード」を選択し、「アップグレード」をクリックした場合、一気に最後の画像の段階になり、アップグレード作業は終了です。
タスクバーに「VMware Toolsのインストールまたはアップグレードの開始」というタスク名が表示されるので、「ステータス」が「完了」になり、上記画像の「VMware Tools」の部分に「利用可能なアップグレード」と表示されなくなったことを確認してください。
 

f:id:udon0418:20170510230229p:image

 
バージョンアップする予定の仮想マシンVMware Toolsのインストーラが入ったディスクがマウントされました。
 

f:id:udon0418:20170510230235p:image

 
中にある「setup64」をダブルクリックします。(64bitの場合。32bitの場合は「setup」)
 

f:id:udon0418:20170510230230p:image

 
あとは、VMware Toolsを初めてインストールするときと同じです。
 

f:id:udon0418:20170510230237p:image

 

f:id:udon0418:20170510230233p:image

 

f:id:udon0418:20170510230239p:image

 

f:id:udon0418:20170510230241p:image

 

f:id:udon0418:20170510230248p:image

 

f:id:udon0418:20170510230250p:image

 
再起動が完了すると、「VMware Tools」のバージョンが新しくなっていることが確認できます。
 

f:id:udon0418:20170510230654p:plain