Salah satu hal berbahaya dalam dunia komputer adalah “Ungraceful shutdown” / “Unplanned shutdown” atau yang sering kita sebut dengan “Tiba-tiba mati sendiri” 😀 .
Komputer yang mati secara tiba-tiba merupakan ancaman yang sangat nyata bagi rekan-rekan yang bekerja di dunia IT, karena bisa menyebabkan data di komputer tersebut corrupt, lalu….tidak bisa di fix, lalu…..tidak ada backup, lalu….dimarahain atasan deh 😀 .
Masalah seperti inilah yang sering saya hadapi di server VMware yang tiba-tiba mati. Biasanya terjadi di server yang ada di rumahan 😀 (Maklum perumahan kan kadang suka mati listrik 😀 ). Walaupun alhamdulillah data sistem operasi VMware tidak corrupt….tetapi data virtual hard disk VM (VMDK) nya yang corrupt :D, alhasil VM tidak bisa di start.
Selain karena server VMware mati secara mendadak, hal lain yang bisa membuat VMDK corrupt dan cukup sering terjadi adalah proses snapshot yang tidak selesai. Misalnya snapshot di cancel pada saat sedang berjalan, VM mati tiba-tiba saat proses snapshot berjalan, ataupun VMDK snapshot terhapus (Contoh nama VMDK snapshot : disk1-000001.vmdk disk1-000002.vmdk).
VM dengan VMDK yang corrupt biasanya akan memunculkan error dengan pesan berikut saat dinyalakan, “Object type requires hosted I/O Failed to start the virtual machine. Module ‘Disk’ power on failed. Cannot open the disk ‘(letak-vmdk)’ or one of the snapshot disks it depends on.“.
Jika mengalami hal tersebut, rekan-rekan bisa ikuti langkah-langkah dibawah ini untuk recover VM tersebut.
- Cloning VM yang corrupt (Dilakukan dari vCenter)
- Power on VM
Kedua langkah diatas adalah langkah yang paling mudah untuk recover VM yang corrupt, tetapi jika proses cloning gagal (Biasanya akan gagal di cloning saat VMDK dalam keadaan corrupt, tetapi tidak apa-apa dicoba untuk cloning terlebih dahulu, karena saya pernah recover VM yang corrupt menggunakan cara cloning seperti ini) atau vSphere tidak di manage oleh vCenter, rekan-rekan bisa mencoba metode dibawah ini.
- Membuat VM baru tanpa harddisk virtual dengan spesifikasi CPU & memori yang sama dengan VM corrupt, seperti contoh dibawah ini (Tanpa HDD virtual)
- Copy VMDK corrupt ke direktori VM baru yang digunakan untuk recover. Di copy ya, jangan di move
- Jika VMDK tidak bisa di copy (Sering terjadi saat VMDK dalam keadaan corrupt), silakan copy VMDK via CLI menggunakan remote SSH ke server vSphere
- Untuk copy VMDK via cli bisa mengggunakan perintah berikut
# cp -v /vmfs/volumes/(nama_datastore)/(nama_folder_vm-corrupt)/(nama_vmdk) /vmfs/volumes/(nama_datastore)/(nama_folder_vm-recover)/
- Setelah VMDK berhasil di copy, lanjutkan proses recover dengan cara menjalankan perintah (Via CLI) berikut dari direktori VM recover
# cd /vmfs/volumes/(nama_datastore)/(nama_folder_vm-recover) # vmkfstools -x check ./(nama_vmdk) Disk needs repair.
- Lalu jalankan perintah berikut untuk repair VMDK yang error
# vmkfstools -x repair ./(nama_vmdk) Disk was successfully repaired.
- Nyalakan VM recover
Sebenarnya prosesnya bisa lebih pendek, yaitu langsung menjalakan perintah repair pada VMDK asli yang ada di direktori VM existing, tetapi saya tidak rekomendasikan untuk melakukan hal itu. Karena satu hal yang perlu diingat saat ada data yang corrupt, “Jangan otak-atik data yang sudah terlanjur corrupt, salin dulu data tersebut ke tempat lain. Setelah itu baru salinan data utama boleh di otak-atik”. Mengapa? Alasannya, untuk mempertahankan posisi data yang saat ini sudah corrupt. Loh kok dipertahankan? Maksudnya dipertahankan adalah tidak memperburuk keadaan data yang sudah corrupt. Bayangkan saja, data yang sudah corrupt malah di otak-atik dan menyebabkan keadaan data makin tidak karuan dan menyebabkan peluang recover semakin kecil.
Catatan : Walaupun cara diatas bisa digunakan untuk repair VM yang corrupt, tetapi tidak menutup kemungkinan cara tersebut gagal sehingga VM tidak bisa di repair. Jadi memang hal terbaik untuk mengantisipasi masalah ini adalah mempersiapkan backup VM, sehingga VM bisa langsung di recover saat data corrupt. Misalnya menggunakan aplikasi Nakivo Backup & Replication untuk VMware.