【FF14】【ID愛でる会Aegis】リドルアナ観光

愛でる会恒例の24人レイドの観光、今回はリドルアナに行ってきました。今回は、クリアまで行くことを目的として、最後のボス手前まではストップせずに攻略していきました。

ファムフリート戦

最初のボスにして、最難関（だと勝手に思っている）ボス。案の定、この戦闘だけで5、6回床ペロしてしまいました。特に水瓶くるくるからのざばーっていう攻撃がどうも苦手です。そんなわけで戦闘に必死であまり観察できず。

ベリアス戦

ベリアス戦の前の道中に出てくる変な顔の雑魚。今まであまり気にしていなかったのですが、結構サイズが大きく、もしこの口が開いたらララフェルを丸呑みできそうな大きさです。それにしても変な顔…

そしてベリアス戦。今回初めて気がついたのですが、ベリアスさんは詠唱中に手をくるくる回しています。こういった細かい部分のモーション、通常の攻略では見ている余裕はないのですがきちんと作りこまれています。

ベリアスさんのお手々くるくる。 #ID愛でる会Aegis pic.twitter.com/H1zCkzd4Uc

— けさらんぱ@Aegis (@KesaranPa) 2018年6月30日

ベリアスさんを倒したあと、フィールドの少し奥には、謎の装置と下から上に流れる水柱があります。最初、この装置は灯台の光源を発生させる装置なのかと思ったのですが、違うような気もします。何なのかわかりませんが、上部から光が出ています。

水柱の方は、なんで下から上に流れているんだろうという話題になり、ヤズマットさんが吸い上げてる説が浮上。喉が乾いてるのかな（普通に考えるとクリスタルが吸い上げてる）。

労働七号戦

ベリアスさんを倒すとエリアチェンジして灯台よりさらに上の部分に飛んでいきます。1ヤルムはおおよそ0.9メートルらしいので、モーグリの言葉が正しければ相当高い場所になります。

労働さんとの戦闘。途中の算数問題、みんななんだかんだと言ってても、うちのPTは全員満点でした。

労働さんを倒したところで記念撮影。最近実装されたプリンセスアタイアを着ている人が数人いました。かわいいよね。

かわいい…よね…！？

ヤズマット戦

ここのエリアは、空を見上げると、青空なのに星が出ています。時間的には昼で固定のようなので、高度が高いせいでしょうか。

ヤズマットさん、途中で心核を破壊しますが、きちんと見た目も心核が壊れています。

今回、たけおさんが労働七号が踊り出すタイミングを見たいということでヤズマット戦に参加せずに労働さんに張り付いていたのですが、結果としてはヤズマットさんを倒して画面が暗転したタイミング、ということだったみたいです。

【FF14】リドルアナで労働七号が踊り出すタイミングを確認してみた

全体としては、ヤズマット戦で一度全滅したものの、無事に最後まで倒せて終了！ 今回も非常に楽しかったです。主催してくれたはなおん、すぱさん、本当にありがとうです！

FF14をLinuxの仮想環境で動かす話・GVT-g編

以前、PCIパススルーを使ってGPUをゲストOS側に完全にパススルーしてFF14をLinux上で動かす話をしました。今回は、完全なパススルーではなく、Mediated Passthroughというもので仮想GPUを作成し、それでFF14のベンチマークを動かしてみるお話です。GVT-gというのは、Intelによる仮想GPUの実装をそのように呼ぶみたいです。

ベンチマーク結果

まずは結果から。ベアメタル環境。

GVT-gを使った仮想環境。CPUやメモリを半分しか割り当てていないこともあり、60%ぐらいに落ち込んでいます。

前回の完全パススルーを使ったときは常用を目的にしていたし、実際に常用していますが、今回は元々非力なIntel NUC6i5SYH上で、しかも仮想環境で動かしているので、常用はかなり厳しいです。

テスト環境

• HW: Intel NUC6i5SYH
• OS: Arch Linux
  • linux: 4.16.5-1
  • qemu: 2.12.0-1
  • libvirt: 4.2.0-1

ハードウェアは2世代ほど前のものですが、ソフトウェアはかなり最新で、LinuxカーネルもQEmuもここ数週間にリリースされたものが必要です（この記事を書いている時点で、qemu-2.12.0-1はtestingにしかありません）。

手順

カーネルコマンドラインに以下のオプションを追加します。 i915.enable_gvt=1 はGVT-gを有効にします。 kvm.ignore_msrs=1 は特殊なレジスタへのアクセスを無視します（たまにアクセスするプログラムがあるらしい）。

i915.enable_gvt=1 kvm.ignore_msrs=1 intel_iommu=on

Linuxが起動したら、下記のようにして、Mediated Deviceを作成します。 echo の引数はUUIDです。 uuidgen とかで作成します。 i915-GVTg_V5_1 以外にもいくつかのディレクトリがありますが、vGPUに割り当たるメモリ量なんかが違うみたいです。ディレクトリ名の最後の数字は、作成できるvGPUの数を表しているようです。

% echo XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX | sudo tee /sys/class/mdev_bus/0000:00:02.0/mdev_supported_types/i915-GVTg_V5_1/create

次に、Libvirtの設定を書き換えます。自分が今回書き換えた箇所のうち、重要な部分は下記の部分です。QEmuのカスタム引数を使用しています。また海外サイトによると、OVMFでは問題があるようなので、SeaBIOSを使用しています。 x-igd-opregion=on は内蔵GPUのときに必要になるようです。

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
...
  <os>
    <type arch='x86_64' machine='q35'>hvm</type>
  </os>
...
  <devices>
...
    <graphics type='spice' keymap='en-us'>
      <listen type='none'/>
      <gl enable='yes' rendernode='/dev/dri/by-path/pci-0000:00:02.0-render'/>
    </graphics>
...
    <video>
      <model type='cirrus' vram='16384' heads='1' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x2'/>
    </video>
    <hostdev mode='subsystem' type='mdev' managed='no' model='vfio-pci'>
      <source>
        <address uuid='XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </hostdev>
...
  </devices>
  <qemu:commandline>
    <qemu:arg value='-set'/>
    <qemu:arg value='device.video0.driver=ne2k_pci'/>
    <qemu:arg value='-set'/>
    <qemu:arg value='device.hostdev0.x-igd-opregion=on'/>
  </qemu:commandline>
</domain>

他にゲームパッド等の必要なデバイスの設定も行い、virt-managerから起動します。

仮想環境のネットワーク接続をMACVLANとMACVTAPに切り替えてみた

今自分のメインPCでは、下記のOSが動いています。

OS	環境	用途
Arch Linux	ホスト（物理マシン）	デスクトップ
Debian GNU/Linux	コンテナ（systemd-nspawn）	サーバー
Windows 10 Pro	仮想マシン（libvirt）	ゲーム

今までDebian GNU/LinuxとWindows 10 Proはソフトウェアブリッジ経由でネットワークに接続されていたのですが、これを性能が良いというMACVLAN/MACVTAP経由に切り替えてみることにしました。

systemd-nspawnでMACVLAN接続

設定ファイル中の下記のような記述を、

[Network]
Bridge=nm-bridge

次のように書き換えます。

[Network]
MACVLAN=eth0

libvirtでMACVTAP接続

設定ファイル中の下記のような記述を、

<interface type='bridge'>
  <mac address='xx:xx:xx:xx:xx:xx'/>
  <source bridge='br0'/>
  ...
</interface>

次のように書き換えます。

<interface type='direct'>
  <mac address='xx:xx:xx:xx:xx:xx'/>
  <source dev='eth0' mode='bridge'/>
  ...
</interface>

ホストと仮想環境での通信の設定

MACVLAN/MACVTAPで仮想環境をネットワークに接続する場合、そのままではホストと仮想環境の間の通信ができません。ただし、MACVLAN/MACVTAP同士の通信はできます。例えば今回の場合では、Arch LinuxとDebian GNU/Linuxの間、Arch LinuxとWindows 10 Proの間の通信ができませんが、Debian GNU/LinuxとWindows 10 Proの間の通信は可能です。なので、ホストのArch LinuxもMACVLAN経由でネットワークで接続するようにしてしまえば、ホストと仮想環境の間で通信ができるようになります。

これをsystemd-networkdで実現する場合、下記のようにします。

#
# macvlan.netdev
#
[NetDev]
Name=macvlan0
Kind=macvlan

[MACVLAN]
Mode=bridge

#
# macvlan.network
#
[Match]
Name=macvlan0

[Network]
Address=192.168.x.y/24
...

#
# eth0.network
#
[Match]
MACAddress=xx:xx:xx:xx:xx:xx

[Network]
MACVLAN=macvlan0