投稿者: osakanataro

投稿日:

All FlashのNetAppでノード1側にディスクを片寄せする場合のメモ

All FlashのnetApp AFF C250は通常２つあるノードに対して均等にディスクが割り当てられている。

ONTAP公式ドキュメント:ルート/データパーティショニング

例えば15TB SSDを10本つんでいる場合、以下のようになる

各スロットにある15TB SSDは内部で、data1パーテーション(約7TB)、data2パーテーション(約7TB)、rootパーテーション(残り) に分割されるという、ADPv2というフォーマットになっている。

オレンジ色の部分のownerがノード1で、水色の部分のownerがノード2となる。

data1パーテーションとdata2パーテーションのownerをノード1に割り当てなおすと以下のような構成をとることが可能となり、ボリュームを拡大することができる。

owner変更してノード1側に集約しよう、という場合は、ノード2側に作成されているaggregateは壊す必要があるので注意

作業で使うコマンドについて

パーテーション変更を行う際に、owner状態などを確認する必要がある。

その際に使うコマンドには、通常権限(admin)で実行できるものと、diag権限で実行できるものがある。

各パーテーションのownerがどちらのノードなのか確認するコマンド

通常権限コマンド「storage disk show -partition-ownership」

通常コマンド「storage disk show -fields owner,type,root-owner,data1-owner,data2-owner」

diag権限コマンド「storage disk partition show」

パーテーションの割り当てを変更するときに、変更忘れがないか確認する場合は「storage disk partition show -partition *P2」パーテーションを指定してOwnerノードの表示を一括で確認するとよい

パーテーションのownerを変更するコマンド

パーテーションownerを変更するコマンドはdiag権限の「storage disk partition assign」で行う

「storage disk partition assign -partition *P2 -owner ノード1 -force」と実行すると有無も言わさず強制的にすべてのP2パーテーション(data2パーテーション)のownerをノード1に変更することができるが、事故を起こさないように事前に「storage disk partition show -partition *P2」を実行し、すべての”Container Type”が「spare」であることを確認した方がよい

すでにaggregateが作成されている場合

すでに両ノードでaggregateが作成されている場合、ownerをはく奪するノード側のaggregateを削除する必要がある。

なお、システム用のaggregate(標準ではaggr0_ノード名 で作成されている) は削除しないこと。

削除手順は「storage aggregate offline -aggregate aggr名」でオフラインにした後

「storage aggregate delete -aggregate aggr名」で削除する。

ADPv2のパーテーション配分について

15TB SSDが8本の場合、各ノードのrootパーテーション部分は4パーテーションを使用したRAID-DPとなりスペアはない状態となる。

各ノードが使うシステム用aggregateは140GB程度は確保されるのだが、ディスクの本数が少ない場合、rootパーテーションに割り当てられる容量が通常より増やされれていた。

data1data2rootrootのスペア
8本6.94TB6.94TB93.52GBなし
10本6.94TB6.94TB93.52GB1
12本6.96TB6.96TB62.35GB1
14本6.96TB6.96TB62.35GB1
16本～22本6.97TB6.97TB37.42GB1
24本6.97TB6.97TB37.42GB2

投稿日:

TRIGKEY MINI PC Key N (N95搭載)を買った

AmazonでTRIGKEYのミニPCが１万円を切ってる、というので買ってみた

15899円になぜか6000円引きのクーポンがついてきて、１万円を切ってるというもの

速やかに到着・・・

なぜか箱をくるんでいるビニールに対して技適 210-173540 というシールが貼れているという・・・

箱の中身はこんな感じ

電源ユニット内蔵なので、謎のType-C形状電源とか不要でコンパクトに使える、というのがとても良いですね

ついでに中身確認

うーん・・・M.2 SATA SSD 256GBが黒いです。

フラッシュチップの記載が何も読めません

メモリにもかかれている「LKY」というのがメーカか何かなんですかね？

起動してみましょう

F2キーでUEFIに入れました。

プレインストールのWindows 11 Proのセットアップを進めていって「slmgr /dli」を実行してWindowsのライセンス認識を確認してみます・・・

ライセンスは以下のようにVOLUME_MAKでした

なので、Amazon経由で正式なライセンスをくれ、とメッセージを送ったところ4営業日でライセンスが発行され、適用したところ OEM_DM として認識されることを確認しました。

で・・・実は、なかなかライセンスが来なかったので、ライセンスが届く前にWindowsの再インストールを行ってみたところ予想外の事態が・・・

インストール時にライセンスは自動認識されないので、Windows 11 Proを手動で選択してインストールを終わらせてみたところ、すでにRETAILで認識されていたという・・・

うーん・・・どういう状態なんですかねぇ・・・これ

とりあえずはWindows 11 Pro ライセンスがついてきて１万円を切っていた、というのは変わらないですね。

謎の真っ黒M.2 SATA SSDを確認

メーカー名なしで「NGFF 2280 256GB SSD」と認識のもの、というのは驚きです。

(NGFF 2280 は 物理的な形状のことを指している単語です)

タスクマネージャー上の認識を確認。ちゃんとIntel N95で認識されている、と

メモリはSO-DIMM DDR4 3200の8GBでした。なお、後述しますが32GBメモリが動作することも確認しました。

ディスクはメーカ、モデル名不詳のNGFF 2280 256GB SSD…まあ、256GBなので捨てちゃいましょう

プレインストールのWindows 11 Proのドライバ認識を確認・・・もちろん未認識はなし。

プレインストールソフトについて

標準でインストールされているプログラムをスタートメニューで確認すると、Intel関連がいくつか登録されていた。

次にインストールされているアプリ一覧を確認

このうち「Intel Driver and Support Assistant」がドライバの更新があると教えてくれたので、実行してみるとブラウザが開いた

開いたURLはこれ : インテル® ドライバー & サポート・アシスタント

アップデートの詳細説明は下記のURL3つ

Windows® 10 および Windows* 11 用インテル® ワイヤレス Wi-Fi ドライバー

Windows® 10 および Windows* 11 用インテル® ワイヤレス・Bluetooth®・ドライバー

Intel® Arc™ & Iris® Xe Graphics – Windows*

Window 11 再インストール実施

SSDを別のものに交換してWindows 11 Pro を再インストールしてみたところ、標準では一部デバイスが認識していない。

まずは認識していないものを確認しつつドライバを適用

PCI シンプル通信コントローラーPCI\VEN_8086&DEV_54A8&SUBSYS_72708086&REV_00\3&11583659&0&F0

Microsoft Update カタログからドライバ適用

PCI デバイス
PCI\VEN_8086&DEV_54E8&SUBSYS_72708086&REV_00\3&11583659&0&A8

Microsoft Update カタログ からドライバ適用

PCI デバイス
PCI\VEN_8086&DEV_54E9&SUBSYS_72708086&REV_00\3&11583659&0&A9

Microsoft Update カタログのドライバ適用

PCI デバイス
PCI\VEN_8086&DEV_54AB&SUBSYS_72708086&REV_00\3&11583659&0&F3

Microsoft Update カタログ

ここからのACPIの不明なデバイス３つを解消するにはMicrosoft Update Catalogで探す前にIntelページからドライバを入手する必要があった。

不明なデバイス
ACPI\INTC1023\2&DABA3FF&0

不明なデバイス
ACPI\INTC1057\2&DABA3FF&0

不明なデバイス
ACPI\INTC1024\2&DABA3FF&0

まずは、下記からINFをインストールすると、不明なデバイスが2つ消える。

ユーザーサポート インテル® Chipset Software Installation Utility

残ったものについてはMicrosoft Update Catalogで捜索する

Microsoft Update カタログ

これでデバイスがすべて認識した。

再インストール後にアプリ一覧を比較すると、プレインストールに存在していたが、再インストール後にないもので、システムの動作に影響がありそうなものをあげると以下のものになる。

Intel(R) Arc Software & Drivers

Intel(R) Computing Improvement Program

Intel Arc Control

Intel Driver & Support Assistant

Intel Unison (なお、Unisonの提供は 2025/06で終了済)

Realtek High Definition Audio Driver

インテル グラフィクス・コマンド・センター

インテル シリアル IO

インテル マネージメント・エンジン・コンポーネント

逆に再インストールで追加されているものは以下の2つ。まあ、copilotなので無視。

Copilot

Microsoft 365 Copilot

足らないアプリケーションについて、まずは「インテル® ドライバー & サポート・アシスタント」をインストールして、実行

実行するとWifi/Bluetooth/グラフィックスドライバの更新がインストールされた。

リストを確認すると、更新と同時に”Intel(R) Computing Improvement Program” と “oneAPI Level Zero”がインストールされていた。どちらもGPUコンピューティング関連のソフトウェアと思われる。

プレインストールにあった「Intel ARC Control」は古いバージョンで、現在は Intel Graphics Softwareに統合されたみたいなので不要の模様(単体ではダウンロードできない)

インテル® グラフィックス・コマンド・センターはMicrosoft Storeからインストール

Realtek High Definition Audio Driver, インテル シリアル IO, インテル マネージメント・エンジン・コンポーネントについてはドライバが適用されてるのでわざわざ追加する必要はない。

これで、プレインストール状態と同等になり問題はないと思われる。

カスタマイズ

とりあえず標準で載っていたWifi 802.11ac/Bluetooth 5.0のRTL8821CE は見た目が怪しすぎるしそもそも仕様が古いということでIntel AX210NGW に交換し、WiFi-6E / Bluetooth 5.3 に対応させました。

SSDについては余っていた512GBのM.2 NVMe SSDとM.2 SATA SSDを使ってUbuntu Linuxのソフトウェアミラーリング設定を行って試験運転中です。

さらに、32GB SO-DIMMを買って、増設してみました。

今回買ったのはWINTENのSO-DIMM DDR4 3200 32GBです

他のPCにもさしてみるか、ということで2枚セットで購入して増設しました・・・

結果無事32GBを認識しました。

とりあえず現状簡単にできる範囲でのカスタマイズはもうないなぁ、といったところです。

投稿日:

Proxmox VEクラスタをUPSで停止する手法のメモ

Proxmox VE環境でとりあえずUPSでサーバ停止する場合についてのメモ

cephについてはもっと面倒なので今回は考慮しない

面倒な点

・HAを有効にした仮想マシンは停止しても再起動してくる

　→ 仮想マシンをHA対象外にする必要がある

・仮想マシンを一時的にHA対象外にする、という設定はない
　→ 恒久的な設定変更として 仮想マシンを HA対象外にする必要がある
　　＆再起動したあと 仮想マシンを HA対象内にする必要もある

・PVEサーバ上で仮想マシンを動作している状態でメンテナンスモード有効にすると仮想マシンの操作が何もできなくなる
　→ 動いてる仮想マシンをほかのサーバに移動する操作を自動でやってくれない

・HA対象仮想マシンの設定は /etc/pve/ha/resources.cfg にされるが変更するためのコマンド/APIはv8.3時点では用意されていない
　→ テキストファイルを編集する必要がある
　　＆/etc/pve 以下は PVEクラスタ内で共有されているファイルなので編集競合に注意

・起動時にすぐにPVEクラスタのマスターが決まるわけではない
　→ 起動後、マスターが決まるまで待機する？（どうやってマスターが決まったかを判定するか？）

ひとまずな実装方針

停止時の流れとしては以下

1) PVEマスターで現在の /etc/pve/ha/resources.cfg を保存
2) PVEマスターで /etc/pve/ha/resources.cfg を書き換え
3) 稼働している仮想マシン/コンテナを停止
4) PVEサーバをメンテナンスモードに切り替える?
5) シャットダウン実行

起動時の流れとしては以下

1) 起動開始
2) 全PVEサーバで PVEクラスタが稼働するまで処理待機
3) PVEマスターで バックアップしてあった /etc/pve/ha/resources.cfg を戻す
4) PVEサーバをメンテナンスモードから解除?
5) resources.cfgの記述に従って仮想マシン/コンテナが起動?

UPSSの出してるシャットダウンボックス UPSS-SDB04 でproxmox検証結果出てるけど、どんな実装にしてんだろ？

未確認の実装例

とりあえず、まだ未検証の実装サンプル

停止時に実行する処理

停止処理について

HAのリソースに仮想マシンが登録されていないと ha-manager statusの結果は「quorum OK」のみとなる。このスクリプトではha-manager statusの際に「master ホスト名 (ステータス)」という出力がある場合=HA設定されている場合のみ設定ファイルの退避を行っている

HA設定されている場合、resources.cfgのステータスがstoppedに書き換えられると、仮想マシンが停止される

#!/bin/bash
# 仮想マシンの状態を確認する関数
check_vms_status() {
    # 実行中の仮想マシンIDを取得
    running_vms=$(qm list | grep running | awk '{print $1}')
    if [ -z "$running_vms" ]; then
        echo "すべての仮想マシンが停止しています。"
        return 0  # すべて停止している場合
    else
        echo "以下の仮想マシンが実行中です: $running_vms"
        return 1  # 実行中の仮想マシンがある場合
    fi
}

# PVEマスター名を取得
mastername=$(ha-manager status | grep 'master' | awk '{print $2}')

# マスターでのみ実行する処理
if [ W$mastername == W`hostname` ];
then
   # resources.cfg のバックアップ作成
   cp /etc/pve/ha/resources.cfg /etc/pve/ha/resources.cfg.upstmp
   # 書き換えによりHA対象仮想マシンは停止が実行される
   sed -i 's/started/stopped/' /etc/pve/ha/resources.cfg
   # HAに含まれない仮想マシンに対する停止
   for hostname in `pvesh ls /nodes/|awk '{ print $2 }'`
   do
      for vmid in `pvesh ls /nodes/$hostname/qemu/|awk '{ print $2 }'`
      do 
         pvesh create /nodes/$hostname/qemu/$vmid/status/shutdown
      done
   done
else
   # マスタサーバ以外は処理を遅延
   sleep 10
fi

# 仮想マシンが停止しているかを確認する
check_vms_status
status=$?
while [ $status -ne 0 ]
do
   echo "仮想マシンがまだ実行中です。再確認します..."
   sleep 5
   check_vms_status
   status=$?
done

# すべての仮想マシンが停止している場合、メンテナンスモードに移行
echo "Proxmoxサーバをメンテナンスモードにします..."
ha-manager crm-command node-maintenance enable `hostname`

投稿日:

HPE Morpheus VM Essentials / HVM が Ubuntu 24.04 ベースにも対応するも別環境として構築必須

しれっとドキュメントが更新されているので気が付きにくいのですが、Ubuntu 22.04 LTSベースだった HPE Morpheus VM Essentials / HVM が v8.0.5 からUbuntu 24.04 LTS ベースに対応しています。

ただ、クラスターに登録する際のインタフェースを見る限りでは、Ubuntu 22.04ベースはHPE VM 1.1クラスタ、Ubuntu 24.04ベースは HPE VM 1.2クラスタと分割する必要があるようです。（2025年5月末時点でのドキュメントには、そもそもクラスタのバージョンについて書かれていませんが・・・)

現状運用しているUbuntu 22.04ベースのHPE VM 1.1クラスタをUbuntu 24.04ベースのHPE VM 1.2クラスタにアップデートすることについての記述がないので、継続運用性に若干疑問が・・・

投稿日:

HPE VMEssentialsでNVIDIA vGPUは使えるか？

HPE VMEssentials環境でNVIDIA vGPUが使えるか試してみたところ、libvirtを直接操作することで仮想マシンにvGPUの割り当てが行えることを確認した。

ただし、HPE VMEssentialsで管理していると思われる仮想マシンのXML形式の設定ファイルと、virsh dumpxml で取得できるXML形式の設定ファイルの内容は別物になっていて、HPE Web UIで設定変更するとvirshで直接編集した結果は破棄されてしまうので注意が必要

仮想マシンの起動/停止レベルであれば問題ないが、設定変更はダメだった

HPE VMEssentialsのGUIでパススルー設定をして仮想マシンに割り当てるという設定も可能ではあるのだが、パススルー設定できるデバイスでvGPUデバイスが選択できない状態だった。つまりは、NVIDIA vGPUドライバを入れずに仮想マシンから直接GPU全体を割り当てる、といった使い方しかできない。

HPE VMessentials側の設定:下地作り

パススルーする際に必要となるIOMMU関連設定は、hpe-vm v8.0.5.1では設定実施済みとなっていた。

必要なのはLinux標準のnouveauドライバを使用しないようにするための blacklist.conf 設定だった

実施後、nvidia vGPU のうちUbuntu版の nvidia-vgpu-ubuntu-570_570.133.10_amd64.deb をインストールして対応完了

Secure Boot有効の場合はUEFIへのキー埋め込みも行ってくれた。

また、sriov-manager -e ALL を実行して、GPUを分割されるか確認

pcuser@vgpuserver:~$ lspci -d 10de: -nnk
08:00.0 3D controller [0302]: NVIDIA Corporation GA107GL [A2 / A16] [10de:25b6] (rev a1)
        Subsystem: NVIDIA Corporation Device [10de:157e]
        Kernel driver in use: nouveau
        Kernel modules: nvidiafb, nouveau, nvidia_vgpu_vfio, nvidia
root@vgpuserver:~# /usr/lib/nvidia/sriov-manage -e ALL
Enabling VFs on 0000:08:00.0
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 90: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
root@vgpuserver:~# lspci -d 10de:
08:00.0 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:00.4 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:00.5 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:00.6 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:00.7 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:01.0 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:01.1 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:01.2 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:01.3 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:01.4 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:01.5 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:01.6 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:01.7 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:02.0 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:02.1 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:02.2 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:02.3 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
root@vgpuserver:~#

分割されるようであれば、これが起動時に実行されるよう/usr/local/lib/systemd/system/nvidia-sriov.service を作成し、起動する

root@vgpuserver:~# mkdir -p /usr/local/lib/systemd/system
root@vgpuserver:~# vi /usr/local/lib/systemd/system/nvidia-sriov.service
root@vgpuserver:~# cat /usr/local/lib/systemd/system/nvidia-sriov.service
[Unit]
Description=Enable NVIDIA SR-IOV
Before=pve-guests.service nvidia-vgpud.service nvidia-vgpu-mgr.service

[Service]
Type=oneshot
ExecStart=/usr/lib/nvidia/sriov-manage -e ALL

[Install]
WantedBy=multi-user.target
root@vgpuserver:~# systemctl  daemon-reload
root@vgpuserver:~# systemctl status nvidia-sriov.service
○ nvidia-sriov.service - Enable NVIDIA SR-IOV
     Loaded: loaded (/usr/local/lib/systemd/system/nvidia-sriov.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
root@vgpuserver:~# systemctl enable --now nvidia-sriov.service
Created symlink /etc/systemd/system/multi-user.target.wants/nvidia-sriov.service → /usr/local/lib/systemd/system/nvidia-sriov.service.
root@vgpuserver:~# systemctl status nvidia-sriov.service
○ nvidia-sriov.service - Enable NVIDIA SR-IOV
     Loaded: loaded (/usr/local/lib/systemd/system/nvidia-sriov.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Thu 2025-05-22 18:08:35 JST; 1s ago
    Process: 2853 ExecStart=/usr/lib/nvidia/sriov-manage -e ALL (code=exited, status=0/SUCCESS)
   Main PID: 2853 (code=exited, status=0/SUCCESS)
        CPU: 44ms

May 22 18:08:35 vgpuserver systemd[1]: Starting Enable NVIDIA SR-IOV...
May 22 18:08:35 vgpuserver sriov-manage[2857]: GPU at 0000:08:00.0 already has VFs enabled.
May 22 18:08:35 vgpuserver systemd[1]: nvidia-sriov.service: Deactivated successfully.
May 22 18:08:35 vgpuserver systemd[1]: Finished Enable NVIDIA SR-IOV.
root@vgpuserver:~#

再起動してnvidia-smiが動くか確認



pcuser@vgpuserver:~$ nvidia-smi
Tue May 27 15:39:51 2025
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 570.133.10             Driver Version: 570.133.10     CUDA Version: N/A      |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA A2                      On  |   00000000:08:00.0 Off |                  Off |
|  0%   50C    P8              9W /   60W |       0MiB /  16380MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|  No running processes found                                                             |
+-----------------------------------------------------------------------------------------+
pcuser@vgpuserver:~$

HPE VMessentials側の設定:libvirtいじり

v8.0.5時点ではHVM経由ではvGPU割り当てができないので、libvirtを直接いじってvGPUを仮想マシンに割り当てる必要がある

参考になるドキュメントは「Configuring the vGPU Manager for a Linux with KVM Hypervisor」

まず、このデバイスがサポートしている”nvidia-3桁数字”という書式のデバイス種別を確認するため「mdevctl types」を実行。また、同時に「0000:08:00.4」といった形でPCIデバイスのアドレスを確認

root@vgpuserver:~# mdevctl types
0000:08:00.4
  nvidia-742
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-1B
    Description: num_heads=4, frl_config=45, framebuffer=1024M, max_resolution=5120x2880, max_instance=16
  nvidia-743
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-2B
    Description: num_heads=4, frl_config=45, framebuffer=2048M, max_resolution=5120x2880, max_instance=8
  nvidia-744
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-1Q
    Description: num_heads=4, frl_config=60, framebuffer=1024M, max_resolution=5120x2880, max_instance=16
  nvidia-745
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-2Q
    Description: num_heads=4, frl_config=60, framebuffer=2048M, max_resolution=7680x4320, max_instance=8
  nvidia-746
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-4Q
    Description: num_heads=4, frl_config=60, framebuffer=4096M, max_resolution=7680x4320, max_instance=4
  nvidia-747
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-8Q
    Description: num_heads=4, frl_config=60, framebuffer=8192M, max_resolution=7680x4320, max_instance=2
  nvidia-748
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-16Q
    Description: num_heads=4, frl_config=60, framebuffer=16384M, max_resolution=7680x4320, max_instance=1
  nvidia-749
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-1A
    Description: num_heads=1, frl_config=60, framebuffer=1024M, max_resolution=1280x1024, max_instance=16
  nvidia-750
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-2A
    Description: num_heads=1, frl_config=60, framebuffer=2048M, max_resolution=1280x1024, max_instance=8
  nvidia-751
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-4A
    Description: num_heads=1, frl_config=60, framebuffer=4096M, max_resolution=1280x1024, max_instance=4
  nvidia-752
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-8A
    Description: num_heads=1, frl_config=60, framebuffer=8192M, max_resolution=1280x1024, max_instance=2
  nvidia-753
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-16A
    Description: num_heads=1, frl_config=60, framebuffer=16384M, max_resolution=1280x1024, max_instance=1
＜略＞
  nvidia-753
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-16A
    Description: num_heads=1, frl_config=60, framebuffer=16384M, max_resolution=1280x1024, max_instance=1
root@vgpuserver:~#

vGPUでCUDAを使う場合はA2-?Q デバイスあたりを使う

0000:08:00.4にある RAM2GBのA2-2Q の nvidia-745 で定義を作成する

まず「0000:08:00.4」をlibvirtで使用するデバイスIDに変換するためvirsh nodedev-listコマンドで確認する

root@vgpuserver:~# virsh nodedev-list --cap pci|grep 08_00_4
pci_0000_08_00_4
root@vgpuserver:~#

「pci_0000_08_00_4」の「nvidia-745」が定義ファイルで使う値となる

また、定義ごとに一意のUUIDが必要になるので「uuidgen」コマンドを実行して値を確認してファイルを作成する

root@vgpuserver:~# uuidgen
73f353e8-7da8-4b76-8182-04c5a1415dec
root@vgpuserver:~# vi vgpu-test.xml
root@vgpuserver:~# cat vgpu-test.xml
<device>
    <parent>pci_0000_08_00_4</parent>
    <capability type="mdev">
        <type id="nvidia-745"/>
        <uuid>73f353e8-7da8-4b76-8182-04c5a1415dec</uuid>
    </capability>
</device>
root@vgpuserver:~#

作成したファイルをnodedevとして登録する

root@vgpuserver:~# virsh nodedev-define vgpu-test2.xml
Node device 'mdev_73f353e8_7da8_4b76_8182_04c5a1415dec_0000_08_00_4' defined from 'vgpu-test2.xml'

root@vgpuserver:~# virsh nodedev-list --cap mdev --inactive
mdev_73f353e8_7da8_4b76_8182_04c5a1415dec_0000_08_00_4

root@vgpuserver:~# virsh nodedev-list --cap mdev

root@vgpuserver:~#

登録できたmdevを開始する

root@vgpuserver:~# virsh nodedev-start mdev_73f353e8_7da8_4b76_8182_04c5a1415dec_0000_08_00_4
Device mdev_73f353e8_7da8_4b76_8182_04c5a1415dec_0000_08_00_4 started

root@vgpuserver:~# virsh nodedev-list --cap mdev
mdev_73f353e8_7da8_4b76_8182_04c5a1415dec_0000_08_00_4

root@vgpuserver:~# virsh nodedev-list --cap mdev --inactive

root@vgpuserver:~#

こうして作られたmdevデバイスをvirtshコマンドを使って直接仮想マシンに追加する

root@vgpuserver:~# virsh attach-device almalinux --persistent /dev/stdin <<EOF
<hostdev mode='subsystem' type='mdev' managed='no' model='vfio-pci' display='on'>
  <source>
    <address uuid='73f353e8-7da8-4b76-8182-04c5a1415dec'/>
  </source>
</hostdev>
EOF
Device attached successfully

root@vgpuserver:~#

これで設定ができたのであとは仮想マシンを起動して、仮想マシン内でvGPUドライバをインストールすれば使えました

ただ、HVM管理UIで設定を変えるとmdev設定は消えてしまうので、実用するにはつらいですね