zoneminderを移行するため、
- PVEが動作しているPCを停止
- 上記のPCからディスクを抜く
- PCの電源ON
という操作を行ったところ、(PVEのGUI上で)抜いたディスク(単一ディスクでLVMの単一VGを構成)のゴミが残っていた。本来はディスクを抜く前に、PVE上でしかるべき処理をすればよかったのだ。そうすれば、こんな苦労(ゴミ処理)をする必要もなかった。正式な処理を行わなかったばっかりに余計な工数をくってしまうというよくあるパターンなので戒めのために記録に残しておく。(いやその割にはゴミ処理が正式な方法じゃなさそうなんだけど?)
そうそう、なんの前置きもなくディスクを奪われたVMは起動できなかった。そのVMの定義からそのディスクをデタッチして削除しようとしたがそのタスクが失敗した(can’t activate LV ‘VG-name/LV-name’ to zero-out its data: Cannot process volume group VG-name)
このままにしておいてもPVEの動作自体には問題なさそうである。が、なんとなく気持ちが悪いのでゴミの処理を行うことにした。
ゴミ処理(無保証)
このセクションの内容はちゃんとしたドキュメントに基づくものではなく筆者の勘や憶測で作業を行っている。当然「無保証」である。ま、こんな記事で実作業を行う酔狂な人はいないと思うがとりあえず注意しておく。
Proxmox VEのOS自体のlvmコマンドを実行しても取り除いたディスクの情報はないので、PVE上の情報にゴミが残っていると判断。/etc/pveの下で上記のLVMの情報が含まれるファイルを探してみると、以下のファイルに情報が残っているようだ。
/etc/pve/storage.cfg内容は以下のとおりである。
dir: local
path /var/lib/vz
content backup,vztmpl,iso
lvmthin: local-lvm
thinpool data
vgname pve
content rootdir,images
lvm: VG-name
vgname VG-name
content rootdir,images
nodes vm30
shared 0
そのほか、ディスクを利用していた先ほどのノードの定義の中にも利用されていた。
/etc/pve/qemu-server/ノード番号.cfgその中の以下の行を削除する。
unused1: VG-name:LV-nameそういえば、このpveはクラスタを組んでいたのだった。もう一方のpveをのぞいてみると、storage.cfgに以下の内容が含まれていた。
lvm: VG-name
vgname VG-name
content rootdir,images
nodes vm30
shared 0
まず、ディスクを取り除いたpveでstorage.cfgのlvm: の項目を削除し保存する。さらに、ノード番号.cfgの修正を行う。
もう一方のpveの定義を変更しようとファイルを開くとすでに消えていた。GUI上でもゴミは消えていた。なんかすごい。
VMのほうも起動時エラーはなくなった。VM内のOSの処置(fstabの修正、zoneminderの停止)を行い、VMを自動起動しないように変更して終了。
コメント