- 締切済み
QEMUを使ったホストOS、ゲストOSともりWindowsの場合のファイル共有の仕方
QEMUというのをご存じでしょうか? Fablice Bellard氏により開発されたCPUエミュレーターで、 なんらかのOSの上で、別のOSをアプリのように動かすことができる ソフトウェアの一つです。 いま、わたしはそれのWindows版を使って、 Windows2000(以下ホストOSと呼びます)上で、Windows98(以下ゲストOSと呼びます)を動かしています。 そこで問題となっているのは、ホストOSとゲストOSのファイルの共有 なんです。 ゲストOSからはQEMU内臓のNATを通して外部のインターネットに 接続できています。 しかし、ホストOS-ゲストOS間では相互にマシンが見えません。 当然ファイル共有もできません。 ホストOS、ゲストOSともにWindowsネットワーククライアントの 設定をしてファイル共有も可に設定しています。 ホストOSであるWindows2000には、ルーターのDHCPでプライベートアドレス に198.168.1.x系が設定されています。 一方、Windows2000上で動くゲストOSのWin98は、QEMUが内臓している DHCPで10.0.2.x系が自動的に設定されていて、外部のインターネットにでる時 内臓のNATを通してホストOSのアドレスに変換されてると思います。 (10.0.2.xの値の変更はソースをハックしないとできないと思います。) どなたか、ホストOS、ゲストOSともにWindows系を使って QEMUを使われている方、お知恵を拝借できないでしょうか? 因みに、QEMUにはtftpサーバも内臓されているのですが、 最大転送ファイルサイズで32768バイトしか転送できないので普通の ファイル共有にはちょっと使えません。
- みんなの回答 (2)
- 専門家の回答
みんなの回答
- getchonchon
- ベストアンサー率39% (9/23)
どうもド素人がくちばし挟んで失礼しました 下記URL内の”ユーザーモードでのネットワークの使い方” http://www.h7.dion.ne.jp/~qemu-win/HowToNetwork-ja.html 4. オプション-redirによるホストOSからゲストOSへの接続 というのがそのものっぽい気がしますが・・・
- getchonchon
- ベストアンサー率39% (9/23)
QEMUを使ったことが無いし、エミュレータというのは実機と 仮想機のデバイスを1:1に対応させる役目を果たすだけのもの だと思うので、ホストOS・ゲストOS間でネットワーク構築と いうのが出来るものなのやら分かりませんが、他の(IBM互換機 でない)PCエミュレータだとファイルの相互利用は エミュ側からホストOSの利用ドライブが見えるドライバ ホストOSからエミュのディスクイメージが覗けるツール を使って実現しているのがあります QEMUに入れたOSに対応する上記のようなモノを探して 使った方が早いと思います(あるかどうかは知りませんけども)
お礼
御回答ありがとうございました。 「回答に対する補足」に書かせていただきましたが、ご指摘のようなツール、ドライバは付属していません。 ゲストOSが起動中でない時にディスクイメージを操作するツールは、フリーソフトとかであります。 しかし、やりたいことは、あくまでゲストOS起動中のファイル操作ですので、これは除外されます。 「回答に対する補足」にも書いたようにゲストOSのネットワークセグメントとホストOSのネットワークセグメントはNATで接しているのでWindows系同士ならNBTかCIFSでファイル共有が可能だと思ったのですがダメでした。
補足
因みにQEMUにその手のツールやドライバはありません。 ゲストOS自体はホストOS上にディスクイメージをもっていて、QEMUがそれを読んで、ホストOS上でゲストOSを動かすという感じです。 ついでに、QEMU自体がDHCP/NAT/DNS/Sambaサーバを内臓していて、QEMU固有のネットワークセグメントを構成しています。 それとホストOS側のネットワークセグメントがNATを接点に隣り合っているような感じです。
お礼
御回答ありがとうございました。
補足
そのホームページは既に拝見しています。 -redirオプションは、ホストOSのポートをゲストOSのポートへマッピングする機能です。 この時、マッピングする二つのポート番号は違えないといけません。 なぜなら、同じにしてしまうと、ホストOS側がそのポート番号で受信ができなくなるからです。 CIFSの139/tcpの例で考えて、-redirでゲストOSの139をホストOSの139にマッピングしたとします。 ホストOS側からゲストOSへは、ターゲットをホストOSの139/tcpとします。 これにより、ホストOSの139/tcpを介してゲストOSの139/tcpにアクセスしてCIFSでファイル共有できます。 逆にゲストOSからホストOSへCIFSでファイル共有しようとすると、ホストOSの139/tcpへ直接アクセスする事になります。 これは、-redirオプションは、ホストOSのポートをゲストOSのポートへマッピングする機能であって、その逆はできないからです。 (原文:When using the `-redir' option, TCP or UDP connections can be redirected from the host to the guest. ) それで、ホストOSの139/tcpへ直接アクセスすると、これはゲストOSの139/tcpへマッピングされているので、ゲストOS側で戻ってきてしまいます。 それでは、ポート番号を違えてみましょう。 同じくCIFSの139/tcpの例で考えて、-redirでゲストOSの139をホストOSの140にマッピングしたとします。 ホストOSからCIFSでファイル共有しようとして、ターゲットをホストOSとします。 しかし、CIFSの通信を確立する事はできません。 なぜなら、140/tcpはCIFSで使うポート番号ではなく、CIFSで使うポート番号は139/tcpと決まっているし、Windowsの機構としてそう作られてるからです。 逆に、ゲストOSからホストOSへのCIFSによるアクセスはホストOSの139/tcpへ直接接続しようとします。 結局、いずれの場合でも-redirの設定が全然有効に働かない事になります。 わたしの認識としては、-redirが使えるのは、HTTPでホストOSをプロキシのように使う場合とか、ホストOS側のサービス/デーモンの待ち受けポート番号がある程度自由に設定可能な場合とか、ポート番号の変更の自由度がある場合に限られると思っています。