Mac（OS X）で IE の確認・検証を行うためのベストな方法（VMware Fusion 5 + Windows から、ホストOS の Web アプリケーションに接続する方法）

本当に長い間、苦しめられていた問題がようやく解決しました！！きっと、同じ問題で苦しんでいる人がいるに違いないので、問題と解決方法を簡単にまとめさせていただきます。

やりたいこと

Ruby on Rails を使い Web アプリケーションの開発を行っています。開発環境は、MacBook Pro（OS X Mountain Lion 10.8.4）でブラウザは Google Chrome を普段利用しています。クロスブラウザ検証としては IE, Safari, Firefox で確認していますが、Mac 使いには、IE の確認をどうしよう？というのが課題かと思われます。

こちら、私の聴いた範囲の話だと、人によってやり方がバラバラな気がします...。

そこで、私は、強く！次の方法を推奨いたします！

・OS X 上で仮想環境（VMware Fusion, Parallels, VirtualBox）上に Windows を構築する。
・OS X 上で開発。WEBrick 等で localhost:3000 で起動し、OS X 上で動作確認する。
・そのまま、仮想環境の Windows から OS X に接続し、IE での動作確認する。

以下の IE テスト方法は、やってはいけません。もしこの方法でテストしている方は、作業効率が著しく向上しますので、ぜひ仮想環境でテストする方法に乗り換えていただきたいです。

やってはいけない１：Windows 搭載マシンを１台用意して、そこで IE の検証を行う。

絶対いけません。

もし開発者が３人いたとしたら、誰かがWindows マシンを使っている時、当然ながら、あなたが検証できません。もし Windows 搭載マシンが遠隔地にある場合どうでしょうか？テストすらできません。

現代では、もう少し IE の検証環境というのは進んでおり、完全無料に絞っても１人１台、仮想 Windows 環境を割り当てることが出来ます。私は有料の仮想ソフトウェア（VMware Fusion、Parallels）をおすすめしますが、予算がない方や、面倒な会社の稟議を通すのが億劫である方は、次のソフトウェアを使ってみて下さい。

やってはいけない２：テスト用 Web サーバーを構築して、そこに IE でアクセスして検証する

テスト用 Web サーバー（ステージングサーバー）にアプリケーションをデプロイして、Windows IE からそこに接続して、動作検証をする。これは、アプリケーションの最終チェックとしてはよいですが、開発行程中の確認方法としてはダメダメです。

ダメダメな理由を述べますと...

まず単純に、テストサーバーを構築しないとチェックができない
テストサーバーは、チームで共有することが多いはずなので、個人的な検証に使いにくい
IE でバグが起きた時、修正して、内容を確認するために、いちいちデプロイしなければいけない

特に、確認のために毎回デプロイをしなければいけないというのは話になりません。あなたのソフトウェアがまだ小さければ、デプロイは十分に高速かもしれませんが、それも時間の問題になります。

REPL という言葉をご存知でしょうか？これは Read（読み取り） Eval（評価） Print（表示）を Loop（繰り返す）という関数型言語のことばの頭文字が合わさったものですが、REPL のサイクルは、小さいほど効率的になります。これはプログラマーの開発工程にも同じことが言えて、コーディングを行い（Read）、コンパイル・実行環境を作り（Eval）、結果を確認する（Print）のサイクルが素早く回せるほど、プログラマーは生産的になれます。

IE での環境確認に、毎度デプロイを行うとどうなるでしょうか？プログラマーの REPL のサイクルが、突然大きなサイクルとなり、プログラマーの生産性は低下します。

やってはいけない３：別途 Windows 環境上にも、実行環境を構築する。

IE でのテストが必要な場合に、あなたが Windows に移動してきて、Windows 上で最新のソースファイルをチェックアウトし、サーバーを起動させて、localhost でチェックするというアイデアです。OS X と Windows で２重に環境構築をしなければいけないデメリットはありますが、検証作業自体は高速に行えそうです。

私は開発に Ruby on Rails を利用しているのですが、この方法は、結果的に却下しました。２重の環境構築も問題ですが、
ruby の gem の中には、OS X や Linux 系でしか動作しないものが、結構あります。IE での検証のために、そういったリスクを負うのはできれば避けたいところです。

問題発生！

（だいぶん、話が脱線してしまいましたが...）

上記のような理由により、Google Chrome、Firefox、Safari での確認は、localhost に Web サーバーを起動して OS X から確認。IE からの確認は、OS X 上に仮想環境で Windows を構築し、そこで IE を起動。ホスト OS の IP に接続し、直接確認できるようにしようと思いました。

Windows の仮想環境は、Modern.IE で手に入れることができます。

localhost に Web サーバーを起動して、いざ Windows 側からホスト OSに接続。すると、接続はできたんだけど、なんか画面の表示が異常に重たい！１画面表示するのに 30 秒くらい時間がかかって、洒落にならない！という問題に出くわしてしまいました。。。

仮想マシンのネットワーク接続には、NAT 接続、ブリッジ接続、ホストオンリーといった接続方法があるのですが、どれを試してみても全然駄目！インターネットを調べてみても、問題が解決しない...。

私は次のような条件でテストを行っていました。

目的	Ruby on Rails を使った Web アプリケーション開発
Ruby on Rails	version 3.2.13
Ruby	ruby 1.9.3p448 (2013-06-27 revision 41675) [x86_64-darwin12.4.0]（RVM: Single-User installations）
開発環境 OS（ホストOS）	MacBook Pro ... OS X 10.8.4 Mountain Lion
仮想ソフトウェア	VMware Fusion 5.0.3
ゲストOS	Windows7 （license Modern.IE）
IE バージョン	IE9〜IE10
検証用のWebサーバー	WEBrick

解決策：最終的に、何が問題だったのか？

Windows IE からの接続が異常に重たい原因ですが、私の場合、Ruby on Rails と WEBrick がキーでした。直接の解決になったのは下記の記事でした。

Redmine Webrickちゃんがネットワーク経由で遅い何とかして

根本的な原因は WEBrick でした。localhost からの接続は問題ありませんが、外部環境から接続（ゲストOS→ホストOS）する場合、WEBrick が名前解決を行っているらしく、これが接続を異常に重くしていました。この名前解決を行わないようにすることで、接続がスムーズになりました。

以下、手順。

まず私の場合、ruby のバージョン管理に rvm を使っていましたので、下記の場所に WEBrick の設定ファイルがありました。

/Users/komiya/.rvm/rubies/ruby-1.9.3-p448/lib/ruby/1.9.1/webrick/config.rb

これを vi で開きます。

vi ~/.rvm/rubies/ruby-1.9.3-p448/lib/ruby/1.9.1/webrick/config.rb

下記の場所の設定を、書き換えて下さい。

    # for GenericServer
    General = {
      :ServerName     => Utils::getservername,
      ...
      :StopCallback   => nil,
      :AcceptCallback => nil,
#      :DoNotReverseLookup => nil, # ← 変更前
      :DoNotReverseLookup => true, # ← 変更後
      :ShutdownSocketWithoutClose => false,
    }

これにより、WEBrick の名前解決が無効になります。IE から問題なく接続できることが確認できました。rvm を使っている方は、注意しなければいけないのは、WEBrick の設定ファイルを直接変更しているため、ruby のバージョンアップ等で再インストールしたりすると、そちらも再度、設定をしなければなりません。

ついでに、ゲストOS（VM上の Windows）→ ホストOS（OS X 10.8.4）に接続するためには、VMware Fusion のネットワーク設定の問題に突き当たると思いますので、ここで合わせて説明いたします。

これまで前置きなくしゃべっていましたが、VMware Fusion では VMware Fusion を動かしている OS、実際にハードウェアが存在している環境側のOS を便宜的に「ホストOS」と呼んでいます。この「ホストOS」で動いている VMware Fusion 上で動作している仮想環境を「ゲストOS」と呼びます。

今回「ホストOS」はMacBook Pro の上で動いている「OS X 10.8.4 Mountain Lion」であり、「ゲストOS」は「Windows」です。

「ゲストOS」のネットワーク設定には、主に下記の３つがあります。（確認方法：VMware Fusion → メニュー → 仮想マシン → ネットワークアダプタ）

NAT接続
ブリッジ接続
ホストオンリー接続

詳しい解説は、下記の記事が詳しいですが、ざっくり言うと

「NAT 接続」はホストOS とゲストOS をほぼ共通のものとして扱い、ネットワークの外から観てみると両者の区別がつかない。
「ブリッジ接続」は NAT接続よりもゲストOS を一人前として扱うイメージで、ゲストOS用に専用のネットワークを割り当てる。ネットワークの外から見てみると、ホストOSとゲストOS、それぞれが立派なコンピュータとして認識できる。
「ホストオンリー接続」は、基本的にゲストOSが、外のネットワークに繋ぐことが出来ない。ホストOS間との通信目的のみに使用する。

ようなイメージだと思います。

NAT、ブリッジのネットワーク設定の違いは何ですか？

では、ゲストOS→ホストOS に直接接続したいとき、「NAT接続」「ブリッジ接続」「ホストオンリー接続」のどれを選ぶのが最適なのか？という話ですが... 結論から言うと、どのタイプでもホストOSに接続は可能なようです（私が実際に試した所、どのタイプも接続できました）

NAT接続：ゲストOS（Windows） → ホストOS（OS X）に接続する

NAT接続は、ゲストOS とホストOS のネットワークをほぼ同一に扱う接続ですが、VMware Fusion 5 の NAT接続の設定は下記の場所にあります。

/Library/Preferences/VMware Fusion/vmnet8/

vmnet8 とは VMware Fusion の NAT 接続用の仮想スイッチらしいです。ゲストOS からホストOS に接続するには、ホストOS の IP アドレスが必要なので、ホストOS の IP アドレスを次のファイルから調べましょう。

$ sudo less /Library/Preferences/VMware\ Fusion/vmnet8/dhcpd.conf

「host vmnet8」という項目に「fixed-address」というのがありませんか？それが、ゲストOS から接続するときのホストOS の IP アドレスです。

host vmnet8 {
        hardware ethernet xx:xx:xx:xx:xx:xx;
        fixed-address 192.168.38.1;
        option domain-name-servers 0.0.0.0;
        option domain-name "";
        option routers 0.0.0.0;
}

私の場合、「192.168.38.1」でした。
Windows の IE のアドレスバーに「http://192.168.38.1:3000/」という URL を入力してみて下さい。
おそらくアプリケーションが表示されると思います。

ブリッジ接続：ゲストOS（Windows） → ホストOS（OS X）に接続する

ブリッジ接続では、ゲストOS も外のネットワークから認識できるようになります。ホストOS もゲストOS も、イントラ上で、それぞれ独立して存在している PC のように振る舞われるので、ホストOS の IP アドレスは、ホストOS の「ifconfig」で調べます。

ホストOS（OS X）上で、ターミナルを起動して、下記のコマンドを実行して下さい。

$ ifconfig
...
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether **:**:**:**:**:**
	inet6 ****::****::****::**** prefixlen 64 scopeid 0x4
	inet 192.168.1.101 netmask 0xffffff00 broadcast 192.168.1.255
	media: autoselect
	status: active
...

上記のような出力が出ると思いますが、この場合「192.168.1.101」がホストOSのIPになります。

Windows から IE のアドレスバーに「http://192.168.1.101:3000/」と入力してみて下さい。アプリケーションが表示されます。

ホストオンリー接続：ゲストOS（Windows） → ホストOS（OS X）に接続する

ホストオンリー接続の設定ファイルは次のところにあります。

/Library/Preferences/VMware Fusion/vmnet1/

ご推察の通り、vmnet1 はホストオンリー接続専用の仮想スイッチのようです。

「/Library/Preferences/VMware Fusion/vmnet1/dhcpd.conf」を覗くと、次の設定が見つけられると思います。

host vmnet1 {
	hardware ethernet **:**:**:**:**:**;
	fixed-address 172.16.1.1;
	option domain-name-servers 0.0.0.0;
	option domain-name "";
}

今度は「172.16.1.1」が、ホストOS の IP のようですので、IE に「http://172.16.1.1:3000/」と入力します。これで、確認することが出来ると思います。

と、ここまで書いて気づいたのですが、OS X で「ifconfig」すると「vmnet1（ホストオンリー）」「vmnet8（NAT接続）」のホストOSの IP がちゃんと表示されてますね...。

$ ifconfig
# ...
vmnet1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether **:**:**:**:**:**
	inet 172.16.1.1 netmask 0xffffff00 broadcast 172.16.1.255
vmnet8: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether **:**:**:**:**:**
	inet 192.168.38.1 netmask 0xffffff00 broadcast 192.168.38.255

以下、余談。（解決策に辿り着くまでに、悩んだり、迷ったりしたこと）

私の環境の場合では、WEBrick の問題という事になりましたが、この辺り、環境によって結構問題がいっぱい見つかるようです。

そもそも、私は WEBrick が怪しいという推測が働かなくて、「VMware Fusion」側の問題だと思ってました。次のようなキーワードでずっとググってたのですが、どの情報も駄目でしたね...。

検索してみたキーワード
- VMware Fusion ゲストOS ホストOS 接続
- VMware Fusion localhost 接続
- VMware Windows OS X 接続
- VMware 接続遅い
- VMware connection very slow
- VMware network very slow
- VMware Fusion 5 windows localhost
- OS X ポート開放

VMWare FusionでWin7からMacにlocalhostで接続する方法

接続できるんですが... 接続がめっちゃ遅いんですよね...、なんでだろう。ウィルス対策ソフトをインストールしていたので、最初はそれを疑っていました。検証用に、一時的に無効化してみたりしましたが、解決にはなりませんでした...。

ゲストOSをブリッジ接続していてはまった | ピースペース

この辺りの記事に遭遇して、ネットワークアダプタの設定を疑い始めました。NAT とかブリッジとか、ホストオンリーとか、どれがゲスト→ホスト接続可能で、どれが不可能なのか？みたいな検証をしていたのですが、そもそも NAT とかブリッジとか、詳しく理解ができてないので、あんまり解決にはなりませんでしたね...。

話は変わりますが、VMware Fusion の体系的な開発者向けのドキュメントって、英語でいいので無いのかなぁと思いました。ちょっと見当たらない感じがして...、エンドユーザー向けの、例えば Windows 仮想環境の作り方。とかいうドキュメントは見当たるのですが、vmrun とかすごく便利なのに、PDF 資料しか見当たらないとか... 結構このあたり、ツライなぁ。もう一つの仮想環境の Parallels とかどうなんだろうなぁ...。