Di pekerjaan infrastruktur, memindahkan disk antarserver, mengganti controller storage, atau memakai replika LUN untuk uji pemulihan adalah kejadian rutin. Masalahnya sering muncul setelah itu: disk terlihat di ESXi, tetapi datastore di dalamnya tidak ter-mount. Data masih utuh, hanya ESXi menolak memakainya secara otomatis.
Perintah yang saya pakai untuk kasus ini sebelumnya saya simpan di catatan. Dalam tulisan ini saya menjelaskan mengapa ESXi menganggap datastore tersebut sebagai salinan, perintah apa yang dipakai, dan risiko dari setiap pilihan, supaya keputusan di sisi storage tidak merusak bagian lain dari sistem.
Ada tiga hal yang perlu diluruskan dari catatan awal saya:
--volume-labeldiisi label yang sudah ada. Nilainya diambil dari outputsnapshot list, bukan label baru yang diinginkan. Setelah resignature, ESXi sendiri yang memberi nama baru berawalansnap-.
- Keep existing signature tidak selalu aman. Pilihan ini hanya berlaku bila datastore asli tidak terlihat oleh host, dan force mount membawa beberapa keterbatasan operasional.
- Resignature tidak bisa dibatalkan. Setelah UUID diganti, salinan itu tidak lagi diperlakukan sebagai replika dari datastore aslinya.
Peta singkat
Langkah | Perintah | Fungsi |
Cek disk | esxcli storage core device list | Memastikan device terlihat oleh host. |
Cek volume | esxcli storage vmfs snapshot list atau esxcfg-volume -l | Menampilkan VMFS yang terdeteksi sebagai salinan. |
Force mount | esxcfg-volume -M <UUID> | Mount dengan signature lama. |
Resignature | esxcli storage vmfs snapshot resignature -l <label> | Memberi UUID baru lalu mount. |
1. Mengapa datastore dianggap salinan
Setiap datastore VMFS memiliki signature unik, yaitu UUID, yang disimpan di superblock file system. Ketika sebuah device direplikasi atau di-snapshot di sisi storage array, hasilnya identik byte demi byte dengan aslinya, termasuk UUID-nya.
Selain snapshot dan replikasi, operasi pada device seperti perubahan LUN ID juga dapat membuat ESXi melihat datastore sebagai salinan. Ini yang terjadi ketika disk dipindah ke server lain atau controller-nya diganti.
ESXi tidak otomatis me-mount salinan tersebut. Mekanisme ini adalah pengaman: dua datastore dengan UUID yang sama tidak boleh aktif bersamaan karena metadatanya akan bentrok.
2. Memeriksa disk dan volume
Langkah pertama adalah memastikan disk terlihat:
esxcli storage core device listLalu tampilkan volume VMFS yang terdeteksi sebagai salinan:
esxcli storage vmfs snapshot listAtau dengan perintah lama yang juga menampilkan nama extent (NAA):
esxcfg-volume -lOutput-nya memuat UUID/label, apakah volume bisa di-mount, dan apakah bisa di-resignature, beserta alasannya jika tidak bisa. Jika volume tidak muncul sama sekali, penyebab paling umum adalah host belum di-rescan, atau device yang sebelumnya dilepas masih dalam status detached.
Kasus yang perlu diwaspadai adalah duplicate extents: dua atau lebih salinan dari datastore yang sama, dengan label dan UUID identik, terlihat oleh host yang sama. Dalam kondisi ini resignature dan force mount sama-sama diblokir, dan satu-satunya opsi yang tersisa di GUI adalah format. Opsi format jangan dipilih karena akan menghapus isi datastore. Solusinya adalah melepas salah satu device, baik dari sisi array maupun dengan operasi detach di host.
3. Force mount dengan signature lama
esxcfg-volume -M <UUID>Opsi
-M membuat mount bertahan setelah reboot, sedangkan -m hanya sementara. Di vSphere Client, pilihan ini muncul sebagai Keep Existing Signature pada wizard New Datastore.Pilihan ini cocok bila datastore asli sudah tidak terlihat di mana pun. Dokumentasi vSphere memberi contoh situs DR: salinan VM dijaga sinkron di situs sekunder, lalu ketika situs utama gagal, salinan datastore di-mount dan VM dinyalakan di situs sekunder.
Yang perlu diwaspadai:
- Force mount ditolak bila datastore aslinya masih online di vCenter. Datastore asli harus di-unmount lebih dulu.
- vCenter tidak melakukan force mount ke banyak host sekaligus. Mount harus dilakukan per host, dan rescan tidak membuat host lain ikut me-mount volume tersebut.
- Jika host lain me-resignature salinan yang sama, UUID-nya berubah dan VM di datastore yang di-force mount bisa kehilangan storage-nya.
- Selama ada salinan yang di-force mount, resignature salinan lain dari sumber yang sama melalui vCenter akan gagal, termasuk yang dijalankan oleh tool replikasi atau backup.
Karena itu, saya memperlakukan force mount sebagai jalan cepat untuk kasus tertentu, bukan pilihan default.
4. Resignature
Resignature memberi datastore UUID baru sehingga ia tidak lagi bentrok dengan aslinya. Langkahnya:
- Rescan storage pada host.
- Ambil label atau UUID dari
esxcli storage vmfs snapshot list.
- Jalankan resignature:
esxcli storage vmfs snapshot resignature -l <label>atau dengan UUID:
esxcli storage vmfs snapshot resignature -u <UUID>Di vSphere Client, pilihan ini muncul sebagai Assign a New Signature. Setelah proses selesai, datastore ter-mount sebagai datastore yang terpisah dari aslinya, dengan nama berawalan
snap-XXXXXXXX- di depan nama lama. Prefiks ini mencegah nama yang bentrok bila datastore asli masih terlihat di vCenter.Yang perlu diwaspadai:
- Resignature tidak dapat dibalik. Setelah itu, device tersebut tidak lagi dianggap replika dari aslinya.
- Datastore yang terdiri dari beberapa extent hanya bisa di-resignature bila semua extent-nya online.
- Proses ini fault tolerant. Jika terputus, prosesnya dapat dilanjutkan kemudian.
5. Memilih di antara keduanya
Kondisi | Pilihan |
Host dapat melihat datastore asli dan salinannya | Resignature |
Replika untuk uji DR di samping produksi | Resignature |
Datastore asli sudah tidak ada, salinan dipakai di situs atau server pengganti | Force mount, dengan memperhatikan keterbatasannya |
Duplicate extents | Lepas salah satu device, lalu resignature |
Penutup
Urutan yang saya sarankan: periksa device, rescan, baca output
snapshot list atau esxcfg-volume -l dengan teliti, selesaikan duplicate extents atau extent yang hilang, baru putuskan antara force mount dan resignature. Jangan pernah memilih format hanya karena opsi lain tidak tersedia.Masalah ini terlihat seperti urusan storage, tetapi dampaknya menjalar ke inventory VM, cluster, tool backup, dan proses pemulihan bencana. Karena itu, langkah-langkah di atas sebaiknya ditulis sebagai runbook dan diuji saat uji DR, bukan ditemukan ulang ketika insiden sedang terjadi.