x11vnc、Xvfb、Xdummy、VirtualGLの使いこごち

前回記事でリモートX環境を色々入れた。今記事ではその使い心地を簡潔にまとめる。

普通にgdm3へx11vncするとき
gdm3でautologin設定していない時には、まずログインするためのXへ接続する。
graphical.target状態で起動すると、vt7にdisplay :0でログイン待ちになっているので
以下の要領でx11vncを起動する。

$ sudo x11vnc -auth /run/user/117/gdm/Xauthority -display WAIT:0

117はgdmのUserID.

sudoするのは、まだログイン前なのでroot権限が必要だから。

VNCビュアーは、TurboVNCが推奨されている。TurboVNCはX11vncのためにオプティマイズされているからだ。

-display WAIT:0

ってすると、接続があった時に初めてx11vncを起動するように待つ。待っている間は

メモリもCPUも消費しないでいいわけだ。

接続してログインすると、この画面は真っ黒になる。なぜならログインユーザで新しいX11がvt2のdisplay :1で起動するから。

だからこの接続は速やかに終了して、サーバーで以下のコマンドを実行する

$ x11vnc -display WAIT:1

今度はsudoじゃなくていい。ゆーざ権限でXが起動しているから。

無事接続したX11デスクトップでは

$ glxinfo 抜粋
name of display: :1
display: :1 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2) (0x1916)
Version: 11.2.0
Accelerated: yes
Video memory: 3072MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 3.3
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1

のようにネイティブなドライバが使われているので、GPUがちゃんと使える。

ここまでで気に入らないのは、ログインがdisplay:0でユーザデスクトップがdisplay:1で、いちいち切り替えなければならないことだ。多分gdm側に共有するような設定があるのではないか？と思うが、もっと楽にやりたい。

gdm3でautologinにしてしまう

/etc/gdm3/custom.confの以下２行のコメントを外して、trueとユーザ名を入れる。

AutomaticLoginEnable = true
AutomaticLogin = ユーザ名

次回gdm3が起動する際にはこのユーザでログインした状態になっているので、

$ x11vnc -display WAIT:0

でユーザデスクトップに接続することになる。

こうすると大分簡略化されるがセキュリティ的には甘々になるので別の方法でセキュリティを確保する必要があるだろう。例えばsshトンネルとか。

$ x11vnc -localhost -display WAIT:0

これでlocalhostからのみ接続許可しかことになるので、リモート側からはsshトンネルで接続して、そのポートへVNC接続する。リモート側では

$ ssh user@hostname -L 5900:localhost:5900

-L以降をつけるとsshトンネルできる。これで接続後にlocalhost:5900へVNCする。

ここまでは物理ディスプレイのデスクトップをVNCする流れ。最大の利点は物理ディスプレイのミラーなのでネイティブなドライバが機能する点。欠点は

・リフレッシュレートが接続しているディスプレイに依存してしまうこと

・実際にディスプレイを接続しておく必要があること（EDIDを解決すれば別）

・解像度がディスプレイに依存すること

などなどなかなか難儀だ・・

ネイティブドライバを諦めさえすれば、かなりの自由が手に入る。

x11vnc + xvfb

xvfbはXorgの標準仮想フレームバッファドライバ。これを使って起動する場合

$ x11vnc -env FD_GEOM=1280x800 -env FD_PROG=gnome-session -create

って感じにする。仮想ディスプレイ解像度の指定はFD_GEOMで。デスクトップはFD_PROGで指定する。-createで新しい別のXorgを起動する。その時使われるデフォルトのドライバがxvfbになる。-createの代わりに-xvfbって指定してもいい。-display WAIT:cmd=FINDCREATEDISPLAY-Xvfbって指定したのと同じ効果がある。

ビデオドライバがXvfbで仮想化されるので自由度は高いが、GPUは使えない。3D描画はソフトウエアエミュレーションになる。

ネイティブドライバでは、GLES3.1が使えるが仮想ドライバはGLESは使用できなかったり、ES3.0までだったりデメリットがある。core profileは同じ3.3でGL Extensionも結構使えるのでGLとしてはさほど不自由はない。

x11vnc + Xdummy？

XDummyは結局 xfree86-video-dummyを使うためのスクリプト＋プログラムなようなので

以下の手順で起動するのと同じこと。

#!/bin/bash

Xorg -noreset +extension GLX +extension RANDR +extension RENDER ¥

-logfile ~/.log/xdummy.log -config ~/.config/xdummy.conf :10 &

DISPLAY=:10 gnome-session &

x11vnc -display :10

色々試したが、上の感じのスクリプトで起動するのが良さそう。で肝心なのがここで使用している xdummy.conf だ。これはどこから持ってきたかというと、xpra.org/xorg.conf から。

編集箇所は、videoram容量とvirtual解像度だけ。

Xdummy経由で起動

$ Xdummy -prconf > xorg.conf

でconfファイルを出力させる。これを適当に編集して、先ほどのXorgの行を

sudo Xdummy -conf xorg.conf &

に書き換える。sudoしないとなぜかコアダンプしてしまう。何か間違っているのかも。

Xdummyの優位性は自分的には感じ取ることができなかった。標準のXvfbでいいかな。

VirtualGL

これは簡単な話で、XvfbとかXdummy(video-dummy driver)経由でXを使用するとドライバが仮想なためどうしてもGPUへのアクセスができない。これを解決するもの。

１つネイティブなXを起動しておいて、次に上記の要領で、XvfbかXdummyのXから

$ vglrun glxgears

とかやるとGLコマンドがvglrun経由でネイティブドライバで実行され、その結果を仮想側で見ることができる。

$ vglrun -d :0 -- glxheads

Display: 0x9a0c90
Window: 0x1a00002
Context: 0x9c1470
GL_VERSION: 3.0 Mesa 11.2.0
GL_VENDOR: Intel Open Source Technology Center
GL_RENDERER: Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2)とネイティブドライバ側で動いていことが分かる。これは一瞬オォって思う。

しかし残念なことに、VirtualGLが解釈できるGLコマンドしかだめだ。

そのためか、GLESドライバとしては機能しない。

以上色々試したが、x11vncでネイティブミラーする以外は仕事では微妙に使えないなというのが結論。x11vncでディスプレイミラーの欠点は、ディスプレイ依存の問題が一番。

これを解決する方が一番自分の希望に近いようだ。EDIDエミュレータを自作するのがいいかな。