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を変更する方法を書きたいと思います。
仮想マシンの互換性のアップグレード(手動)
仮想マシンの互換性のアップグレード手順はすごく少なくて簡単ですが、重要なことが二つあります。
(1)対象の仮想マシンは電源を落とす必要があること。
(2)作業前に対象の仮想マシンのバックアップを取得しておくこと。
(2)はどの作業でも必要ですが、この作業だと特にそうです。実際、VMware Toolsのアップグレードなどとは異なり、警告がでます。
以下に、手順を記載します。
冒頭でも述べたように、警告が表示されるため「はい」をクリックします。
(バックアップ取得済みであることが前提です)
今回この仮想マシンはバージョン6.0から6.5の環境に移行してきたもののため、「ESXi 6.5以降」が選択されていることを確認し「OK」をクリックします。
ただ、念のためパワーオンして正常に稼働するかどうか確認する必要はあります。
なお、現在パワーオン中で次回シャットダウンしたときにしたい場合は最初の画像の選択肢にある「仮想マシンの互換性のアップグレードのスケジュール設定」をクリックすれば可能です。
個人的な意見としては自動よりは手動で、確認できるときにやった方が安心できますが、また気が向いたらやってみようかなと思ってます。
…実際の運用でも自動じゃなくて手動を使うんだろうなぁ…。
VMware Toolsのアップグレード(Windows)
vSphere環境(vCSA、ESXi等)をバージョンアップした際、仮想マシンのサマリ画面に以下のような警告が表示されます。
今回は手動で一台ずつバージョンアップする方法について記載しています。
本記事に記載しているのはバージョン6.0から6.5に移行した仮想マシンです。
今回は「対話形式のアップグレード」を選択し、「アップグレード」をクリックします。
なお、「自動アップグレード」を選択し、「アップグレード」をクリックした場合、一気に最後の画像の段階になり、アップグレード作業は終了です。
タスクバーに「VMware Toolsのインストールまたはアップグレードの開始」というタスク名が表示されるので、「ステータス」が「完了」になり、上記画像の「VMware Tools」の部分に「利用可能なアップグレード」と表示されなくなったことを確認してください。
中にある「setup64」をダブルクリックします。(64bitの場合。32bitの場合は「setup」)
再起動が完了すると、「VMware Tools」のバージョンが新しくなっていることが確認できます。
