2017/01/30

iGVT-g(XenGT/KVMGT) 構築 パート1

Intel® Graphics Virtualization Technology (Intel® GVT)

これを簡単に言うと、Xen/KVMのゲストで1つの物理GPUをシェアする技術のこと。
普通のゲスト端末では通常FBやグラフィックスドライバは仮想なので物理GPUは利用できない。パススルーすれば1つのゲストのみ使用できる。
このiGVT-gは、その中間的な位置づけで、複数のゲストで物理GPUを共有できる。

自分がやりたかったことに近いと思い、今回頑張って動かしてみることにした。
以下、色々やってみたときの流れをまとめたもの。

これを使うためには普通のXen/KVMではだめで、専用のカーネルとQEmuが必要。それらを簡単にインストールすることが出来るISOファイルが提供されている。

ISOファイル
のDownload LinkからISOファイルをダウンロード
この記事を書いている時には、これが一番最新だった。

KVMGT ENVIRONMENT SETUP GUIDE BY USING GVT-G INSTALLATION ISO にWindowsでUSBFlashMemoryに焼く方法が書いてある。

LinuxのCUIで焼くには
# umount /dev/sdX
# dd if=/path/to/ubuntu.iso of=/dev/sdX bs=4M && sync
な感じで。

このISOは、インストールせずにXenGT/KVMGTを体験できるようになっている。そっちを選ぶと、Launch Guestアイコンが
デスクトップに置かれていて、クリックするだけで物理GPUイネーブルなguestVMが1つ起動できる。しかしここでは、体験ではなくInstallしてVGTイネーブルなゲストを自分で作るところまでやってみる。

ルート権限での操作ばかりなので
$ sudo su -
してから色々やる。

Install
USB Flashで起動してInstallを選んで進める。後で面倒になるのでLVMを選ぶ。
再起動。ほっておくとKVTGTが起動する。

とりあえず
# apt update
# apt install emacs
# apt upgrade -y

ネットワーク
# apt install bridge_utils すでに入っているが一応。
# emacs /etc/network/interface
auto xenbr0 enp0s31f6
iface enp0s31f6 inet manual
iface xenbr0 inet dhcp
bridge_ports enp0s31f6

付属品 全部コピー
# cp /media/ubuntu/Intel ¥GVT-g/guest.qcow2 .
# cp /usr/share/script/* .
# cp XenGT_boot.hvm guest.hvm
# emacs guest.hvm
--- XenGT_boot.hvm 2017-01-14 01:37:42.690241567 +0900
+++ guest.hvm 2017-01-14 01:40:02.713018599 +0900
@@ -1,11 +1,11 @@
-kernel="hvmloader"
+#kernel="hvmloader"
 builder='hvm'

 vcpu = 2

 memory = 1024
 name = "Guest"
-#vif = [ 'type=ioemu,mac=00:23:F7:34:69:9D,bridge=xenbr0,model=e1000' ]
+vif = [ 'type=ioemu,mac=00:23:F7:34:69:9D,bridge=xenbr0,model=e1000' ]
 disk=[ '/root/guest.qcow2, qcow2,hda,rw' ]
 device_model_version='qemu-xen'
 device_model_override='/usr/lib/xen/bin/qemu-system-i386'

KVMGTはひとまず置いておいて、ここではXenGTを使うことを前提に進める

XenGT Grub setup
# emacs /etc/grub.d/20_linux_xen
--- 20_linux_xen~ 2017-08-26 03:31:40.000000000 +0900
+++ 20_linux_xen 2017-01-14 10:10:50.086070770 +0900
@@ -132,7 +132,7 @@ linux_entry ()
  fi
  multiboot ${rel_xen_dirname}/${xen_basename} placeholder ${xen_args} \${xen_rm_opts}
  echo '$(echo "$lmessage" | grub_quote)'
- module ${rel_dirname}/${basename} placeholder root=${linux_root_device_thisversion} ro ${args} i915.hvm_boot_foreground=1 i915.vgt=1
+ module ${rel_dirname}/${basename} placeholder root=${linux_root_device_thisversion} ro ${args}
 EOF
  if test -n "${initrd}" ; then
  # TRANSLATORS: ramdisk isn't identifier. Should be translated.

# emacs /etc/default/grub
GRUB_DEFAULT="Advanced options for XenGT>0>XenGT, with Linux 4.3.0-rc6-vgt+"
GRUB_CMDLINE_XEN="dom0_mem=2048M loglvl=all guest_loglvl=all conring_size=4M noreboot"
GRUB_CMDLINE_LINUX="rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 rhgb crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM ignore_loglevel console=tty0 console=hvc0 consoleblank=0 log_buf_len=4M i915.hvm_boot_foreground=1 i915.enable_cmd_parser=0"
apt upgradeで Grubメニュートップが Genericカーネルになってしまったので、GRUB_DEFAULTが複雑なことに。。
参考ページGrub2/Submenus

# update-grub
# reboot

その後はリモート操作で(自分はそうしたけど、直接デスクトップ操作でもかまわない。というかそのほうが普通)
# apt install x11vnc
# emacs .x11vncrc
#usepw # 最初はpw設定になるので、'o'オプションはコメントした方が良い
o x11vnc.log
nonc
shared
noxrecord
noxdamage
noxfixes
norc
xkb
repeat
scr_keyrepeat 4-10
x11vnc起動
# x11vnc -auth guess -display :0
リモートからVNCでつなぐ。TurboVNCがお勧め。

付属guest boot up
# xl cr guest.hvm
user: intel
pw: 123456

qemu console window内にマウスカーソルを入れておく。
ディスプレイがguestデスクトップに自動で切り替わる。demoを動かす程度は楽しめる。
どういうわけかnetworkがダメだ。
# xl destroy Guest

Guest作成
お気に入りの download Xenial netbook isoを使う。
# qemu-img-xen create -f qcow2 install.qcow2 30G
# cp guest.hvm install.hvm
# emacs install.hvm
--- guest.hvm 2017-01-14 01:40:02.713018599 +0900
+++ install.hvm 2017-01-14 11:19:03.538116270 +0900
@@ -3,10 +3,10 @@ builder='hvm'

 vcpu = 2

-memory = 1024
-name = "Guest"
-vif = [ 'type=ioemu,mac=00:23:F7:34:69:9D,bridge=xenbr0,model=e1000' ]
-disk=[ '/root/guest.qcow2, qcow2,hda,rw' ]
+memory = 2048
+name = "install"
+vif = [ 'type=ioemu,bridge=xenbr0,model=e1000' ]
+disk=[ '/root/install.qcow2, qcow2,hda,rw','file:/root/mini.iso,hdc,cdrom,r' ]
 device_model_version='qemu-xen'
 device_model_override='/usr/lib/xen/bin/qemu-system-i386'
 boot="dc"
ゲスト起動
# xl cr install.hvm
いつものCUIベースのインストーラ。Desktopが各種選べる。今回は'gnome desktop + OppenSSH'で。

リブードするけど一度落とす。
# xl destroy install

GuestへvGTカーネル インストール
一応、セットアップガイドに記述されている方法を書いておく。
パート2ではもっと簡単な方法で入れる方法を考えよう。

## Mount
modprobe nbd
qemu-nbd -c /dev/nbd0 $1
kpartx -av /dev/nbd0
mount /dev/mapper/nbd0p1 /mnt

## Install
cp /boot/initrd.img-4.3.0-rc6-vgt+ /mnt/boot
cp /boot/vmlinuz-4.3.0-rc6-vgt+ /mnt/boot
cp -r /lib/modules/4.3.0-rc6-vgt+ /mnt/lib/modules
cp /etc/udev/rules.d/vgt.rules /mnt/etc/udev/rules.d

## grub.cfg編集
# chmod 644 /mnt/boot/grub/grub.cfg
# emacs /mnt/boot/grub/grub.cfg
diff -up /mnt/boot/grub/grub.cfg~ /mnt/boot/grub/grub.cfg
--- /mnt/boot/grub/grub.cfg~ 2017-01-17 22:39:41.132555000 +0900
+++ /mnt/boot/grub/grub.cfg 2017-01-17 22:48:53.006084554 +0900
@@ -140,8 +140,8 @@ menuentry 'Ubuntu' --class ubuntu --clas
  else
  search --no-floppy --fs-uuid --set=root c6047092-6039-4614-a5b2-b708a39d7636
  fi
- linux /boot/vmlinuz-4.4.0-59-generic root=UUID=c6047092-6039-4614-a5b2-b708a39d7636 ro splash quiet $vt_handoff
- initrd /boot/initrd.img-4.4.0-59-generic
+ linux /boot/vmlinuz-4.3.0-rc6-vgt+ root=UUID=c6047092-6039-4614-a5b2-b708a39d7636 ro splash quiet $vt_handoff
+ initrd /boot/initrd.img-4.3.0-rc6-vgt+
 }
 submenu 'Advanced options for Ubuntu' $menuentry_id_option 'gnulinux-advanced-c6047092-6039-4614-a5b2-b708a39d7636' {
  menuentry 'Ubuntu, with Linux 4.4.0-59-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.4.0-59-generic-advanced-c6047092-6039-4614-a5b2-b708a39d7636' {
Guestのブートカーネルをvgt+に直接変更する。後で色々ブート設定整えるにしても、まずはこのカーネルじゃないと動かないので。

## Unmount
umount /mnt
kpartx -d /dev/nbd0
qemu-nbd -d /dev/nbd0
rmmod nbd

起動用hvm
# rm install..qcow2 gnome.qcow2
# cp install.hvm gnome.hvm
# emacs gnome.hvm
--- install.hvm 2017-01-14 11:19:03.538116270 +0900
+++ gnome.hvm 2017-01-14 11:34:47.606061409 +0900
@@ -4,9 +4,10 @@ builder='hvm'
 vcpu = 2

 memory = 2048
-name = "install"
-vif = [ 'type=ioemu,bridge=xenbr0,model=e1000' ]
-disk=[ '/root/install.qcow2, qcow2,hda,rw','file:/root/mini.iso,hdc,cdrom,r' ]
+name = "gnome"
+#vif = [ 'type=ioemu,bridge=xenbr0,model=e1000' ]
+vif = [ '' ]
+disk=[ '/root/gnome.qcow2, qcow2,hda,rw' ]
 device_model_version='qemu-xen'
 device_model_override='/usr/lib/xen/bin/qemu-system-i386'
 boot="dc"
@@ -23,4 +24,4 @@ vgt=1
 vgt_low_gm_sz=128
 vgt_high_gm_sz=384
 vgt_fence_sz=4
-soundhw="ac97"
+#soundhw="ac97"

ゲスト起動(vgtイネーブル)
# xl cr gnome.hvm

無事に起動しただろうか。デフォルト設定だとディスプレイがゲストに切り替わる。
x11vncを使って隣の端末からリモートで操作していると、様子がわかる。
マウスが動かないとかは、ホスト側でのqemuウインドウないにマウスカーソルが入ってないから。

起動したらゲストにログインして、まずはgrub設定だけやり直す。
# emacs /etc/default/grub
GRUB_DEFAULT='1>Ubuntu, with Linux 4.3.0-rc6-vgt+'
#GRUB_HIDDEN_TIMEOUT=0
#GRUB_HIDDEN_TIMEOUT_QUIET=true
# update-grub
これで、apt upgrade でいつの間にか新しいカーネルインストールされても大丈夫。

2個目のゲスト起動したら以下のようなエラーで起動できず・・・
libxl: error: libxl_dm.c:1914:device_model_spawn_outcome: domain 5 device model: spawn failed (rc=-3)
libxl: error: libxl_create.c:1345:domcreate_devmodel_started: device model did not start: -3
libxl: error: libxl_dm.c:2024:kill_device_model: Device Model already exited
libxl: error: libxl.c:1615:libxl__destroy_domid: non-existant domain 5
libxl: error: libxl.c:1573:domain_destroy_callback: unable to destroy guest with domid 5
libxl: error: libxl.c:1476:domain_destroy_cb: destruction of domain 5 failed
この辺は自分のマシンスペックの問題だった。次回(パート2)へ持ち越し。


次回は、ISOからのインストールではなく、カーネル、Qemuビルドするところからちゃんとやってみる。

2017/01/08

NVMe SSDにUbuntu-Xen-vnc構築までの小ネタ

M.2 Intel SSD6 512GB PCIe gen3.0 x4 (NVMe) がやっと届いたので、デュアルブートで今までとは違う環境を入れてみる。

NVMeを意識して買ったわけじゃないので最初BIOSでストレージデバイスとして認識してないじゃん?とちょっと焦った。nvmeはBIOS的にもまた別のデバイスなのね。

Ubuntu16.04LTSのインストーラでインストールディスクを手動で選ぶことでnvmeデバイスにインストールできた。その後はBIOSでもブートデバイスとして選べるようになった。
2度目以降のインストールでは(もう何度もやってる・・)パーティションが作られているためえ普通にインストールメニューに出てくる。

kvmじゃなくて今回はXenをベースに組み立ててみる。VMストレージはイメージファルじゃなくて LVM で組んでいくことにする。そのため、最初のUbuntuインストールでは
ガイド付きLVMを構成する方を選ぶ。
そして大事なのが、dom0に相当するubuntu-rootには全部使うのではなく、32GB程度の小さめにして、残りをゲストマシンに空けておく。

空けるといってもLVM的な空容量であって物理的にはパーティショニングされている。
ディスク全体が1つのvgになっているので、あとはlvで消費していくだけ。

無事Ubuntuのインストールが終わったら、早速 ssh したところ以前のfootprintと異なっているため .ssh/known_hosts でワーニングが出る。エラーじゃなくワーニングなのはIPアドレスが同じでもホスト名が異なるため別物となるから。IPアドレスだと同じになってしまうので、/etc/hostsにホスト名を登録してホスト名アクセスすれば、ブートOSを変更するたびにイラっとしないで済む。

ワーニングを黙らせるには、.ssh/known_hostsに従来の方にはホスト名,IPアドレスとなって新しい方はIPアドレス記述がない。新しいホスト名,IPアドレス にしてやると次回からスムースに ssh できる。

xen環境は未経験なのと、その後試したいことがあるのでXenを構築する。
Xenインストール
$ sudo apt-get install xen-hypervisor-amd64
$ sudo reboot

Network設定
$ sudo apt-get install bridge-utils(多分すでに入っているはず)

/etc/network/interfacesの編集内容(物理Ethernetデバイス名が'eth0'だと仮定)
auto lo eth0 xenbr0
iface lo net loopback
iface xenbr0 net dhcp
bridge_ports eth0
iface eth0 inet manual
Network再起動
$ sudo ifdown eth0 && sudo ifup xenbr0 && sudo ifup eth0

以下のことをやっておくとパフォーマンスやセキュリティ的にいいらしい
$ sudo vi /etc/sysctl.conf
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
設定
$ sudo sysctl -p /etc/sysctl.conf

VM作成
virt-builder: VMディスクイメージ作成ツール
xen-tools: PVゲスト作成ツール
virt-manager: libvirt使ってVMを作成管理するGUIツール(kvm/xenどちらでも)

など、いろいろあるけど、xen-toolsで作る
$ sudo apt install xen-tools

PV domU作成
PV:準仮想化という意味。
HVMというアプローチがあるが完全仮想化でWindowsを入れる場合とかに使う。
KVMと大して変わらないことになるので、ここはあえてPVで。

ホストOS(Dom0)インストール時に構築されているLVM上に論理ボリューム作成

ボリュームグループ確認。空容量とか確認。
$ sudo vgs

論理ボリューム作成
$ sudo lvcreate -L 10G -n gest-name /dev/<vgname>

論理ボリューム確認
$ sudo lvs

Netbootインストーライメージのダウンロード
https://launchpad.net/ubuntu/+archivemirrors から適当なダウンロードサイトを選ぶ

Ubuntu-16.04LTSの場合 (Guestname: xenial)
$ sudo mkdir -p /var/lib/xen/images/netboot/xenial
$ cd /var/lib/xen/images/netboot/xenial
$ wget http://<mirror>/ubuntu/dists/xenial/main/installer-amd64/current/images/netboot/xen/vmlinuz
$ wget http://<mirror>/ubuntu/dists/xenial/main/installer-amd64/current/images/netboot/xen/initrd.gz

ゲストOS設定ファイル
$ cd /etc/xen
$ cp xlexample.pvlinux xenial.cfg
$ vi xenial.cfg

# Guest name
name = "xenial"

# Kernel image to boot
kernel = "/var/lib/xen/images/netboot/xenial/vmlinuz"

# Ramdisk (optional)
ramdisk = "/var/lib/xen/images/netboot/xenial/initrd.gz"

#bootloader = "/usr/lib/xen-4.6/bin/pygrub"

# Kernel command line options
extra = 'root=/dev/xvda1 xen-fbfront.video=16,1024,768'

# Initial memory allocation (MB)
memory = 2048
# Number of VCPUS
vcpus = 2

# Network devices
vif = [ '' ]

# Disk Devices
disk = [ '/dev/xenbox-vg/xenial,raw,xvda,rw' ]

# vfb
#vfb = [ 'type=vnc,vncdisplay=1,vncpasswd=pass-word' ]
vfb = [ 'type=vnc' ]
stdvga=1
videoram=16

VM起動
$ sudo xl create -c /etc/xen/ubud1.cfg
いつもの感じでUbuntuインストール

完了したら設定ファイルをpygrubブートローダに切り替え
$ vi /etc/xen/xenial.cfg

#kernel = "/var/lib/xen/images/ubuntu-netboot/trusty14LTS/vmlinuz"
#ramdisk = "/var/lib/xen/images/ubuntu-netboot/trusty14LTS/initrd.gz"
bootloader = "/usr/lib/xen-4.4/bin/pygrub"
特にgrubmenuとか必要なければ直接
kernel = "/vmlinuz"
ramdisk = "/initrd.img"

でもいいと思う。

VM再起動
$ sudo xl shutdown xenial
$ sudo xl create -c /etc/xen/xenial.cfg

VMコンソールに入る
$ sudo xl console xenial

コンソールから抜ける
Ctrl+]

ここまでは https://help.ubuntu.com/community/Xen に書いてある通り。

vfb設定だけ付け足した。vfbでvnc使う設定に。
xen-fbfront.video=16,1024,768 は、1024x768 16MBという意味。

クライアント側でssh-vncトンネル接続
$ ssh -l ubuntu -L 5901:localhost:5901 xenbox

turbovnc, tightvnc or chicken などで接続
$ vncviewer localhost:5901

接続できたものの、マウスカーソルの位置がズレズレ・・
ネットで調べたらなんと、xen-vncはデフォルトの800x600になっていて、今回のように
1024x768にディスプレイを拡張するとキャリブレーションがズレてしまうのだ。
素直に800x600で使うか、もしくは以下の方法でキャリブレーションする。

VMへひとまずVNCでログインして、
$ xinput
で仮想マウスデバイス名を確認。自分の場合デフォルトの"Xen Virtual Pointer"

$ xinput list-props "Xen Virtual Pointer"
で、属性を確認。
Evdev Axis Calibration が設定されていない。なのでデフォの800x600になってしまう。

$ xinput set-prop "Xen Virtual Pointer" 'Evdev Axis Calibration' 0 1024 0 768
これでディスプレイにマッチするようキャリブレーションされる。

ログアウトするとまた元に戻ってしまうが、とりあえずこんなとこかな。

2017/01/03

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の以下2行のコメントを外して、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へのアクセスができない。これを解決するもの。

1つネイティブな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エミュレータを自作するのがいいかな。