QEMUを使ったホストＯＳ、ゲストＯＳともりWindowsの場合のファイル共有の仕方

ＱＥＭＵというのをご存じでしょうか？
Fablice Bellard氏により開発されたＣＰＵエミュレーターで、
なんらかのＯＳの上で、別のＯＳをアプリのように動かすことができる
ソフトウェアの一つです。

いま、わたしはそれのWindows版を使って、
Windows2000(以下ホストＯＳと呼びます）上で、Windows98(以下ゲストＯＳと呼びます）を動かしています。

そこで問題となっているのは、ホストＯＳとゲストＯＳのファイルの共有
なんです。
ゲストＯＳからはＱＥＭＵ内臓のＮＡＴを通して外部のインターネットに
接続できています。
しかし、ホストＯＳ－ゲストＯＳ間では相互にマシンが見えません。
当然ファイル共有もできません。
ホストＯＳ、ゲストＯＳともにWindowsネットワーククライアントの
設定をしてファイル共有も可に設定しています。

ホストＯＳであるWindows2000には、ルーターのDHCPでプライベートアドレス
に198.168.1.x系が設定されています。
一方、Windows2000上で動くゲストＯＳのWin98は、ＱＥＭＵが内臓している
DHCPで10.0.2.x系が自動的に設定されていて、外部のインターネットにでる時
内臓のＮＡＴを通してホストＯＳのアドレスに変換されてると思います。
(10.0.2.xの値の変更はソースをハックしないとできないと思います。)

どなたか、ホストＯＳ、ゲストＯＳともにWindows系を使って
ＱＥＭＵを使われている方、お知恵を拝借できないでしょうか？

因みに、ＱＥＭＵにはtftpサーバも内臓されているのですが、
最大転送ファイルサイズで３２７６８バイトしか転送できないので普通の
ファイル共有にはちょっと使えません。

No.1 回答者： getchonchon 回答日時： 2005/07/06 11:47

ＱＥＭＵを使ったことが無いし、エミュレータというのは実機と

仮想機のデバイスを１：１に対応させる役目を果たすだけのもの
だと思うので、ホストＯＳ・ゲストＯＳ間でネットワーク構築と
いうのが出来るものなのやら分かりませんが、他の（IBM互換機
でない）PCエミュレータだとファイルの相互利用は

エミュ側からホストＯＳの利用ドライブが見えるドライバ
ホストＯＳからエミュのディスクイメージが覗けるツール

を使って実現しているのがあります

ＱＥＭＵに入れたＯＳに対応する上記のようなモノを探して
使った方が早いと思います（あるかどうかは知りませんけども）

この回答への補足

因みにＱＥＭＵにその手のツールやドライバはありません。
ゲストＯＳ自体はホストＯＳ上にディスクイメージをもっていて、ＱＥＭＵがそれを読んで、ホストＯＳ上でゲストＯＳを動かすという感じです。
ついでに、ＱＥＭＵ自体がＤＨＣＰ/ＮＡＴ/ＤＮＳ/Ｓａｍｂａサーバを内臓していて、ＱＥＭＵ固有のネットワークセグメントを構成しています。
それとホストＯＳ側のネットワークセグメントがＮＡＴを接点に隣り合っているような感じです。

補足日時：2005/07/06 17:42

この回答へのお礼

御回答ありがとうございました。

「回答に対する補足」に書かせていただきましたが、ご指摘のようなツール、ドライバは付属していません。
ゲストＯＳが起動中でない時にディスクイメージを操作するツールは、フリーソフトとかであります。
しかし、やりたいことは、あくまでゲストＯＳ起動中のファイル操作ですので、これは除外されます。

「回答に対する補足」にも書いたようにゲストＯＳのネットワークセグメントとホストＯＳのネットワークセグメントはＮＡＴで接しているのでＷｉｎｄｏｗｓ系同士ならＮＢＴかＣＩＦＳでファイル共有が可能だと思ったのですがダメでした。

お礼日時：2005/07/06 18:07

No.2 回答者： getchonchon 回答日時： 2005/07/06 21:53

どうもド素人がくちばし挟んで失礼しました

下記URL内の”ユーザーモードでのネットワークの使い方”
http://www.h7.dion.ne.jp/~qemu-win/HowToNetwork- …

4. オプション-redirによるホストOSからゲストOSへの接続
というのがそのものっぽい気がしますが・・・

参考URL：http://www.h7.dion.ne.jp/~qemu-win/index-ja.html

この回答への補足

そのホームページは既に拝見しています。
-redirオプションは、ホストＯＳのポートをゲストＯＳのポートへマッピングする機能です。

この時、マッピングする二つのポート番号は違えないといけません。
なぜなら、同じにしてしまうと、ホストＯＳ側がそのポート番号で受信ができなくなるからです。
ＣＩＦＳの１３９/tcpの例で考えて、-redirでゲストＯＳの１３９をホストＯＳの１３９にマッピングしたとします。
ホストＯＳ側からゲストＯＳへは、ターゲットをホストＯＳの１３９/tcpとします。
これにより、ホストＯＳの１３９/tcpを介してゲストＯＳの１３９/tcpにアクセスしてＣＩＦＳでファイル共有できます。
逆にゲストＯＳからホストＯＳへＣＩＦＳでファイル共有しようとすると、ホストＯＳの１３９/tcpへ直接アクセスする事になります。
これは、-redirオプションは、ホストＯＳのポートをゲストＯＳのポートへマッピングする機能であって、その逆はできないからです。
（原文：When using the `-redir' option, TCP or UDP connections can be redirected from the host to the guest. ）
それで、ホストＯＳの１３９/tcpへ直接アクセスすると、これはゲストＯＳの１３９/tcpへマッピングされているので、ゲストＯＳ側で戻ってきてしまいます。

それでは、ポート番号を違えてみましょう。
同じくＣＩＦＳの１３９/tcpの例で考えて、-redirでゲストＯＳの１３９をホストＯＳの１４０にマッピングしたとします。
ホストＯＳからＣＩＦＳでファイル共有しようとして、ターゲットをホストＯＳとします。
しかし、ＣＩＦＳの通信を確立する事はできません。
なぜなら、１４０/tcpはＣＩＦＳで使うポート番号ではなく、ＣＩＦＳで使うポート番号は１３９/tcpと決まっているし、Ｗｉｎｄｏｗｓの機構としてそう作られてるからです。
逆に、ゲストＯＳからホストＯＳへのＣＩＦＳによるアクセスはホストＯＳの１３９/tcpへ直接接続しようとします。

結局、いずれの場合でも-redirの設定が全然有効に働かない事になります。

わたしの認識としては、-redirが使えるのは、HTTPでホストＯＳをプロキシのように使う場合とか、ホストＯＳ側のサービス／デーモンの待ち受けポート番号がある程度自由に設定可能な場合とか、ポート番号の変更の自由度がある場合に限られると思っています。

補足日時：2005/07/13 01:33

この回答へのお礼

御回答ありがとうございました。

お礼日時：2005/07/13 01:35