Meskipun ini pertanyaan yang relatif lama, jawabannya tetap sama. Anda memiliki mesin virtual (berjalan di host fisik) dan semacam penyimpanan (baik penyimpanan bersama – FC SAN, penyimpanan iSCSI, berbagi NFS – atau penyimpanan lokal).
Dengan virtualisasi, banyak mesin virtual mencoba mengakses sumber daya fisik yang sama secara bersamaan. Karena keterbatasan fisik (jumlah operasi baca/tulis – IOPS; throughput; latensi) mungkin ada masalah untuk memenuhi semua permintaan penyimpanan dari semua mesin fisik secara bersamaan. Apa yang biasanya terjadi:Anda akan dapat melihat "SCSI retries" dan operasi SCSI yang gagal di sistem operasi mesin virtual Anda. Jika Anda mendapatkan terlalu banyak kesalahan/coba lagi dalam jangka waktu tertentu, kernel akan menyetel sistem file yang dipasang hanya-baca untuk mencegah kerusakan pada sistem file.
Singkat cerita:Penyimpanan fisik Anda tidak cukup "kuat". Ada terlalu banyak proses (mesin virtual) yang mengakses sistem penyimpanan pada saat yang sama, mesin virtual Anda tidak mendapatkan respons yang cukup cepat dari penyimpanan, dan sistem file menjadi hanya-baca.
Tidak banyak hal yang dapat Anda lakukan. Solusi yang jelas adalah penyimpanan yang lebih baik/tambahan. Anda juga dapat memodifikasi parameter untuk batas waktu SCSI di kernel Linux. Detail dijelaskan, mis., di:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009465
http://www.cyberciti.biz/tips/vmware-esx-server-scsi-timeout-for-linux-guest.html
Namun, ini hanya akan "menunda" masalah Anda, karena kernel hanya mendapat lebih banyak waktu sebelum sistem file disetel hanya-baca. (Yaitu, Anda tidak memecahkan penyebab masalah.)
Pengalaman saya (beberapa tahun dengan VMware) adalah bahwa masalah ini hanya ada pada kernel Linux (kami menggunakan RHEL dan SLES) dan bukan pada server Windows. Selain itu, masalah ini terjadi pada semua jenis penyimpanan – FC, iSCSI, penyimpanan lokal. Bagi kami, komponen paling penting (dan mahal) dalam infrastruktur virtual kami adalah penyimpanan. (Sekarang kami menggunakan HP LeftHand dengan koneksi iSCSI 1 Gbps, dan tidak mengalami masalah penyimpanan sejak saat itu. Kami memilih LeftHand (dibandingkan solusi FC tradisional) karena skalabilitasnya.
Penjelasan yang mungkin adalah bahwa ada masalah perangkat keras (kegagalan sebagian disk), dan bahwa kernel me-remount sistem file root sebagai hanya-baca segera setelah masalah terdeteksi, untuk meminimalkan masalah. Cara yang lebih andal¹ untuk memeriksa opsi pemasangan saat ini adalah cat /proc/mounts (grep ' / ' /proc/mounts untuk sistem file root, abaikan rootfs / … baris yang merupakan artefak dari proses boot). Anda mungkin akan menemukan rw,errors=remount-ro itu telah berubah menjadi ro (opsi lain mungkin ditampilkan sebagai tambahan).
Log kernel mungkin berisi pesan Remounting filesystem read-only , didahului oleh kesalahan akses disk. Log biasanya berada di /var/log/kern.log , namun jika ini pada sistem file yang sekarang hanya bisa dibaca, pesan tidak akan muncul di sana, meskipun seharusnya ada kesalahan sebelumnya. Anda juga dapat melihat beberapa kesalahan kernel terbaru dengan dmesg perintah.
Selain itu, di bawah Ubuntu, tempat biasa untuk mount point (digunakan oleh antarmuka desktop) adalah di bawah /media (misalnya /media/cdrom0 ), meskipun Anda dapat menggunakan /mnt atau /mnt/cdrom jika Anda suka.
¹ mount laporan dari /etc/mtab . Jika sistem file root bersifat hanya-baca, /etc/mtab tidak dapat terus diperbarui.
Apa yang terjadi adalah, ada kegagalan daya di pusat data baru-baru ini. Sejak itu, saya belum menyentuh server saya. Setelah pusat data kami kehilangan daya, VSphere membuat sistem file Ubuntu hanya dapat dibaca hingga dimulai ulang. Saya akan mencoba memulai ulang tetapi saya tidak ingin semua pemantauan menjadi gila. Saya telah membungkam Nagios (layanan pemantauan) dan semuanya berfungsi dengan baik sekarang setelah saya memulai ulang sistem. Terima kasih atas semua masukannya. Itu sangat dihargai.