どこぞの話で突っ込みを入れたときに調べた事を書いておく。
pvSCSI とは vSphere のディスクIOに対する準仮想化ドライバの事で、vSphere がサポートする一部のOSにて利用できる。どのOSで利用できるかは KB 1010398 を参照してほしい。
さて、そこの話、端的に言えば「pvSCSI も LSI Logic もIOPS変わんない」と、暗に pvSCSI を使えないと示唆するようなことだった。
そう、よく勘違いされるが pvSCSI は (vmxnet3 も) ただ「IO性能を上げるもの」ではない。これは pvSCSI の出始めに発表された、このホワイトペーパーを見ればわかる。
英文を読まずとも表だけ見れば LSI Logic と pvSCSI で性能差がほとんどない事に気がつく。
一方、差が出ているのは「CPIO」と呼ばれる項目だ。ドキュメント中に説明があるがこれは「a unit of cycles per I/O」、すなわちそのIOの間にどれだけ CPUが消費されたか、になる。
考えてみれば当たり前の話だ。pvSCSI でも LSI Logic でも、仮想環境上のメモリに存在するデータを、VMkernel に渡して実際のストレージIOにする部分に大きな差はない。異なるのはそのためにLSI Logic という実際のハードウェアの手順をエミュレートするのか、そういう細かいところを省くか、だけになる。LSI Logic のデバイスドライバをそのまま使えるようにするという手間が省ける分、CPUサイクルが削減され、CPU負荷が下がる、というのが pvSCSI の本質だ。
結果として IOしている間のCPU負荷が下がる。
これは IOPS をはかるベンチマークではあまり意味をなさないが、CPUがそれだけあいているという事はアプリケーションがさらに演算を行ったり、pvSCSI以外のデバイスに対するIOを行うだけの余地が増える。ワークロードのスループット全体を見れば、向上が行われる、という次第だ。
ベンチマークの結果値だけを見ているとこうした事はわからない。
数字の多寡を気にするのではなく、システム全体を俯瞰し、それがどういう位置づけになるかを忘れない事だ。
2015/04/05
2015/03/12
アップグレードしたOSはカスタマイズできない
所用があり WindowsServer 2012 R2 をいくつかテンプレートから展開していたのだが、カスタマイズ仕様で指定した設定がなされていないことに気がついた。
該当のマシンにログオンし、 sysprep のログを見たところ、以下のメッセージが表示されていた。なお、sysprep のログについてはこちらのKBに記載がある。
該当のマシンにログオンし、 sysprep のログを見たところ、以下のメッセージが表示されていた。なお、sysprep のログについてはこちらのKBに記載がある。
[0x0f0036] SYSPRP spopk.dll:: Sysprep will not run on an upgraded OS. You can only run Sysprep on a custom (clean) install version of Windows.
...ああ、なるほど。このテンプレート、そもそもは WindowsServer 2012 で、R2 を後から適用したため「アップグレード」となってしまったわけだ。2012 を展開する用がなかったのでそのことをすっかり失念していた。
対処としては二つある。一つは、素直にOSを新規インストールし直すことだ。
今回はこちらを採用した。理由は簡単で、Windows.old が残っており、削除がやっかいで、そのうえ肥大した VMDK の領域回収を考えると、時間はかかるがほったらかしておけば終わる入れ直しの方が楽だったからだ。
もう一つは、アップグレードであるというフラグをつぶしてしまうことだ。
レジストリを操作するだけなので時間は短くて済む。
しかし、そもそもなぜアップグレードしたOSだと sysprep を拒否するようになってるかがわからないので、後々で面倒を抱えたくないというのもあり、この手を取らなかった。
2015/03/09
Horizon View Connection Server で「サービスが正常に機能していません」が表示される。
Horizon View の Connection Server を複数立てたとき、ダッシュボードの接続サーバに「サービスが正常に機能していません」というメッセージが表示されることがある。
なお、英文だと「The service is not working properly. 」の模様。
KBを探してみても vCenterServer にこのメッセージが出る場合の記載ぐらいで、ログもそれらしいエラーがなく困っていたが、ようやく原因を特定できた。
二つの ConnectionServer で時刻同期がうまくいっておらず、時間が1分程度ないしそれ以上ずれていると、このメッセージが表示される。
一方が ServerCore で構成していたのだが、どっかのタイミングで Windows Time が起動されてなかったらしく、時々ずれがこの時間を超えて、なぜか赤くなる、を繰り返していたのだ。
わかってしまえば対処は簡単で、時刻同期がちゃんと実行されるようにするだけだ。
今回実施したのは、以下の通り
起動しないとそれ以降のコマンドが打てないので、とりあえず動かしておくのだ。
3行目でドメインコントローラから時刻をとるように設定を強制、4行目で同期を強制している。( どうも /redisover をつけないと同期先を古い設定のまま見に行くことがあるので注意。)
1,2 分程度のずれなのでこれで済んだ。
大きくずれている場合の同期方法については適当に調べてほしい。
なお、同期状況の確認は
time コマンドだと、そのまま実行すると時刻の設定をしようとし、/T をつけると秒以下を表示してくれないため。
いろいろ探しても該当事例を見つけられなかったので、念のために記録しておく。
なお、英文だと「The service is not working properly. 」の模様。
 |
| 「サービスが正常に機能していません」のエラーメッセージ そう言われましても...、って気分になる |
KBを探してみても vCenterServer にこのメッセージが出る場合の記載ぐらいで、ログもそれらしいエラーがなく困っていたが、ようやく原因を特定できた。
二つの ConnectionServer で時刻同期がうまくいっておらず、時間が1分程度ないしそれ以上ずれていると、このメッセージが表示される。
一方が ServerCore で構成していたのだが、どっかのタイミングで Windows Time が起動されてなかったらしく、時々ずれがこの時間を超えて、なぜか赤くなる、を繰り返していたのだ。
わかってしまえば対処は簡単で、時刻同期がちゃんと実行されるようにするだけだ。
今回実施したのは、以下の通り
w32tm register
net start "Windows Time"
w32tm /config /update /syncfromflags:DOMHIER
w32tm /resync /rediscover最初の行でサービスとして登録、二行目で起動する。
起動しないとそれ以降のコマンドが打てないので、とりあえず動かしておくのだ。
3行目でドメインコントローラから時刻をとるように設定を強制、4行目で同期を強制している。( どうも /redisover をつけないと同期先を古い設定のまま見に行くことがあるので注意。)
1,2 分程度のずれなのでこれで済んだ。
大きくずれている場合の同期方法については適当に調べてほしい。
なお、同期状況の確認は
w32tm /monitorを実行するのが手っ取り早く、時間は
echo %time%としたほうが、time コマンドより楽だ。
time コマンドだと、そのまま実行すると時刻の設定をしようとし、/T をつけると秒以下を表示してくれないため。
いろいろ探しても該当事例を見つけられなかったので、念のために記録しておく。
2015/02/23
ESXi に使うべき フラッシュメディアのサイズ
ESXi 5.5 のインストールには最低 1GB のストレージ容量が必要で、scratch を配置する場合は 5.2GB 以上、となる。
これは ESXi のマニュアルに記載されている。
さて、ではサイズが異なると ESXi のインストレーションはどう変わっていくのだろうか?
VMware Fusion 上に ESXi をインストールし、その時の VMDK のサイズを変えて試してみた。
● 1,2,4GB の場合
これら 5.2 GB 未満のメディアの場合は、まったく同じサイズで5つのパーティションが作成される。
IDはパーティション番号を意味する。
1は要するに EFI システムパーティションで、FAT である。
5 が実際の ESXi のシステムが入ってる bootbank で、6 は altbootbank である。
7 は診断パーティションとも呼ばれているもので、要するにコアダンプ用だ。
8 は visorfs の /store にマウントされるパーティションで、VMware Tools のインストール用 CDイメージなどが格納されている。
linuxNative とGUIDで記載されているパーティションが何故 FAT32かというと、GUIDパーティションテーブルでは、Windows のパーティションと Linux のパーティションに同じGUID が割り当てられており、区別できないからだ。
全体で1GiB も使ってないが、これは 1,2,4 GB どの場合も同じだった。
つまり、5.2GB 未満では、どの容量のメディアを使おうと、先頭 0.9 GiB程度しか使われない訳だ。
● 8GB の場合
さて、8GBのメディアにインストールすると、こうなる。
前半のパーティションはそのままで、あらたに9, 2, 3 の三つのパーティションが追加された。
ID:9 はESXi 5.5 で新たに用意されたコアダンプパーティションだ。従来の110MiBのダンプでは全てを取りきれないため、2.5GBもの容量が確保されている。
ID:2 がいわゆる Scratch パーティションで、ログなど様々な情報が格納される。
このパーティションが存在しないと、ESXi が警告を発するのはご存じの通りだ。
ID:3 は VMFS であり、datastore1 となる部分だ。ここは、ディスクの残り領域がすべて割り当てられる。8GBのメディアの場合、600MiB程度が VMFSとして確保される。
ここであれ?っと疑問に思われた方は正しい。そう、VMFS は 600MiB なんてサイズでは構成できない。vSphereClient から datastore1 を削除した後、再作成は失敗する。
この制限以下の小さな VMFS は、インストール時にのみ現れる特別なものらしい。
閑話休題、scratch が必要な場合は 5.2GB 以上のメディアを使うようドキュメントにはあるが、0.9GiB + 2.5GiB(拡張ダンプ) + 4GiB(scratch) では、7.4GB 程度が必要に見える。
そこで、6GB の場合を試してみた。
● 6GB の場合
6GB では、パーティションテーブルはこうなった
ID9 の拡張ダンプパーティションが消えている。その分、余りが増えるため VMFS 領域が拡大しているのが分かる。VMFS領域を抜くと、約 4.9 GiB になる。つまりは、SI単位系で言うところの約 5.2GB である。厳密に言うなら、scratch の最終セクタが 10229759 であり、1セクタが 512バイトのため、5237636608 バイトが必要である。これを1024 で割っていくと 4.87GB となり、1000 で割ると 5.2GB となる訳だ。
そして余った分が VMFS の領域になる。
もし、余りが 2.5GiB 以上あれば、拡張ダンプパーティションが作成され、そこからの残りで VMFS が作成される。
共有ディスクに、複数 ESXi のログまとめて管理したり、syslog で飛ばして LogInsight を使う、とかでも無い限り、scratch はあるに越したことない。
このため、おとなしく 5.2GB以上、実質的には 8GB のフラッシュメディアを用意しておくのが正解、となる。
なお、こちらのKBには面白いことが書いてある。
後半の文章が謎だが、8GB の誤植ではないかと思われる。
これは ESXi のマニュアルに記載されている。
さて、ではサイズが異なると ESXi のインストレーションはどう変わっていくのだろうか?
VMware Fusion 上に ESXi をインストールし、その時の VMDK のサイズを変えて試してみた。
● 1,2,4GB の場合
これら 5.2 GB 未満のメディアの場合は、まったく同じサイズで5つのパーティションが作成される。
| ID | 開始セクタ | 終了セクタ | サイズ | 形式(FS) | 用途 |
| 1 | 64 | 8191 | 4MiB | systemPartition (FAT32) | EFI |
| 5 | 8224 | 520191 | 250MiB | linuxNative (FAT32) | /boot |
| 6 | 520224 | 1032191 | 250MiB | linuxNative (FAT32) | /altboot |
| 7 | 1032224 | 1257471 | 110MiB | vmkDiagnostic | Coredump |
| 8 | 1257504 | 1843199 | 286MiB | linuxNative (FAT32) | /store |
IDはパーティション番号を意味する。
1は要するに EFI システムパーティションで、FAT である。
5 が実際の ESXi のシステムが入ってる bootbank で、6 は altbootbank である。
7 は診断パーティションとも呼ばれているもので、要するにコアダンプ用だ。
8 は visorfs の /store にマウントされるパーティションで、VMware Tools のインストール用 CDイメージなどが格納されている。
linuxNative とGUIDで記載されているパーティションが何故 FAT32かというと、GUIDパーティションテーブルでは、Windows のパーティションと Linux のパーティションに同じGUID が割り当てられており、区別できないからだ。
全体で1GiB も使ってないが、これは 1,2,4 GB どの場合も同じだった。
つまり、5.2GB 未満では、どの容量のメディアを使おうと、先頭 0.9 GiB程度しか使われない訳だ。
● 8GB の場合
さて、8GBのメディアにインストールすると、こうなる。
| ID | 開始セクタ | 終了セクタ | サイズ | 形式(FS) | 用途 |
| 1 | 64 | 8191 | 4MiB | systemPartition (FAT32) | EFI |
| 5 | 8224 | 520191 | 250MiB | linuxNative (FAT32) | /boot |
| 6 | 520224 | 1032191 | 250MiB | linuxNative (FAT32) | /altboot |
| 7 | 1032224 | 1257471 | 110MiB | vmkDiagnostic | Coredump |
| 8 | 1257504 | 1843199 | 286MiB | linuxNative (FAT32) | /store |
| 9 | 1843200 | 7086079 | 2.5GiB | vmkDiagnostic | 拡張Coredump |
| 2 | 7086080 | 15472639 | 4GiB | linuxNative (FAT32) | /scratch |
| 3 | 15472640 | 16777182 | 約0.6GiB (残り全部) |
vmfs | datastore01 |
前半のパーティションはそのままで、あらたに9, 2, 3 の三つのパーティションが追加された。
ID:9 はESXi 5.5 で新たに用意されたコアダンプパーティションだ。従来の110MiBのダンプでは全てを取りきれないため、2.5GBもの容量が確保されている。
ID:2 がいわゆる Scratch パーティションで、ログなど様々な情報が格納される。
このパーティションが存在しないと、ESXi が警告を発するのはご存じの通りだ。
ID:3 は VMFS であり、datastore1 となる部分だ。ここは、ディスクの残り領域がすべて割り当てられる。8GBのメディアの場合、600MiB程度が VMFSとして確保される。
ここであれ?っと疑問に思われた方は正しい。そう、VMFS は 600MiB なんてサイズでは構成できない。vSphereClient から datastore1 を削除した後、再作成は失敗する。
この制限以下の小さな VMFS は、インストール時にのみ現れる特別なものらしい。
閑話休題、scratch が必要な場合は 5.2GB 以上のメディアを使うようドキュメントにはあるが、0.9GiB + 2.5GiB(拡張ダンプ) + 4GiB(scratch) では、7.4GB 程度が必要に見える。
そこで、6GB の場合を試してみた。
● 6GB の場合
6GB では、パーティションテーブルはこうなった
| ID | 開始セクタ | 終了セクタ | サイズ | 形式(FS) | 用途 |
| 1 | 64 | 8191 | 4MiB | systemPartition (FAT32) | EFI |
| 5 | 8224 | 520191 | 250MiB | linuxNative (FAT32) | /boot |
| 6 | 520224 | 1032191 | 250MiB | linuxNative (FAT32) | /altboot |
| 7 | 1032224 | 1257471 | 110MiB | vmkDiagnostic | Coredump |
| 8 | 1257504 | 1843199 | 286MiB | linuxNative (FAT32) | /store |
| 2 | 1843200 | 10229759 | 4GiB (FAT32) | linuxNative (FAT32) | /scratch |
| 3 | 10229760 | 12582878 | 約1.1GiB (残り全部) |
vmfs | datastore01 |
ID9 の拡張ダンプパーティションが消えている。その分、余りが増えるため VMFS 領域が拡大しているのが分かる。VMFS領域を抜くと、約 4.9 GiB になる。つまりは、SI単位系で言うところの約 5.2GB である。厳密に言うなら、scratch の最終セクタが 10229759 であり、1セクタが 512バイトのため、5237636608 バイトが必要である。これを1024 で割っていくと 4.87GB となり、1000 で割ると 5.2GB となる訳だ。
そして余った分が VMFS の領域になる。
もし、余りが 2.5GiB 以上あれば、拡張ダンプパーティションが作成され、そこからの残りで VMFS が作成される。
共有ディスクに、複数 ESXi のログまとめて管理したり、syslog で飛ばして LogInsight を使う、とかでも無い限り、scratch はあるに越したことない。
このため、おとなしく 5.2GB以上、実質的には 8GB のフラッシュメディアを用意しておくのが正解、となる。
なお、こちらのKBには面白いことが書いてある。
リテール購入品の 16 GB 以上の USB フラッシュ ドライブを使用すると、「予備の」フラッシュ セルで起動メディアを長持ちさせることができるのでお勧めしますが、コアダンプの拡張パーティションの保持には 4 GB 以上の高品質ドライブがあれば十分です。16GB にしておくことで、ウェアレベリングが効いてより長持ちすると言うことだ。
後半の文章が謎だが、8GB の誤植ではないかと思われる。
2015/02/20
vExpert 2015 受賞しました
今年も vExpert 2015 を受賞できました。ありがとうございます。
http://blogs.vmware.com/vmtn/2015/02/vexpert-2014-announcement-2.html
http://blogs.vmware.com/vmtn/2015/02/vexpert-2014-announcement-2.html
2014/07/27
[ヨタ] Fusion はいつ買い時か?
Fusion のリリースノートを順に追いかけたり、Wikipedia のエントリなどを見ると確認できるが、VMware Fusion のメジャーリリースは以下となっている。
- 1.0 2007/8/6
- 2.0 2008/9/12
- 3.0 2009/10/27
- 4.0 2011/9/14
- 5.0 2012/8/23
- 6.0 2013/9/19
見事に秋口にまとまっているのが分かる。大まかに言って理由は二つある。
一つは、OS X のリリースだ。WWDCの影響もあり、こちらは大まかに初夏から秋にかけてのリリースとなる。
- 10.6 Snow Leopard 2009/8/28
- 10.7 Lion, 2011/7/20
- 10.8 Mountain Lion, 2012/7/25
- 10.9 Mavericks, 2013/10/22
- 10.10 Yosemite, 2014/秋?
どちらの製品も 2010年が欠如していることから見えてくるように、OS X のリリースに合わせて、Fusion の新バージョンが出てきている、といっても過言ではない。
もう一つは VMworld SanFrancisco の存在だ。例年8月末に行われるこのイベントに合わせて新バージョンが用意され、程なくリリースされている。
開発者向けの OS X 10.10 Yosemite のプレビュー版は6月のWWDCにてアナウンスされ、以後 OSカーネルからの大幅な変更で阿鼻叫喚の修羅場が静かに巻き起こっているようだが、それに加えて、10.0 以来とも思われる一般ユーザ向けのパブリックベータ版も出てきている。
Mac開発者だった当時はドッグフードをかっ喰らう生活、そう不安定な開発者版でメールなどの日常の処理からアプリケーションの開発までやってたので、「アップルが開発者向けに出しているものは気軽に常用できるものでない、苦労を買うだけだからやめておけ」と思うのだが、しかも Yosemite は聞いた限りではかなり厄介な事態になってる、-- たとえばこの blog によるとデバイスドライバ(KEXT)にAppleの証明書が必要になり、署名のないドライバーはロードできなくなっている -- ので、どうせ後数ヶ月の話なのだから、リリースまで待った方が賢明である。
だが、OS X はアクティベーションのような強いライセンス認証を持たない。(それどころかインストールに際してライセンスキーすら確認されない)。このため、開発者向けプレビュー版の漏洩とアンダーグラウンドでの流通は毎度のことである。どうせ突っ込みたがる人間がいるなら、いっそ分かる形で出した方がマシ、っていうことなのだろう。
VMware Fusion についてもβ版が出てきている。
仮想ハードウェアバージョン11 のサポートや、Library ウィンドウからリモートの仮想マシンを操作できる、などの機能がアナウンスされている。特に ESXi の仮想マシンをリモートコントロール出来るのは気になる機能だ。これは VMware Workstation には既にあった機能だが、「クリエイティブ向け」とされた Mac では外されていたものだ。
いわゆる IT Pro 系のSEや、OSS系ではない普通の開発者にも Mac は浸透してきている。Fusion Professional ではそうしたインフラ系エンジニアにとって便利な機能が着実に整備されてきている。
さて、現在βの 次期 Fusion はいつリリースだろうか? 多分 VMworld SF にて詳細が語られ、その後、おそらく Yosemite のリリースの前後にリリースされるのだろう。
そういう意味では、特に個人ユーザはもう少し、秋口まで待ってみるのもいいかもしれない。新しいバージョンがでてから購入するも良し、リリースぎりぎりになって現行バージョンを買うも良い。
なお、現在の VMware Fusion 6.0.4 は Yosemite との互換性があるらしい。今の Fusion を買っても、Yosemite で即動かなくなることはないだろう。
確証は出来ないが、例年、新バージョンがでれば直近に旧バージョンを買ったユーザ向けに無償アップグレードがでたりする。現行バージョンを使い尽くしてから、パッチが落ち着いてから新しいバージョンにアップグレードしても遅くはないわけだ。
また、βテストユーザ向けにはディスカウントコードがでることもある。とりあえずβテストに申し込むのも手だ。
なお、10ライセンス以上をまとめて購入できる企業等の場合、vSphere などにもある Basic/Production の SnS (保守サービス)を購入することが出来る。SnS は「Support and Subscription」の略で、有効期間中に問い合わせなどサポートを受けれるのだが、そこにはフリーアップグレード/ダウングレード権が含まれている。Fusion 6 をまとめ買いして、SnS をつけておき、次のバージョンがでたらSnSの権利下で無償アップグレードをする、という感じだ。
2014/06/04
VMware Tools でカスタムスクリプトを実行させる
VMware Tools には、ゲストOSの起動/終了時、および仮想マシンをサスペンドやレジュームしたときにスクリプトを実行する機能がある。
Windows の場合は 「%ProgramFiles%\VMware\VMware Tools」 以下に以下のバッチファイルがあるのが見てとれるだろう。このバッチファイルが、それぞれのタイミングで実行されるスクリプトだ。
なお、Linux, FreeBSD, Solaris などUNIX系のOSの場合、/etc/vmware-tools 以下に同等のファイルが存在する。
OS X をゲストOSとして動かしている場合は、/Library/Application Support/VMware Tools/ 以下だ。
これらのスクリプトを編集することでOSの起動直後や終了前に様々な処理を追加する事ができる。特に View のデスクトップVMなどでは、終了前に ipconfig /flushdns, ipconfig /release をかけておきたいものだが、この機能を使えば簡単に実現できる。
ただ、特に Windows 版では、上記のスクリプトはインストール時に少々きつめの制限がかかってて、編集に苦労する。また resume と suspend については、実は空ではなく VMware 社自身の処理が入っていたりもする。念のために残しておきたいものだ。
そこで、デフォルトのスクリプトを編集するのではなく、スクリプトを別途作成、デフォルトのスクリプトに代わって VMwareTools に実行させる。これがカスタムスクリプトだ。
Fusion 4.0 や vSphere 5.0 までの VMware Tools では、GUIからカスタムスクリプトを指定することができた。
しかし、Fusion 5 や vSphere 5.1 ないしそれ以降の VMware Tools ではこのUIがなくなってしまっている。
では、カスタムスクリプトを指定するにはどうすればいいかというと、GUIではなくコマンドラインからになる。VMwareToolboxCmd というコマンドが増えており、これをつかうのだ。
(Linux/FreeBSD/Solaris は /usr/bin/vmware-toolbox-cmd 、OS X は何故か /Library/Application Support/VMware Tools/vmware-toolbox-cli とコマンド名からして他のUNIX系と異なる)
Windows 版ではこのコマンドは VMware Tools のインストールディレクトリにある。
ただ、何故かこのディレクトリをカレントディレクトリにして使うことを前提としている節があるので、まず cd しておいたほうがいいだろう。
使い方は、「VMwareToolboxCmd help」を実行すると表示される
現在のシャットダウン時に実行するスクリプトのパスを表示するには「VMware Tools script shutdown current」で表示される
シャットダウン時のカスタムスクリプトを設定するには「VMware Tools script shutdown set "フルパス"」で指定する。相対パスは使えないので注意だ。
なんでこんなことをいまさら書いているかというと、カスタムスクリプトを仕掛けておいた vSphere 4.x 時代の仮想マシン(テンプレート)をずっと使っていたのだが、新しく作った仮想マシンでも同じくカスタムスクリプトをしかけようとして、見てみたら VMwareTools の GUI が無くなっており、設定ができなくなって焦ったから、だったりする。
Windows の場合は 「%ProgramFiles%\VMware\VMware Tools」 以下に以下のバッチファイルがあるのが見てとれるだろう。このバッチファイルが、それぞれのタイミングで実行されるスクリプトだ。
- poweron-vm-default.bat
- poweroff-vm-default.bat
- resume-vm-default.bat
- suspend-vm-default.bat
なお、Linux, FreeBSD, Solaris などUNIX系のOSの場合、/etc/vmware-tools 以下に同等のファイルが存在する。
OS X をゲストOSとして動かしている場合は、/Library/Application Support/VMware Tools/ 以下だ。
これらのスクリプトを編集することでOSの起動直後や終了前に様々な処理を追加する事ができる。特に View のデスクトップVMなどでは、終了前に ipconfig /flushdns, ipconfig /release をかけておきたいものだが、この機能を使えば簡単に実現できる。
ただ、特に Windows 版では、上記のスクリプトはインストール時に少々きつめの制限がかかってて、編集に苦労する。また resume と suspend については、実は空ではなく VMware 社自身の処理が入っていたりもする。念のために残しておきたいものだ。
そこで、デフォルトのスクリプトを編集するのではなく、スクリプトを別途作成、デフォルトのスクリプトに代わって VMwareTools に実行させる。これがカスタムスクリプトだ。
Fusion 4.0 や vSphere 5.0 までの VMware Tools では、GUIからカスタムスクリプトを指定することができた。
 |
| Fusion 4.0 までのタスクトレイのメニュー |
 |
| VMware Tools を開くを選ぶと、各種設定が可能 |
しかし、Fusion 5 や vSphere 5.1 ないしそれ以降の VMware Tools ではこのUIがなくなってしまっている。
 |
| Fusion 5.0 ないしそれ以降のタスクトレイのメニュー |
 |
| VMware Tools についてを選んでも情報が見えるだけだ |
では、カスタムスクリプトを指定するにはどうすればいいかというと、GUIではなくコマンドラインからになる。VMwareToolboxCmd というコマンドが増えており、これをつかうのだ。
(Linux/FreeBSD/Solaris は /usr/bin/vmware-toolbox-cmd 、OS X は何故か /Library/Application Support/VMware Tools/vmware-toolbox-cli とコマンド名からして他のUNIX系と異なる)
Windows 版ではこのコマンドは VMware Tools のインストールディレクトリにある。
ただ、何故かこのディレクトリをカレントディレクトリにして使うことを前提としている節があるので、まず cd しておいたほうがいいだろう。
使い方は、「VMwareToolboxCmd help」を実行すると表示される
現在のシャットダウン時に実行するスクリプトのパスを表示するには「VMware Tools script shutdown current」で表示される
シャットダウン時のカスタムスクリプトを設定するには「VMware Tools script shutdown set "フルパス"」で指定する。相対パスは使えないので注意だ。
なんでこんなことをいまさら書いているかというと、カスタムスクリプトを仕掛けておいた vSphere 4.x 時代の仮想マシン(テンプレート)をずっと使っていたのだが、新しく作った仮想マシンでも同じくカスタムスクリプトをしかけようとして、見てみたら VMwareTools の GUI が無くなっており、設定ができなくなって焦ったから、だったりする。
登録:
投稿 (Atom)