On 25/03/14 12:58, Craig Sanders wrote: > On Tue, Mar 25, 2014 at 12:27:04PM +1100, Daniel Jitnah wrote: >> Is it fair to assume that the problem was caused by something that the >> cloud provider has done? Or could it be something on server OS side? > > it's probably not your VM but it's more likely to be a fault or outage > than something the cloud provider has deliberately done. breaking > running VMs is something that most providers would try to avoid. > >> What can cause this? > > most likely the VM's disk image became unavailable temporarily - > possibly due to network problems, or a server being rebooted. > > it's hard to be more specific than that because there are countless > ways of setting up a cloud server. > >> (I am thinking the virtual disk hosting the VM has become readonly >> somehow, but how? ) > > assuming you are using ext2/3/4 on your VM's disk - the mount option > "errors=remount-ro" says to remount the fs as read-only if the kernel > has any errors accessing the filesystem (e.g. if a disk is dead/dying or > the cable is loose etc). > > debian at least, and probably other distros, routinely adds > "errors=remount-ro" to /etc/fstab for ext filesystems when you build the > system.
If it is not set in fstab, look at the superblock with tune2fs -l <device> and see what is set for "Errors behavior:" _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
