ESXi 6.7 +PT2 (PT3/USB) パススルー + Intel QSV をやりたい。
ESXi を使った PT2 仮想化+QSVエンコードにトライ中。
まだ全然完成してないけど、試行錯誤の内容を忘れそうなので、そろそろメモに残しておく。
検証構成(その1)：
- 本体: Fujitsu ESPRIMO D586/P
- CPU: Core i5 6500 (Skylake)
- メモリ: 32GB (DDR4 8GB×4)
- SSD: 480GB (余りモノ)
- 【2022/11/20 追記】安SSDを酷使すると、最後速度低下がエグい事になります。空き容量が十分に確保できるサイズを選びましょう。
- USB-Flash: MLC相当を謳う某microSD+ツライチカードリーダー
- ハイパーバイザ: VMware ESXi 6.7
- (補足)パススルー対象: PT2×2枚、Intel HD Graphics
USB-Flash に ESXi をインストールし、SSD は全領域をVMのストレージとして割り当てる。 【2022/11/20 追記】USB-Flash信用ならんです。SSDにESXiもゲストOSも全部突っ込む方が良いです。
PCIパススルーなので、Intel VT-d とかに対応したCPUが必要。パススルーを受けるゲストOSは、仮想マシンのメモリ割り当てを固定する必要がある。ホストのメモリ量はその点を見越して多めに積んでおくことを推奨。
【2022/11/20 追記】検証環境その2：
- 本体: Fujitsu ESPRIMO Q556/M
- CPU: Core i5 6500T (Skylake)
- メモリ: 12GB (DDR4 8GBx1 + 4GBx1)
- SSD: 480GB (PayPayフリマで3000円で買った)
- HDD: 1TB (QuaStationから抜き取った2.5インチを光学ドライブと挿げ替え‥)
- ハイパーバイザ: VMware ESXi 6.7
- (補足)パススルー対象: Intel HD Graphics 530、Intel xHCI USB 3.0 Host Controller
当初の目論見（構成1）とは別目的で組んだ録画PC。PT2ではなく、USBチューナーを沢山積む方針。
ESXi のカスタマイズISO作成 (7.0対応)
標準イメージは Realtek NIC に対応しない為、カスタマイズISOを作成する。
管理者権限で立ち上げた powershell にて。(ESXi 7.0 を使う場合、v67をv70に書き換える)
PS C:\Windows\system32> Install-Module -Name VMware.PowerCLI
PS C:\Windows\system32> Set-ExecutionPolicy Unrestricted
PS C:\Windows\system32> cd C:\createESXi\
PS C:\createESXi> .\ESXi-Customizer-PS.ps1 -ozip -v67
PS C:\createESXi> .\ESXi-Customizer-PS.ps1 -v67 -izip .\ESXi-6.7.0-20200804001-standard.zip -pkgdir .\vibs\
作業ディレクトリには、 以下のスクリプトを配置（githubが最新版）
追加したいドライバは「vibs」フォルダの下に配置。入手元はこの辺。
-
(USB-NIC) https://flings.vmware.com/usb-network-native-driver-for-esxi
- (Realtek)
https://vibsdepot.v-front.de/wiki/index.php/Net55-r8168 ※6.7まで
ライセンスは普通に取得してください。インストール手順も普通にどうぞ。
Realtek NIC について
ESXi 6.7 まではRealtek向けのドライバが利用できる が、手元の環境だと自動ネゴシエーションで 1000Mbps でリンクアップしなかったり、動作が怪しい。（1000Mbps に固定しても、知らぬ間に 10Mbps, 100Mbps とかに落ちてる事がある）
USB-NICよりマシかな？って思って6.7選んだけど、ぶっちゃけUSB-NICの方が安定してる疑惑あり。
【2022/11/20 追記】これ蟹の問題じゃなくてケーブルの品質が原因っぽいです。きしめんケーブルとか細ケーブルは避けましょう。
USB-NIC について
手元にあるASIXチップ搭載NICを幾つか試したが、NICとして認識しない率が結構高い‥？（USBパススルー対象になってしまう）
- PLANEX UE-200TXG: NG
- IODATA ETG4-US2: NG
- Logitec: LAN-GTJU3: OK 6.7 のみOK (7.0では認識できず)
＃ ESXi に繋ぎたい時とゲストに繋ぎたい時、どう切り替えればいいんだ‥？
(参考)
https://twitter.com/colinhd8/status/1031468984149766145
PT2 パススルー
Windows で検証した限り、特にハマる要素なし。（PT3 もうまくいくんじゃね？）
冒頭に記載の通り、PCIパススルーを使う際はメモリ割り当てを固定する必要あり。
USBパススルー
結構相性が出た。
ゲストの環境設定で USB ホストを 2.0→3.0 に変えると、認識しなかったデバイスが認識する場合があった。（例えば USB 3.0 対応フラッシュとか。多分逆もありそう）
カードリーダーは、どう頑張っても HITACHI はうまく認識しなかった（再起動すると切れる）。NTT com推奨。
【2021/10/28 追記】
件の日立カードリーダー（M-520U）、デバイスマネージャー上で無効→有効を繰り返すことで、稀にきちんと認識できる場合があることに気付いた。
devcon.exe を使って、スタートアップ時に以下のスクリプトを叩く事でうまく認識できるようになる‥かもしれない。
@echo off
cd %~dp0
: Enable_M520U
echo Enable Smartcard Reader/Writer M-520U
devcon enable "USB\VID_0858&PID_2102&REV_0100"
TIMEOUT /T 5devcon status "USB\VID_0858&PID_2102&REV_0100"|find "problem: 10"
IF NOT ERRORLEVEL 1 (
echo Disable Smartcard Reader/Writer M-520U
devcon disable "USB\VID_0858&PID_2102&REV_0100"
TIMEOUT /T 3
GOTO Enable_M520U
)exit
ハードウェアIDはデバイスマネージャー上で確認して各々置換、devcon.exe の入手方法、スタートアップ スクリプトの指定方法は適当に調べて下さい。
環境によっては、iGPUのパススルーでも「再起動後にうまく認識しない（エラーコード43）」みたいな問題があるようなので、そのスタートアップ処理にも流用できるかもしれません。（シャットダウン時に無効化スクリプトも併せて配備しておく方が安定するかも）
【2021/10/30 更に追記】
PCI-Express to USB3.0 なボードをPCIパススルーすることで問題が生じなくなりました。他にもESXiのUSBパススルーって細かな制約が多そうなので、USBハードウェア常用するなら絶対に刺しておいた方が良さそうです。
【2022/11/20 またまた追記】
オンボードUSBでもホストコントローラごとPCIパススルーできました。上記PT2とは別構成ですが、USBチューナー、カードリーダー両方繋いで安定稼働できています。
そのままPCIパススルーから選ぼうとしても、既定ではグレーアウトしており選択ができないので、以下のパススルー定義に追記をします。
My Virtual School: How to FORCE passthrough the internal USB controller in the mother board
[root@localhost:~] lspci -v
(略)
0000:00:14.0 Serial bus controller USB controller: Intel Corporation 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller
Class 0c03: 8086:a12f
# [Custom] Intel USB 3.0 xHCI Controller
8086 a12f d3d0 default
ざっくりこんな感じ。
iGPU パススルー (Intel HD Graphics)
【2022/11/20 追記】事前の仕込みとして、ESXiがiGPUを掴まないように画面出力を切っておく必要がある。
esxcli system settings kernel set -s vga -v FALSE
ESXi 6.7u2 の初期ビルド辺りまでは何もせずパススルーを有効化できた気がするが、6.7 の最新パッチ適用 or 7.0以降では、この仕込みをしないとiGPUパススルーを有効化できない。（パススルーON→再起動すると無効に戻ってしまう）
ゲストが Windows の場合
物理端子からの映像出力を諦めれば使えなくもない。
Windows インストールの時点ではパススルーさせず、後からパススルーを追加する。
そのままではドライバがコード31などで読み込まれないので、仮装マシンの詳細オプションに「hypervisor.cpuid.v0 = "FALSE"」を追加する。
後は通常通り Intel の提供ドライバをインストールことで、デバイスの認識まで可能。（物理ポートからの映像出力はできないが、この状態でもQSVは動作）
Windows 10以上だとGPUを跨いで映像をミラーできるので、頑張ればVMRCの仮想コンソールとiGPUの両方に同じ映像を出力可能。（＝HD Graphicsを有効にしつつリモート コンソール操作が可能）
【事象：ディスプレイに何も出ない！／デスクトップにアイコンが出ない！】
HD Graphics認識直後、プライマリGPUが物理GPUに切り替わってしまう事がある。リモート コンソールがセカンダリ ディスプレイになってしまうので、何の対処もしていないと詰む。プライマリ画面が見えない(物理端子からは何の信号も出ない)、マウス操作もできない状態で、どうにかしてログインし、どうにかしてプライマリ ディスプレイを切り替える必要がある。
以下のコマンドをスタートアップとかに突っ込んでおくと、スタートアップ時にクローンモードへ切り替えてくれるようになり幸せになれる。併せてユーザーの自動ログインとかも仕込んでおくと良いと思う。
C:\Windows\System32\DisplaySwitch.exe /clone
仕込みはiGPUパススルーを切った状態でやりましょう。
ゲストがUbuntu (18.04/20.04辺り)の場合
結論から言うと使い物にならない。
OSインストールの時点でGPUが繋がっていると操作不能になる為、こちらも後からパススルーを追加する。
フレーバーが Server/Desktop、起動モードが BIOS/EFI の組み合わせで動きが違うように見えるが、大抵画面は出力されないし、SSHすら繋がらず完全にハングアップする事もある。（条件により起動ロゴが出力される事もあるが‥症状が安定しない）
「hypervisor.cpuid.v0 = "FALSE"」の設定有無で動きは変わる様子。（ドライバが何かチェックしてる？）
＃この手の情報を調べてると「mce.enable = "TRUE"」と「vhu.enable = "TRUE"」が並んで出てくる事があるが、どちらもよく調べてないので効果は不明。
ゲストがCentOS (7/8辺り)の場合
やや厳しい。
OSインストール後にiGPUを接続する方法のみ検証中。
デスクトップなしの場合、起動自体は問題なく完了するが、時間差でi915ドライバを読み込むのか？途中でVMRSのリモートコンソールが操作不能になる。（物理ディスプレイに何も出ない‥）
(Linux) 物理端子の認識状況
# ls -l /sys/class/drm/
# grep . /sys/class/drm/card?-*/status
（脱線）シリアル接続を使ったコンソール ログイン
↑の調査で起動の様子を確認する為、仮想環境とのシリアル接続を試してみた。操作される側のゲスト設定は以下参照。
隣にWindows ゲストOSを準備して、それぞれの仮想マシンにシリアル ポートを追加する。
Windows 側から TeraTerm とか開いて立ち上げると、懐かしい感じの起動メッセージが出てきてコンソール操作できる。
（更に脱線）
VMRCでクリップボード転送したい場合、仮想マシンの詳細設定で以下のオプションを設定する。
isolation.tools.copy.disable : FALSE
isolation.tools.paste.disable : FALSE
isolation.tools.setGUIOptions.enable : TRUE
（メモ）ESXi を代替できそうなもの
- oVirt
- Proxmox VE
- kimchi
（さらにメモ）現時点で一番正解に近そうな情報源
7.0なんだよなぁ‥CPUの世代も違うし動くかなぁ‥頑張って上げるか‥
