例年、vExpert にはだいた1年のほぼ全製品の評価版が渡されており、自由に検証に使うことができる。あくまで個人への割り当てのため家の私物 ESXi 環境などに入れても問題がないため、これは結構重宝する。
さて、そのVSANの検証をしていて、VSANの構成にHDDやSSDを使おうとした際、あるいはその逆でVSANで使ってたディスクを VMFSで利用しようとすると、構成時にそのディスクが選択肢に表示されず、利用できないことがあった。
どうやら以前に一方で使っていたディスクは、もう一方に使えないようになっているようだ。これはフェイルセーフとしても納得がいく。何らかの理由で孤立してしまい、単体では VSANの一部として見なされないディスクをうっかりVMFSで上書きしてしまっては困るからだ。
とはいえ、検証でディスクを使い回しているとそうも言ってられない。
ので、少々乱暴だが認識できるようにしたので、メモをしておく。
● なぜ認識されないか
VMFSを削除したり VSANを解放しても、SSD/HDD上にはその時に作成されたパーティション情報が残っている。ESXi はこのパーティション情報を見て VSAN/VMFSで使っていたことを検知する。VMFSで使ってた領域を VMFSで使う分には問題ないのだが、タイプを変えようとするとお互いの選択肢から除外されてしまう訳だ。
(なお、これに限らず、ESXi はなんらかのパーティション情報があると選択肢から除外する傾向がある。Linux 等で使ってたディスクを追加のVMFSとして使う際はこれが問題になる事がある。 )
このため、パーティションテーブルをクリアすれば新しいSSD/HDDのように素直に認識してくれる。
● パーティションの削除(失敗編)
さて、パーティションテーブルを飛ばすとなると、普通 dd コマンドだろう。
(大事なことなので強調してみました)
しかし、なんとも嘆かわしいことに ESXi Shell では dd コマンドは使えない。
存在はするのだが、ディスクドライバ側に必要なAPIが備わってないため、書き込みができないのだ。
# dd if=/dev/zero of=/dev/disks/naa.600508b1001cccc92c42c05aa821872a count=1 bs=1M
dd: can't open '/dev/disks/naa.600508b1001cccc92c42c05aa821872a': Function not implemented
嘆かわしい、実に嘆かわしいっ。
仕方が無いので、前時代的で格好の悪いパーティション操作系のコマンドを使うことになる。もういつから使ってるか分からない、あの fdisk だ。
ただ、ESXi の作者はすこしは正気が残ってたようで、fdisk コマンドは動きはするが非推奨となっている。MBRパーティションではなく GPT を使ってるからだ。
# fdisk -l /dev/disks/naa.
***
*** The fdisk command is deprecated: fdisk does not handle GPT partitions. Please use partedUtil
***
Found valid GPT with protective MBR; using GPT
Disk /dev/disks/naa.
Logical sector size: 512
Disk identifier (GUID): b380795f-8cc1-4991-b911-
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 390651806
Number Start (sector) End (sector) Size Code Name
1 2048 6143 4096 0700
2 6144 390651806 372M 0700
上記のように、fdisk を実行すると推奨されるのが partedUtil というコマンドだ。
● partedUtil で情報を取得する
partedUtil でのパーティション情報の取得には get/set とgetptbl/setptbl という2つの系統がある。どっちも fdisk にくらべればシンプルだが、より細かい情報が出るのは getptbl の方だ。
# partedUtil get /dev/disks/naa.600508b1001cccc92c42c05aa821872a
24316 255 63 390651840
1 2048 6143 0 0
2 6144 390651806 0 0
# partedUtil getptbl /dev/disks/naa.600508b1001cccc92c42c05aa821872a
gpt
24316 255 63 390651840
1 2048 6143 381CFCCC728811E092EE000C2911D0B2 vsan 0
2 6144 390651806 AA31E02A400F11DB9590000C2911D1B8 vmfs 0
get/set では「パーティション番号」「開始ブロック」「終了ブロック」「タイプ」「属性」の順で、getptbl/setptbl では「パーティション番号」「開始ブロック」「終了ブロック」「UUID」「属性」となっている。実際には上記のように、UUIDのあと、そのUUIDの意味がテキストで表示されている。どの用途(ファイルシステムなど)でどのUUIDを使うかは、showGuids オプションで確認できる
# partedUtil showGuids
Partition Type GUID
vmfs AA31E02A400F11DB9590000C2911D1B8
vmkDiagnostic 9D27538040AD11DBBF97000C2911D1B8
vsan 381CFCCC728811E092EE000C2911D0B2
VMware Reserved 9198EFFC31C011DB8F78000C2911D1B8
Basic Data EBD0A0A2B9E5443387C068B6B72699C
Linux Swap 0657FD6DA4AB43C484E50933C84B4F4F
Linux Lvm E6D6D379F50744C2A23C238F2A3DF928
Linux Raid A19D880F05FC4D3BA006743F0F84911E
Efi System C12A7328F81F11D2BA4B00A0C93EC93B
Microsoft Reserved E3C9E3160B5C4DB8817DF92DF00215AE
Unused Entry 00000000000000000000000000000000
実際にブートドライブを partedUtil で見たのが、以下だ。
# partedUtil getptbl /dev/disks/naa.600508b1001c7b1101f3c08c5b2c5784
gpt8920 255 63 143305920
1 64 8191 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128
5 8224 520191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 520224 1032191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 1032224 1257471 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
8 1257504 1843199 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
9 1843200 7086079 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
2 7086080 15472639 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
3 15472640 143305886 AA31E02A400F11DB9590000C2911D1B8 vmfs 0
EFI準拠のため、先頭に EFI パーティションが存在する。LinuxNative の部分がブート用に使用され、vmkDiagnostic がカーネルだんぶ領域だ。最後のVMFSは datastore1 に相当する部分にあたる。パーティションの物理的な所在と、パーティション番号が異なるのも注意を要する。
どのドライブがどのデバイス名を持っているかは、色々調べる方法がある。
こちらのブログのように esxcfg-scsidevs コマンドを使っても良いし、以下のように esxcli でも同じ結果を得られる。
# esxcli storage core device list
naa.600508b1001c36b38da960b49ca5fbed
Display Name: HP Serial Attached SCSI Disk (naa.600508b1001c36b38da960b49ca5fbed)
Has Settable Display Name: true
Size: 3815350
Device Type: Direct-Access
Multipath Plugin: NMP
Devfs Path: /vmfs/devices/disks/naa.600508b1001c36b38da960b49ca5fbed
Vendor: HP
Model: LOGICAL VOLUME
Revision: 1.28
SCSI Level: 5
Is Pseudo: false
Status: degraded
Is RDM Capable: true
Is Local: false
Is Removable: false
Is SSD: false
Is Offline: false
Is Perennially Reserved: false
Queue Full Sample Size: 0
Queue Full Threshold: 0
Thin Provisioning Status: unknown
Attached Filters:
VAAI Status: unknown
Other UIDs: vml.0200030000600508b1001c36b38da960b49ca5fbed4c4f47494341
Is Local SAS Device: false
Is Boot USB Device: false
No of outstanding IOs with competing worlds: 32
naa.600508b1001c7b1101f3c08c5b2c5784
Display Name: HP Serial Attached SCSI Disk (naa.600508b1001c7b1101f3c08c5b2c5784)
Has Settable Display Name: true
Size: 69973
(後略)
非常に多くの情報が出るので適宜 grep で削ってもいい。お目当てがどのデバイスかは、サイズとやベンダー名、Display Name あたりがヒントになるだろう。
なお、partedUtil について記載している VMware 社のKB1036609 では、ディスクを見つけるのに /dev/disks 以下を調べろ、というなかなか素敵なことが書いてある。
余談だが、VSANで使ってた、個別にマウントされていたHDDを HP社の SmartArray でRAID5で束ねた場合、partedUtil で見るとこんなことになる。
# partedUtil getptbl /dev/disks/naa.600508b1001c36b38da960b49ca5fbed
Error: The backup GPT table is not at the end of the disk, as it should be. This might mean that another operating system believes the disk is smaller. Fix, by moving the backup to the end (and removing the old backup)? This will also fix the last usable sector as per the new size. diskSize (7813837232) AlternateLBA (1953459631) LastUsableLBA (1953459598)
Error: The primary GPT table on '/dev/disks/naa.600508b1001c36b38da960b49ca5fbed' is OK, but secondary is corrupt. Fix secondary table? This will move secondary at the end in case it is not at the end already. It will also set LastUsableLBA to use all the space at the end. diskSize (7813837232) AlternateLBA (1953459631) LastUsableLBA (1953459598)
Warning: Not all of the space available to /dev/disks/naa.600508b1001c36b38da960b49ca5fbed appears to be used, you can fix the GPT to use all of the space (an extra 5860377600 blocks) or continue with the current setting? This will also move the backup table at the end if is is not at the end already. diskSize (7813837232) AlternateLBA (1953459631) LastUsableLBA (1953459598) NewLastUsableLBA (7813837198)
gpt
486388 255 63 7813837232
1 2048 6143 381CFCCC728811E092EE000C2911D0B2 vsan 0
2 6144 1953459598 AA31E02A400F11DB9590000C2911D1B8 vmfs 0
間にすごく長いエラーメッセージが表示されるが、要は、先頭のGPTパーティションテーブルと、末尾にあるはずのバックアップテーブルが一致しない、というエラーになる。
すくなくとも SmartArray では、RAIDを組んだだけでは内容がクリアされない、以前の単一ディスクだったときのどれかのパーティションテーブルが見えてしまうことがあるようだ。
こういう場合は、partedUtil fixGpt <デバイス名> コマンドを実行することで、パーティションテーブルの復元が行われる。
● partedUtil でパーティションを削除する
ここまで分かれば、後は簡単だ。パーティションを削除すれば良い。
ブートドライブや共有ディスクを誤って殺ってしまわないよう、またパーティション番号にも注意して、以下のように partedUtil delete コマンドを実行する
# partedUtil getptbl /dev/disks/naa.600508b1001cb619f764cc6d47de5db0
gpt486388 255 63 7813837232
1 2048 6143 381CFCCC728811E092EE000C2911D0B2 vsan 0
2 6144 1953459598 AA31E02A400F11DB9590000C2911D1B8 vmfs 0
# partedUtil delete /dev/disks/naa.600508b1001cb619f764cc6d47de5db0 2
# partedUtil delete /dev/disks/naa.600508b1001cb619f764cc6d47de5db0 1
#
再認識後は、VMFSの作成などで再び選択肢に表示されるようになる。
● VSAN で使っていたSSDの場合
ただ、VSANで使われていた SSD の場合、2つできているパーティションの後者が削除されないという問題が生じた。
gpt
24316 255 63 390651840
1 2048 6143 381CFCCC728811E092EE000C2911D0B2 vsan 0
2 6144 390651806 AA31E02A400F11DB9590000C2911D1B8 vmfs 0
# partedUtil delete /dev/disks/naa.600508b1001cccc92c42c05aa821872a 1
# partedUtil delete /dev/disks/naa.600508b1001cccc92c42c05aa821872a 2
Error: Read-only file system during write on /dev/disks/naa.600508b1001cccc92c42c05aa821872a
Unable to delete partition 2 from device /dev/disks/naa.600508b1001cccc92c42c05aa821872a
どうやら、SSDについては ESXi の VSAN モジュールが握っており、簡単には解放させてくれないようだ。
- esxcli vsan cluster leave コマンドで VSANを終わらせる
- 下記の vmkload_mod コマンドで VSAN関連のモジュールを排除し、解除させる
- vmkload_mod -u vsan
- vmkload_mod -u plog
- vmkload_mod -u lsocommon
ただ、ブログにも記載があるが、1. ではうまくいかないことが多いようだ。私の場合、先に1つパーティションを消して情報を欠損させているせいか、やはりうまくいかなかった。
ので 2. にある3つの vmkload_mod を実行した。すると、上記にある Read-only のエラーが出なくなり、パーティションが削除された。
なお、別解としては以下がある
- SSDの2つあるパーティションのうち一方を削除後、ESXi を再起動
再起動が一回かかるので面倒で時間はかかるが、強制的なモジュール排除などを必要としないのでまだ安全かと思われる。
