VMware Player 2.0.5でのゲストOS→ホストOSのSMB/CIFS共有アクセスの極端な遅延
ホストOSを入れ替えたあと、以前から使っていた仮想マシンを使用してホストOSのWindows共有にアクセスすると、非常に遅くてタイムアウトになる症状が起きた。
数ヶ月前にもやはりホストOSを入れ替え、同じ症状に悩まされたことを思い出し、今度は謎解きしようと思った。
（結果を先に書く。根本解決はできなかった。同じ症状で、ググって辿り着いたひと、ゴメン。でも回避策はうまく行った）
環境はこんな感じ。
・ホストOS……Windows Server 2003 Enterprise Edition SP2
・ゲストOS……Windows XP Professional Edition SP3
ホストOSではVMware Player 2.0.5を用いてゲストOSを動かしている。
ホストOSからゲストOSのSMB/CIFS共有にアクセスした場合、全く問題がない。
ゲストOSから他のWindowsやubuntuのSMB/CIFS共有にアクセスするのも、今まで通り全く問題が無い。
ただ、ゲストOSからホストOSの共有にアクセスすると非常に遅くて、たいていの場合、途中でタイムアウトになってしまう。エクスプローラは応答がなくなるし、テキストエディタから「前回開いたファイル」でホストOS上のファイルを選ぶだけで、凍りついて固まってしまう。
ゲストOSからホストOS上のWindows共有ファイルにアクセスした時だけ、ダメなのだ。
試しに、他のゲストOSも試したが、同じ症状が起きた。
もう数ヶ月以上使ってないやつとか、他のマシンで使っている仮想マシンなどを持ってきて動かしてみたが、全く同じ症状が起こる。ということは、ゲストOSの問題ではないのだろうか？
何とはなしに、IPあるいはイーサネットレベルで輻輳でも起こしてるのではないかと、根拠のない妄想を抱き、ホスト・ゲスト双方でnbtstat -Rとか、適当にやらかしてみるが、さっぱり効果が無い。
困り果ててWiresharkでパケットを追ってみるが、ますます、何が悪いのかさっぱりわからん。（どこかが悪いように見えない。私の目が節穴なので見つけられないのかもしれないが）
以前同じ症状になった時、どうやって直したか思い出せない。日記をgrepするが（か、書いてたのか俺）何もヒントが出てこない。
どうも、記憶があやふやだが「自然に」直ったような気がするんだ。
とにかく具合が悪いのは、ゲストOS→ホストOSのみであるから、VMware共有フォルダの機能を使って回避することにした。
まず、ゲストOSのvmxファイルに、次のような設定をエディタで書き加える。
sharedFolder.maxNum = "2"sharedFolder0.enabled = "TRUE"
sharedFolder0.present = "TRUE"
sharedFolder0.writeAccess = "TRUE"
sharedFolder0.readAccess = "TRUE"
sharedFolder0.hostPath = "D:\"
sharedFolder0.guestName = "hotsuma1"
sharedFolder0.eXpiration = "never"sharedFolder1.enabled = "TRUE"
sharedFolder1.present = "TRUE"
sharedFolder1.writeAccess = "TRUE"
sharedFolder1.readAccess = "TRUE"
sharedFolder1.hostPath = "E:\"
sharedFolder1.guestName = "hotsuma2"
sharedFolder1.eXpiration = "never"
"sharedFolder.maxNum"は、共有フォルダをいくつ設定するかの指定だ。上記の例では、sharedFolder0とかsharedFolder1を使い分けている。2個使うと宣言しているので、0と1の二個、指定出来るわけだ。何個まで使えるのかは調べてないが。
以上のvmx修正が終わったら、ゲストを起動する。そして、VMware Playerのメニューから、「共有フォルダ」を選び、先ほど指定した共有フォルダが表示されていることと、フォルダが有効になっていることを確認しよう。その場で有効に出来るし、VMware Playerの再起動は不要だ。また、ホスト側の場所もその場で変更できる。これで、VMware Player側の準備は終わった。
一方、ゲストOS側の準備も必要だ。今までVMware共有フォルダ機能を使っていなかったゲストOSの場合、これだけでは共有フォルダを利用できない。というのもこの機能を利用するためには、例によってVMware Toolsの助けが必要なのである。が、共有フォルダを無効にした状態でVMware Toolsをインストールしていると、デフォルトでは、このVMware共有フォルダ機能がインストールされないのである。この辺、ハマる人が多い。（っていうか他ならぬ僕がハマったのですが。どれだけの人がハマったか、正直に言うと数えたことは無いぞ）
「VMware Playerメニューに共有フォルダが現れたのに使えないよ！」という場合は、次の点を確認しよう。
もう一回、VMware Toolsのセットアップを起動し、共有フォルダがインストールされているか設定を確認する。
まず、VMware Toolsを再インストールするためには、VMware Playerのインストールディレクトリにあるwindows.isoを、Daemon ToolsやAlcohol 52%などを使ってマウントしよう。実CDに焼いたり、どこかにコピーしてあるならそれを使えば良い。
そして、VMware Toolsのsetup.exeを起動し、「変更」を選ぶと、共有フォルダ機能が見事にオフになっていることが分かるはずだ。早速追加インストールする。
（……説明画像を入れる甲斐性が無い『文字だけブログ』なので、もしここまでの説明で状況を見失うようだったら、他の判りやすいページを探してください）
以上を終えてさらにゲストOSを再起動すると、ネットワークに、見慣れないネットワークが増えている筈だ。これで成功。
(↑なお、環境によっては、「VMware共有フォルダ」のように日本語になる)
マイネットワーク
ネットワーク全体
Microsoft Terminal Services
Microsoft Windows Network
VMware Shared Folders
Web Client Network
さて以上で終了であるが、一つ問題があった。
というのも、僕は、ホストOSから２つ以上のポイントをWindows共有で公開し、それぞれをドライブに割り当てているのである。
ところが、VMware共有フォルダは、試してみるとわかるが、ネットワークドライブを割り当てられるポイントは一つしか公開できないのである。
先に紹介したvmxでは、共有フォルダを２つ公開していた。この二つの共有フォルダ（hotsuma1とhotsuma2）は、
の下に含まれてしまう。だから、３つ、４つといくらでも任意のフォルダを公開することは出来ても、それらは全て一カ所に集められて並んでしまい、個別にドライブを割り当てることが出来ないのだ。僕のように、プログラムを含むフォルダを公開している場合、ディレクトリ構成が変わるの困る。そうでなくても、パスが変わってしまうのは何かとイヤだろう。
\\.host\Shared Folders
そこで、そんな時はMSDOSの昔からある
コマンドのお世話になるしかない。
subst
というわけで、
・まずVMware共有フォルダをマウントするための捨てドライブを一個用意する。僕は普段使わないBドライブにしている。このドライブマウントは、次回起動時も覚えて居てくれるので再設定する手間はかからない
・次にBドラ以下の各フォルダをsubstするバッチファイルを作りログオン時に実行する。
subst ?: /Dは、既にsubstされている設定を消す指定だ。実際に使う時は無くてもいいだろう。
subst N: /D
subst N: B:\hotsuma
subst O: /D
subst O: B:\mnt
ログオンの度に動かすのは面倒！という人は、スタートアップに入れるか、タスクに登録してはどうだろうか。
僕自身は、コントロールパネル→タスクで、上記バッチファイルを「ログオン時」に動かす指定にしている。
……Webで色々な人のブログを見ると、どうやらVMware共有フォルダの方が「速い」らしい。だから、この機能を使うきっかけになったのはとても良かったのだが、最初に挙げた不具合は何に起因するのだろうか。気になって仕方がない。時間が経って直るということは、やはり何らかの古い情報がキャッシュされていて悪さを……と思いたくなるが、さっぱり判らない。
