Windows Virtual PC & Fedora 13 & openSUSE 11.3 再び ･･･ 動いた!!...けど

Linux IS v2.1 の提供開始で Hyper-V 上でも Linux ゲストが何とか運用できるレベルになりました (サポート対象 OS に限られますけど → 過去の投稿へ)。これに対して、“Windows Virtual PC で最新 Linux を動かす”ことは、ほとんど意味 (メリット、やる価値) が無いことなのが分かっているのですが、多くの方が興味のある話題のようなので、あきらめかけていた  Fedora 13 と openSUSE 11.3 に再挑戦します。Hyper-V でのお話は、こちらをどうぞ。

Hyper-V & Fedora 13 & Windows Virtual PChttp://yamanxworld.blogspot.com/2010/07/hyper-v-fedora-13-windows-virtual-pc.html
Hyper-V & openSUSE 11.3 & Windows Virtual PChttp://yamanxworld.blogspot.com/2010/07/hyper-v-opensuse-113-windows-virtual-pc.html

Windows Virtual PC & Fedora 13 再挑戦

結論から言うと、Windows Virtual PC & Fedora 12, openSUSE 11.2 (http://yamanxworld.blogspot.com/2009/12/windows-virtual-pc-fedora-12-opensuse.htm) で説明したのと同じ方法で Fedora 13 を Windows Virtual PC の仮想マシンにインストールすることができました。

同じ方法とは...

1. インストール時にオプションとして「noreplace-paravirt vga=0x317」を指定する。
2. 「システム クロックで UTC を使用」のチェックを外す。
3. 「おめでとうございます。Fedora のインストールが完了しました」の画面が表示され、「再起動」をクリックしたら、もう一度、インストール DVD を使用して起動して Rescue installed system でディスクをマウントする。そして、(/mnt/sysimage)/boot/grub/menu.lst の起動エントリにも noreplace-paravirt vga=0x317 を追記する。

違いがあるとすれば、DVD イメージ (Fedora-13-i386-DVD.iso) を仮想マシンの DVD ドライブに直接指定するのではなく (直接指定するとメディアが原因で Error になります)、Daemon Tools Lite (http://www.daemon-tools.cc/jpn/home) 経由でマウントしたこと、そして、3072 MB (3 GB) のメモリを仮想マシンに割り当てたことです。1 GB、2 GB で試し、3 GB でようやくインストールが最後まで完了しました。どう見ても過剰な割り当てのようですが、これでも仮想マシンはスローな感じです。インストール完了後は 1 GB のメモリ割り当てでも起動できますが、さらに動きは遅く感じますし、vpc.exe (Virtual PC ホスト プロセス) がCPU 使用率を必要以上に高めている感じがします。Linux ゲストの性能には、プロセッサの性能も大きく影響しているようです (Pentium D 3.4GHz を使用)。

Windows Virtual PC & openSUSE 11.3 再挑戦

openSUSE 11.3 のほうも、幾度かの失敗を経て、なんとかインストールを完了させ、動かすことが出来ました。

openSUSE 11.3 のほうは、Fedora 13 のときと同じ物理マシンでは、どうしても途中でストップしてしまいます。ストップする場所は、インストールを試すたびに違っているのですが、最高でも 71 % どまり。


もしやプロセッサの種類や性能が影響しているのではと思い、Core 2 Duo マシンで試したところ、途中問題はありましたが、インストールを完了することができました。手順は openSUSE 11.2 のときと同じ。openSUSE-11.3-DVD-i586.iso を Daemon Tools Lite 経由で使用し、起動オプションに「noreplace-paravirt vga=0x317」を指定してインストールします。

問題とは、インストールの最終段階である自動構成のステップ (最初の再起動後のステップ) が失敗し、ユーザーの作成や自動構成、X (KDE) の構成が行われなかったことです。

仮想マシン起動時にコンソールに表示される、「VMBUS: ...」「VMBUS_DRV: ...」「VMBUS: Windows hypervisor detected!」という文字が見えるのも気になります (Windows Virtual PC であることをお忘れなく)。自動構成の失敗に関係しているかどうかはわかりませんが、Windows Virtual PC を Hyper-V と誤検出して、Hyper-V & openSUSE 11.3 & Windows Virtual PC でも触れた hv_vmbus をロードし、面倒なことになっているようです。毎回の起動時にこのあたりでかなりの時間を食います (起動オプションに noprobe を追加することで時間を節約できるかもしれません)。

とりあえず、テキスト モードのログイン画面は表示されます。root でログインし、startx で X を起動すれば、KDE (英語) も起動します。自動構成は失敗しましたが、ユーザーの作成や X の構成などは手動設定できるので、openSUSE 11.3 の巻はこれでよしとしましょう (動くってことで一応は成功、中途半端でごめんなさい)。

試してはいませんが、こちらの物理マシンで Fedora 13 をインストールすれば、もっとすんなりいったかもしれません。Windows ゲストの場合、プロセッサの種類や性能の違いがゲストの動作の可否にまで影響することはほとんどない (Windows 95/98 の場合はクロック数が影響する場合があります → 過去の投稿へ) のですが、Linux ゲストの場合は影響が大きいようです。

“Windows Virtual PC で最新 Linux を動かす” 意味がない理由

苦労してサポート対象外の Linux ゲストを Windows Virtual PC で動かしても、ゲスト コンポーネントが存在しないため、適切なパフォーマンスで実行することができません。ていうか、パフォーマンスは非常に悪いです。ホストとの時刻同期機能もないので、ゲスト OS が正しい時を刻んでくれないことも致命的な問題になります。たとえば、先ほどの Fedora 13 ですが、1 分間に 4 ～ 5 秒時計が先に進んでしまいます。これは、NTP など他の方法で訂正できる範囲を超えていると思います。時間にシビアなアプリケーションだと、大きな時刻訂正が入ると意図しない動きをするかもしれません。

というわけで、Windows マシン上で Linux ゲストを動かしたいなら、Oracle VM VirtualBox や VMware Player など、Linux ゲストが得意なものを使った方がよっぽど簡単です。

Hyper-V で Linux ゲストが何とか運用できるレベルになったと言ったのは、x64 ゲストや マルチ プロセッサのサポートもそうですが、Linux IS v2.1 でようやくホスト－ゲスト間の時刻同期機能が提供されたことが大きいと思ってのことです。時刻同期は、稼働中の仮想マシンでも重要ですが、保存状態の仮想マシンを再開したときにも重要になります。