Dalam pekerjaan administrasi infrastruktur, disk yang terlihat oleh ESXi belum tentu berarti datastore di dalamnya sudah dapat diakses. Saya memisahkan pemeriksaan device, pengenalan volume VMFS, dan status mount agar tidak langsung menjalankan perintah pada storage yang keliru.
Tulisan ini merapikan catatan saya dari web lama saya tentang mount datastore yang sudah ada. Fokusnya adalah memakai kembali volume dengan identitas yang sama, bukan membuat datastore baru atau mengganti signature.
Dua hal dari catatan awal perlu diperjelas:
esxcfg-volume -lmenampilkan VMFS yang terdeteksi sebagai snapshot atau replika, bukan seluruh volume yang belum di-mount.
- Server lama yang sudah tidak digunakan belum cukup menjadi alasan untuk force mount. Identitas volume harus dipastikan, dan tidak boleh ada konflik dengan datastore lain ber-UUID sama.
1. Pastikan device terlihat
Jalankan melalui ESXi Shell atau SSH dengan hak administrasi:
esxcli storage core device listCocokkan identitas device dengan disk atau LUN yang dimaksud. Jangan menyimpulkan data masih utuh hanya karena device muncul.
Jika storage baru dipresentasikan ke host, lakukan rescan dari pengelolaan storage, lalu ulangi pemeriksaan. Bila device tetap tidak ditemukan, selesaikan konektivitas atau pengenalan device sebelum melanjutkan mount.
2. Periksa status volume
esxcli storage filesystem listCari volume tujuan dan periksa kolom
Mounted. Volume VMFS biasa yang dikenali tetapi belum di-mount menggunakan jalur pada langkah berikutnya.Jika volume tidak ada dalam daftar tersebut, periksa kemungkinan terdeteksi sebagai snapshot atau replika:
esxcfg-volume -lBaca UUID, label, extent, serta keterangan apakah volume dapat di-mount. Daftar kosong dari perintah ini tidak membuktikan partisi VMFS hilang.
Kondisi | Langkah |
Volume biasa, Mounted = false | Mount dengan storage filesystem mount. |
Volume muncul di esxcfg-volume -l | Periksa syarat mount dengan signature lama. |
Mounted = true | Tidak perlu menjalankan mount lagi. |
Tidak ditemukan atau mount ditolak | Telusuri penyebabnya; jangan beralih ke format. |
3. Mount volume VMFS biasa
Ambil UUID dari hasil pemeriksaan, lalu gunakan:
esxcli storage filesystem mount --volume-uuid="<UUID>"Alternatifnya, gunakan label:
esxcli storage filesystem mount --volume-label="<datastore-label>"Pilih salah satu identitas. Ganti placeholder dengan nilai yang benar; tanda kutip membantu ketika label mengandung spasi. Mount ini persisten secara default. Periksa bantuan perintah pada host bila opsi berbeda:
esxcli storage filesystem mount --help4. Mount dengan signature lama bila diperlukan
Bagian ini hanya untuk volume yang muncul pada
esxcfg-volume -l dan memenuhi syarat mount. Pastikan datastore asli tidak online dan tidak ada konflik UUID. Mount bukan akses read-only; volume akan digunakan untuk baca dan tulis.Untuk mount persisten:
esxcfg-volume -M "<UUID>"Untuk mount sementara:
esxcfg-volume -m "<UUID>"Huruf besar dan kecil berbeda:
-M mempertahankan mount setelah reboot, sedangkan -m tidak. Keduanya mempertahankan signature volume.Jika hasil pemeriksaan menyatakan volume tidak dapat di-mount, berhenti dan baca alasannya. Mengulang force mount bukan penyelesaian konflik identitas atau extent yang tidak tersedia.
5. Verifikasi hasilnya
esxcli storage filesystem listPastikan UUID dan label sesuai, serta
Mounted bernilai true. Buka datastore melalui browser datastore dan periksa direktori yang diharapkan sebelum mengoperasikan VM.Persisten berarti konfigurasi mount dipertahankan; keberhasilan melewati reboot tetap perlu dibuktikan pada jadwal pemeliharaan yang aman. Jangan me-reboot host produksi hanya untuk memeriksa artikel ini.
Penutup
Urutan yang saya gunakan sebagai panduan adalah: kenali device, periksa volume, pilih jalur mount yang sesuai, lalu verifikasi hasilnya. Jangan membuat datastore baru atau memilih format untuk mengatasi volume lama yang belum ter-mount.
Dengan urutan tersebut, mount menjadi tindakan yang terukur dalam administrasi storage, bukan percobaan perintah tanpa memahami kondisi sistem.
Referensi
Catatan asal: .
