ラズパイ x Proxmox VE (PVE, pimox, pxvirt) 環境でのUSBストレージ障害の対応メモ

Diary
ラズパイ x Proxmox VE (PVE, pimox, pxvirt) 環境でのUSBストレージ障害の対応メモ
Page content

効き目があるかもしれない策

ラズパイでProxmox VE (PVE, pimox, pxvirt) を運用し、かつ、USB接続のストレージをヘビーな負荷をかけて使用しているとする。ぶっちゃけこれは私の環境 (後述) の話なのだが、このような環境でUSBストレージ障害が発生した場合に、効き目があるかもしれない再発防止策などをポイントとして列挙する。

Point-1. 電源供給を安定化する

  • 消費電力の大きなUSBデバイスへの給電は、ラズパイからは行わない。可能な限り、USBハブ経由の接続としてUSBハブから給電する
  • ラズパイ本体およびUSB周辺機器へ給電するACアダプターは、信頼性が高く、出力が十分あるものにする

Point-2. LXC/VMのイメージファイルのエラーチェックをする

障害発生時に、運用中のLXC/VMのイメージファイルが何らかのダメージを受けているかもしれない。イメージファイルをエラーチェックしておいても損はないだろう。私の環境では実際にエラーが発見できたので、修復まで行った。

LXCの場合

対象とするLXCは停止状態にしておく。

  1. PVE上の、loopデバイスとLXCとの対応関係は「losetup --all」で確認できる
    $ sudo losetup --all
/dev/loop1: [2050]:385029 (/var/lib/vz/images/102/vm-102-disk-0.raw)
/dev/loop2: [2050]:1527086 (/var/lib/vz/images/103/vm-103-disk-0.raw)
/dev/loop0: [2050]:384971 (/var/lib/vz/images/100/vm-100-disk-0.raw)
/dev/loop3: [2050]:1017910 (/var/lib/vz/images/109/vm-109-disk-1.raw)
  2. rawファイルをエラーチェックする
    $ sudo fsck.ext4 -f /var/lib/vz/images/102/vm-102-disk-0.raw
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/var/lib/vz/images/102/vm-102-disk-0.raw: 38921/262144 files (2.6% non-contiguous), 792826/1048576 blocks

VMの場合

対象とするVMは停止状態にしておく。

  1. qcow2ファイルをエラーチェックする
    $ sudo qemu-img check /var/lib/vz/images/108/vm-108-disk-0.qcow2
$ sudo qemu-img check /var/lib/vz/images/108/vm-108-disk-1.qcow2
  2. qcow2ファイル内の各パーティションをエラーチェックする
    $ sudo qemu-nbd --connect=/dev/nbd0 /var/lib/vz/images/108/vm-108-disk-0.qcow2
$ sudo fdisk -l /dev/nbd0 # パーティションの一覧が得られる
$ sudo fsck.ext4 -f /dev/nbd0p1 # エラーチェックしたいパーティションを指定
$ sudo qemu-nbd --disconnect /dev/nbd0

Point-3. PVEのSwapファイルを作り直す (効果は未確認のおまじない)

障害発生時に、比較的広大なSwapファイルが何らかのダメージを受けているかもしれない、という想像に基づく。

  1. Swapの無効化・サービスを停止する
    $ sudo dphys-swapfile swapoff
$ sudo systemctl stop dphys-swapfile
  2. Swapファイルを削除する
    $ sudo dphys-swapfile uninstall # /var/swapファイルが削除される
  3. Swapファイルを作り直す・サービスを再開する
    $ sudo dphys-swapfile setup # /var/swapファイルが生成される
$ sudo dphys-swapfile swapon

Point-4. USBストレージの転送モードを「usb-storage」に変更する

本変更は、USBデータ転送の高速性よりも安定性を重視したものとなる。

  1. USBストレージ (Class=Mass Storage) が使用しているDriverのデフォルト「uas」を確認する (この例では対象のUSBストレージは2つ)
    $ lsusb -t -v
(省略)
		|__ Port 1: Dev 4, If 0, Class=Mass Storage, Driver=uas, 5000M
			ID 0781:55af SanDisk Corp. 
(省略)
	|__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=uas, 5000M
		ID 0411:0397 BUFFALO INC. (formerly MelCo., Inc.)
  2. /boot/firmware/cmdline.txtの各種設定 (1行) の最後に「usb-storage.quirks=XXXX:XXXX:u」を追加する。「XXXX:XXXX:u」のXXXX:XXXX部分は該当のUSBストレージのIDに置き換える。USBストレージが複数ならカンマ区切りで続けて書く
    $ cat /boot/firmware/cmdline.txt
(省略) usb-storage.quirks=0411:0397:u,0781:55af:u
  3. ラズパイを再起動する
  4. USBストレージ (Class=Mass Storage) が使用しているDriverが「usb-storage」に変更されたことを確認する
    $ lsusb -t -v
(省略)
		|__ Port 1: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
			ID 0781:55af SanDisk Corp. 
(省略)
	|__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
		ID 0411:0397 BUFFALO INC. (formerly MelCo., Inc.)

転送モード変更の意図

USBストレージの転送モードの「uas」から「usb-storage」への変更は、規格的に言うと、「USB Attached SCSI」という新しいモードから古いモードへ切り替えていることを意味する。これにはデメリットもあって、下記の記事のようにおそらくデータ転送速度を低下させる変更となるが、

ラズパイでの「uas」においては、チップセットとの相性などの何らかの問題により、安定性がまだ完璧ではない可能性もありうると考えている。

私の環境について

構成

本構成では、USBストレージを接続するためのSSD/HDDケースなどは介在しておらず、USBストレージ製品を直接接続の状態で用いている。

ストレージ利用に関わる主なタスク

OS領域にはProxmox VE (PVE, pimox, pxvirt) を導入しており、Home AssistantのVMが1個、他のLXCが4個、常時動いている。データ領域には、クラウド上のDropbox (実使用量約1.0TB) とGoogle Drive (同約1.4TB) のデータを、週に4回深夜にバックアップしている。したがって、我が家のRaspberry Pi 4において、特にこのバックアップ実施中には、USBデータ転送を酷使しつつ相当な量のディスクI/Oが発生していると思われる。

現象 / 障害対応の時系列

  1. 上記の構成でサーバ運用しているラズパイの稼働中に、機能停止が多発した。何度目かの障害時に、ヘッドレス運用しているラズパイにモニターを接続して画面の表示内容を確認したところ次の通り。[2025-04-25]
  2. なんとなく、USBデバイスの瞬断が起こっているのではないか？と推測し、電源供給方法を見直して、電力不足による電源の瞬断が起こりにくいであろう状態にした。[2025-05-11]
  3. それでも、時々、サーバが機能停止した。
  4. この頃から、ラズパイにリモートKVM装置であるGL.iNet GL-RM1を常時接続するようにしており、コンソール画面に表示される内容をネットワーク経由ですぐに確認できるようになった。
  5. これまでに起こった障害の影響で、仮想マシンのイメージが論理的に壊れているかもしれない可能性を考えて、仮想マシンのイメージファイルのエラーチェックを行ったところ、データ不整合がいくつか発見できて実際に回復が行われた。[2025-08-28]
  6. それでもまだ、サーバが機能停止する。
  7. USBストレージドライバに関する次の記事を見つけ、ドライバを切り替える対応をやってみた。[2025-09-02]
  8. 対応から10日以上が経過。今のところ何も問題は起こっていない。[2025-09-14]

以上、ここまでやって、我が家のラズパイ x Proxmox VE (PVE, pimox, pxvirt) 環境は、やっと安定してくれたのではないか？と希望的観測をしている。