仮想マシンで3Dアクセラレーション 第3回：Linuxホスト×Linuxゲスト環境でVMGLに挑戦 ― 果たして可能なのか？

仮想化に関するシリーズ第3回となる本記事は、おそらくシリーズ中で最も難易度の高い内容です。これまで、VMware製品ではDirectXサポートが、VirtualBoxではOpenGLサポートが提供されてきましたが、いずれもWindowsゲスト限定のものでした。ホスト側のOSは問われません。では、Linuxゲストではどうなるのでしょうか?

当初は不可能だと考えていました。ところが、linux.comの記事で、VMGLというアプリケーションを使えばLinuxゲストでも3D描画を楽しめると知りました。非常に有望に見えた一方で、難しそうでもありました。5〜10分の手軽なハックではなく、かなり大掛かりな作業になる予感がしました。そこで、本当に実現できるのか、実際に検証してみることにしました。

その答えは…

答えはこうです。「動くはずです」「あとは〇〇するだけです」といったフレーズが使われた記事・チュートリアル・ガイドを目にしたら、要注意です。大量の苦労が待ち受けています。

元記事も、作者自身のアプリケーションドキュメントも、ゴールにたどり着くまでに必要な泥臭い作業の約9割を考慮していません。本チュートリアルでは、Linux仮想マシンで3Dアクセラレーションを(おそらく)動作させるために必要な、あらゆる厄介な詳細をお見せします。

P.S. シリーズ前半の2記事もぜひご覧ください。

• 仮想マシンでの3Dアクセラレーション パート1:VMware & DirectX - チュートリアル
• 仮想マシンでの3Dアクセラレーション パート2:VirtualBox & OpenGL - チュートリアル

VMGL:OpenGL 3Dアクセラレーション - 完全版の手順

まずVMware Serverから始め、その後同じ手順をVirtualBoxでも試します。

インストール

パッケージのダウンロードとインストール自体は簡単です。配布形式がRPMのため、Debian系ディストリビューション(Ubuntuなど)を使っている場合は、まずalienパッケージをインストールし、RPMをDEBに変換する必要があります。

sudo apt-get install alien

続いて、RPMパッケージをDEB形式に変換します。

alien -k package.rpm package.deb

最後にインストールします。

rpm -i package.rpm
または
dpkg -i package.deb

「package」の部分は実際のVMGLパッケージ名に置き換え、ホスト側とゲスト側の両方にインストールしてください。

注意点として、RPM/DEBのインストール時には(表面上は)エラーが表示されません。しかし、ソースからビルドしようとすると完全に混乱します。build-essential一式(gcc、make、カーネルソース、カーネルヘッダ)に加え、imake、python、OpenGLヘッダなど、膨大な依存パッケージを揃える必要があります。

残念ながら作者は必要な依存関係の完全なリストを提示していないため、こちらで試行錯試行錯誤しながら推測するしかありません。

しかもソースコード自体も完全に壊れています。

Ubuntuゲスト上でも同様の結果でした。

この段階で諦めてしまう可能性は十分にあります。ただしRPM/DEBパッケージを使えば、一見すべてうまくいったように見えるため、そのまま先へ進んでしまうことになります…。

モジュールのロード

次のステップはxorg.confファイルの編集です。以下のようなセクションを追加します。

Section "Module"
Load "vmglext"
EndSection

変更を反映させるため、ゲストのX Window Systemを再起動します(Ctrl + Alt + Backspace)。

Xvncサーバーの起動

次に、ゲスト内で改造版のXvncサーバーを起動します。OpenGLトンネリングの魔法はすべてこのサーバーが担ってくれるはずです。

さて、ここからが本当の難所です。作者が使用したサーバーは非常に古いバージョンで(おそらく所属大学で使われていたものをそのまま流用したのでしょう)、理由は不明ながら、現代のディストリビューションでは動作しません。現在のディストリビューションには存在しないファイルやフォルダのパスを前提としているためです。

SUSE 11.0とUbuntu 8.10の両方で、エラーを出さずにサーバーを起動させるために相当なハックが必要でした。大量のエラーが発生します。

2003年頃のパッケージでアプリケーションを構築すると、こうなってしまいます。幸い、解決策は「簡単」です。問題を修正していきましょう。

rgb.txtの入手

最初のエラーはこれです。rgb.txtをインターネット上で探し(googleで検索すれば見つかります)、ダウンロードして、パッケージが期待する場所に配置します。ファイル内の空行は構文エラーの原因になるため、すべて削除しておきましょう。

Xvncサーバーが参照する場所に直接置いてもよいですが、より良い方法として、/etc/X11/rgb.txtに本体を置き、シンボリックリンクを作成します。

cd /usr/X11R6/lib/X11
sudo ln -s /usr/share/X11/rgb.txt
cd /usr/share/X11
sudo ln -s /etc/X11/rgb.txt

この時点で、次のような状態になります。

見た目が汚いですね。実際、汚いのです!

次は、不足しているフォント類についてもシンボリックリンクを作成します。

cd /usr/X11R6/lib/X11/fonts
sudo ln -s /usr/share/fonts/X11/100dpi
sudo ln -s /usr/share/fonts/X11/75dpi
sudo ln -s /usr/share/fonts/X11/encodings
sudo ln -s /usr/share/fonts/X11/misc
sudo ln -s /usr/share/fonts/X11/Type1
sudo ln -s /usr/share/fonts/X11/util

ここまで進めると、Xvncサーバー起動時に依然としてエラーは表示されるものの、今度は実際に動作するようになります。

次に、ホスト側でvncviewerを実行します。言うまでもなく、ゲストはホストから到達可能なIPアドレスを持っている必要があります。つまり、ゲスト仮想マシンにはブリッジ接続かNAT接続のネットワーク設定が必要です。

vncviewer guest-ip-address:1

接続すると、このような画面になります。

ゲスト側でGLSTUB環境変数をエクスポートします。

export GLSTUB=guest-ip-address:port

今回のケースでは、GLSTUBはポート7001を指しています。ゲストのIPアドレスが192.168.34.129なので、次のように指定します。

export GLSTUB=192.168.34.129:7001

さあ、これで魔法のようにすべて動くはず…!

ところが、動きません。glxinfoを実行してもvmglextドライバーが使用中とは表示されず、指示どおりglxgearsを動かしても、以前と変わらない悲惨なパフォーマンスしか得られませんでした。壊れたパッケージ群を考えれば、当然といえば当然の結果です。

VirtualBoxで全部やり直してみる

原因はVMware ServerのNATやプロプライエタリなコードにあるのではないかと考え、今度はUbuntuホスト上でVirtualBox OSE版を使い、Ubuntuゲストで同じ手順を試しました。ブリッジネットワーキングも設定しています。

ブリッジネットワーキングの設定自体は本題と直接関係ありませんが、ホストとゲストを通信させるために必要なコマンド一式をご紹介します。詳細については「VirtualBox - Community Ubuntu Documentation」を参照してください。

私が実施した手順は以下のとおりです(皆さんの環境や設定とは異なる場合があります)。

1. ホストにブリッジユーティリティをインストール

まず、ネットワークインターフェースをブリッジしてIPアドレスを共有できるよう、bridge-utilsをインストールします。

sudo apt-get install bridge-utils

2. ネットワーク設定ファイルでブリッジを宣言

ブリッジユーティリティのインストール後、ネットワーク設定ファイルに定義を追記します。Debian系システムでは、設定は/etc/network/interfacesという単一ファイルにまとめられています(RedHat系ディストリビューションでは、アダプターごとに個別の設定スクリプトを使用します)。

P.S. IPアドレスは自分で選んだ静的アドレスを使用してください。

sudo gedit /etc/network/interfaces

--- 以下を追記 ---
auto br0
iface br0 inet static
    address 192.168.3.100
    netmask 255.255.255.0
    gateway 192.168.3.1
    bridge_ports eth0 vbox0

3. VirtualBox用の仮想ネットワークアダプターを宣言

これにより、VirtualBoxがbr0ブリッジを利用できるようになります。

sudo gedit /etc/vbox/interfaces

--- 以下を追記 ---
vbox0 <your user name> br0

4. ネットワークとVirtualBoxドライバーの再起動

設定ファイルへの追記が完了したら、ネットワークサービスとVirtualBoxの両方を再起動し、変更を反映させます。

sudo service networking restart
sudo /etc/init.d/virtualbox-ose restart

5. 権限を調整するためのファイル操作

VirtualBoxがネットワークトンネリングデバイスを利用できるよう、権限の変更が必要になる場合があります。

sudo chown root:vboxusers /dev/net/tun
sudo chmod 666 /dev/net/tun

6. ゲストにvbox0仮想アダプターを割り当て

この作業はホストマシン上で行います。対象の仮想マシンの「Settings(設定)」メニューから該当項目を選択してください。

7. ゲストを起動し、静的IPアドレスを割り当て

このアドレスは、ブリッジと同じサブネットに属している必要があります。つまり、最終オクテットを1つ増やすだけでOKです。

sudo ifconfig eth3 192.168.3.101 up

8. 先ほどの手順をすべて再実行

「完全版の手順」の冒頭に戻り、セットアップ全体をもう一度実行します。そして結果は…やはり動きません。魔法はどこへ?

結論

結局のところ、Linux仮想マシン上で3Dアクセラレーションを楽しむことは、私のような詳しいギークを含め、99.999995%のユーザーには無理な話でした。このプロジェクトは、どうやら誰かの博士論文研究らしいのですが、いかにも学術的な成果物といった印象です。中途半端で、普通の人には使い物にならないのです。

私が最も理解できないのは、「いくつかの小さなハックをするだけで準備完了」と謳っている点です。まるで朝露の入ったカップの話でもしているかのようです。実際には、5分のはずのハックが3〜4時間の苦痛に変わりました。そもそも、なぜ6年も前のバージョンのXvncを使う必要があったのでしょうか?

しかし、何よりも腹立たしいのは、これほど未完成な状態のまま製品を公開したという事実そのものです。恥ずべきことです。とはいえ、すべてが失われたわけではありません。3つのうち2つは成功しています。WindowsゲストにおけるVMwareのDirectXサポートと、VirtualBoxのOpenGLサポートは、まさに宝石のような機能でした。

それでも嘆くことはありません!VMwareとSunは仮想化業界の大手プレイヤーです。LinuxユーザーがLinuxゲスト上で3Dアクセラレーションを快適に楽しめる日も、時間の問題でしょう。

すべてを総合的に考えると、Linuxホスト/Linuxゲスト間の3Dアクセラレーションの需要は、実はそれほど大きくないとも言えます。WindowsユーザーはおそらくWindowsのみを使い、Linuxが必要になればデュアルブートを選ぶでしょう。逆にLinuxユーザーは、レガシーアプリケーションを動かすためにWindowsゲストを求めることが多く、その用途にはすでに解決策(むしろ複数)が存在します。Linuxの中でLinuxを動かす仮想化は面白い発想ですが、大多数の人にとっては優先事項ではないのです。とはいえ、いずれ必ず実現します。私の言葉を覚えておいてください。

締めくくりに、ここまでの道のりを振り返りましょう。このシリーズを通じて、貴重な教訓をいくつも得ることができました。VMware ServerとVirtualBoxを使ってWindowsゲスト上で3Dアクセラレーションを楽しむ方法を学び、その過程で数々のクールなハックやテクニックも身につけました。何より重要なのは、デスクトップ仮想化が絶えず進化を続け、私たちの目標と願望をさらに先へと押し進めてくれているという事実です。

それでは、また次回。