けさらんぱの自由帳

とあるFF14プレイヤーがFF14のこととか関係ないことを書いていく予定のブログです。記載されている会社名・製品名・システム名などは、各社の商標、または登録商標です。

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

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

ファムフリート

f:id:KesaranPa:20180701112715j:plain

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

ベリアス戦

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

f:id:KesaranPa:20180701112848j:plain

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

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

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

労働七号戦

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

f:id:KesaranPa:20180701113745j:plain

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

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

かわいい…よね…!? f:id:KesaranPa:20180701113820j:plain

ヤズマット戦

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

f:id:KesaranPa:20180701113859j:plain

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

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


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

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

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

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

ベンチマーク結果

まずは結果から。ベアメタル環境。 f:id:KesaranPa:20180502005244p:plain

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

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

テスト環境

ハードウェアは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/LinuxWindows 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 LinuxDebian GNU/Linuxの間、Arch LinuxWindows 10 Proの間の通信ができませんが、Debian GNU/LinuxWindows 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

記載されている会社名・製品名・システム名などは、各社の商標、または登録商標です。