Přestože se jedná o poměrně starou otázku, odpověď je stále stejná. Máte virtuální počítač (běžící na fyzickém hostiteli) a nějaký druh úložiště (buď sdílené úložiště – FC SAN, úložiště iSCSI, sdílené úložiště NFS – nebo místní úložiště).
S virtualizací se mnoho virtuálních strojů pokouší přistupovat ke stejným fyzickým prostředkům současně. Kvůli fyzickým omezením (počet operací čtení/zápis – IOPS; propustnost; latence) může nastat problém uspokojit všechny požadavky na úložiště všech fyzických strojů současně. Co se obvykle stane:v operačních systémech vašich virtuálních strojů uvidíte „opakování SCSI“ a neúspěšné operace SCSI. Pokud za určité časové období dostanete příliš mnoho chyb/opakování, jádro nastaví připojené souborové systémy pouze pro čtení, aby se zabránilo poškození souborového systému.
Abych to zkrátil:Vaše fyzické úložiště není dostatečně „výkonné“. K systému úložiště přistupuje příliš mnoho procesů (virtuálních strojů) současně, vaše virtuální stroje nedostávají odpověď z úložiště dostatečně rychle a souborový systém je pouze pro čtení.
Není příliš mnoho věcí, které můžete dělat. Samozřejmým řešením je lepší/další úložiště. Můžete také upravit parametry pro časové limity SCSI v jádře Linuxu. Podrobnosti jsou popsány např. v:
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
To však pouze „odloží“ vaše problémy, protože jádro dostane pouze více času, než bude souborový systém nastaven pouze pro čtení. (Tj. nevyřešíte příčinu problému.)
Moje zkušenost (několik let s VMware) je, že tento problém existuje pouze s linuxovými jádry (používáme RHEL a SLES) a ne se servery Windows. Tento problém se také vyskytuje na všech typech úložišť – FC, iSCSI, místní úložiště. Pro nás je nejkritičtější (a nejdražší) součástí naší virtuální infrastruktury úložiště. (Nyní používáme HP LeftHand s připojením iSCSI o rychlosti 1 Gb/s a od té doby jsme neměli žádné problémy s úložištěm. Zvolili jsme LeftHand (před tradičními FC řešeními) pro jeho škálovatelnost.
Pravděpodobným vysvětlením je, že došlo k hardwarovému problému (částečné selhání disku) a že jádro znovu připojilo kořenový souborový systém jako pouze pro čtení, jakmile problém zjistilo, aby se problém minimalizoval. Spolehlivější¹ způsob, jak zkontrolovat aktuální možnosti připojení, je cat /proc/mounts (grep ' / ' /proc/mounts pro kořenový souborový systém ignorujte rootfs / … řádek, který je artefaktem zaváděcího procesu). Pravděpodobně zjistíte, že rw,errors=remount-ro se změnil na ro (dodatečně se mohou zobrazit další možnosti).
Protokoly jádra pravděpodobně obsahují zprávu Remounting filesystem read-only , kterým předcházejí chyby přístupu na disk. Protokoly normálně žijí v /var/log/kern.log pokud je to však na souborovém systému, který je nyní pouze pro čtení, zpráva se tam nezobrazí, ačkoli předchozí chyby by se měly objevit. Můžete také vidět několik posledních chyb jádra s dmesg příkaz.
Mimochodem, pod Ubuntu je obvyklé místo pro přípojné body (používané rozhraním desktopu) pod /media (např. /media/cdrom0 ), i když můžete použít /mnt nebo /mnt/cdrom pokud chcete.
¹ mount zprávy z /etc/mtab . Pokud je kořenový souborový systém pouze pro čtení, /etc/mtab nelze udržovat aktuální.
Stalo se to, že nedávno došlo k výpadku napájení v datovém centru. Od té doby jsem se svého serveru nedotkl. Jakmile naše datové centrum ztratí napájení, VSphere způsobí, že souborový systém Ubuntu bude pouze pro čtení, dokud nebude restartován. Zkusil bych restartovat, ale nechtěl jsem, aby se všechno sledování zbláznilo. Umlčel jsem Nagios (monitorovací službu) a nyní, když jsem restartoval systém, vše funguje dobře. Díky za všechny příspěvky. Velmi si toho vážíme.