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設定は消えてしまうので、実用するにはつらいですね

Proxmoxで作った仮想マシンのsnapshotはどうやって見えるのか?

Proxmoxで仮想マシンを作った場合、仮想マシンのsnapshotの作られ方が仮想マシンを置く場所(データストア)によって異なっている。

zfsについては簡単に確認できたが、それ以外についてどうなるのかを確認した。

まず、proxmoxのWeb UIからスナップショットを作成した

これをコマンドで確認していく

まず、Proxmox VE側のコマンドで仮想マシンにsnapshotがあるかどうかは「qm listsnapshot <VMID>」を実行して確認できる。これは各ファイルシステムで共通となる。

root@pve3:~# qm listsnapshot 103
`-> test                        2025-04-17 15:19:16     no-description
 `-> current                                            You are here!
root@pve3:~#

次に各ファイルシステムごとにそれぞれ確認していく手法が違う。

ZFSの場合

例えばzfsの場合であれば 「zfs list -t snapshot」で確認できる。

root@pve3:~# qm listsnapshot 101
`-> zfs-test-snap               2025-04-17 15:39:18     no-description
 `-> current                                            You are here!
root@pve3:~# zfs list -t snapshot
NAME                                     USED  AVAIL  REFER  MOUNTPOINT
rpool/data/vm-101-disk-0@zfs-test-snap     0B      -   139K  -
rpool/data/vm-101-disk-1@zfs-test-snap     0B      -  22.8G  -
rpool/data/vm-101-disk-2@zfs-test-snap     0B      -  22.1M  -
rpool/data/vm-101-disk-3@zfs-test-snap     0B      -  85.2K  -
root@pve3:~#

NFSの場合

NFSの場合、仮想マシンをqcow2形式で作成した場合のみsnapshot作成が可能となる。

まず仮想マシンの設定を確認

root@pve3:~# qm config 105
agent: 1
boot: order=sata0;ide0;ide2;net0
cores: 2
cpu: x86-64-v2-AES
ide0: none,media=cdrom
ide2: none,media=cdrom
machine: pc-i440fx-9.2+pve1
memory: 2048
meta: creation-qemu=9.2.0,ctime=1744345484
name: wintest3-nfs
net0: e1000=BC:24:11:FD:D4:F3,bridge=vmbr0,firewall=1
numa: 0
ostype: win10
parent: nfs-snap
sata0: ontap:105/vm-105-disk-0.qcow2,size=40G
scsihw: virtio-scsi-single
smbios1: uuid=7a3e58d8-be9e-4e03-a040-bd1635aa3dfe
sockets: 1
vmgenid: f361fff2-f474-4260-99ac-586c42db009b
root@pve3:~# qm listsnapshot 105
`-> nfs-snap                    2025-04-17 15:39:29     no-description
 `-> current                                            You are here!
root@pve3:~#

該当する領域をlsコマンドで確認

root@pve3:~# ls -l /mnt/pve/ontap/images/105
total 13607536
-rw-r----- 1 root root 45504004165 Apr 17 15:36 vm-105-disk-0.qcow2
root@pve3:~#

見た目には1ファイルしかないように見える。

このファイルに対して「qemu-img snapshot -l ファイル名」を実行するとsnapshotが作成されているかどうかがわかる。

root@pve3:~# qemu-img snapshot -l /mnt/pve/ontap/images/105/vm-105-disk-0.qcow2
Snapshot list:
ID      TAG               VM_SIZE                DATE        VM_CLOCK     ICOUNT
1       nfs-snap              0 B 2025-04-17 15:39:29  0000:00:00.000          0
root@pve3:~#

cephの場合

cephの場合、rbdコマンドのオプションでいろいろ指定していくのだが、確認がちょっとめんどい

まずは、仮想マシンの設定を「qm config <VMID>」を実行して確認する。

root@pve3:~# qm config 103
agent: 1
boot: order=scsi0;ide2;net0
cores: 2
cpu: x86-64-v2-AES
ide2: none,media=cdrom
memory: 2048
meta: creation-qemu=9.2.0,ctime=1744338514
name: linux2-ceph
net0: virtio=BC:24:11:3A:D1:9E,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
parent: test
scsi0: cephpool:vm-103-disk-0,iothread=1,size=40G
scsihw: virtio-scsi-single
smbios1: uuid=37f0d81e-3ed1-417a-9a10-3d8f556e3b37
sockets: 1
vmgenid: 0ea7ac3f-7b05-49d0-90c0-fbba87cc63ae
root@pve3:~# qm listsnapshot 103
`-> test                        2025-04-17 15:19:16     no-description
 `-> current                                            You are here!
root@pve3:~#

scsi0の行にある「cephpool」が使用しているデータストア名となる。

Ceph RDBが使用しているOSD Pool名を「ceph osd pool ls」を実行して確認する

root@pve3:~# ceph osd pool ls
.mgr
cephpool
cephfs_data
cephfs_metadata
root@pve3:~#

cephfs_dataとcephfs_metadataはCeph FSのほうで使っているデータで、仮想マシンをおくデータストアはcephpool のほうとなる。

cephpoolにある仮想マシン用のディスクを「rbd ls cephpool」で確認する

root@pve3:~# rbd ls cephpool
vm-103-disk-0
root@pve3:~#

この仮想マシンについて、snapshotが作成されているかは「rbd snap ls cephpool/<仮想ディスク名>」で確認する

root@pve3:~# rbd snap ls cephpool/vm-103-disk-0
SNAPID  NAME  SIZE    PROTECTED  TIMESTAMP
    10  test  40 GiB             Thu Apr 17 15:19:16 2025
root@pve3:~#

VMware Flingsにあったソフトウェアがbroadcomになって移転した先

ESXi for ARM EditionやUSB Network Native Driver for ESXi といった以前VMware Flings http://flings.vmware.com にあったソフトウェアは、2023年10月に https://developer.vmware.com/samples にリダイレクトされるようになった。

このURLは、 https://developer.broadcom.com/samples にリダイレクトされるのだが、2025年4月2日時点では、errorとなっている。

では、以前VMware Flings にあったものがどこにあるのかというと Broadcom communityの「Welcome to the new home for Flings!」にあった

2024年8月に更新されたvSphere GPU Monitoring を最後に更新はないように見えたけど、

よくみてみたら「Nested ESXi Virtual Appliance」は ESXi 8.0 Update 3c VAが出てた