Hi Lv, glad you got it sorted. Apologies - I missed your previous post - but DB servers are where you typically see these problems first since they tend to be I/O intensive. You are right in that shared storage allows for live migration between hypervisor hosts without the underlying disks migrating, however all running VMs will consume bandwidth on your backend network - and ultimately if there isn't enough network bandwidth or speed between the hypervisor and the NFS host your VMs will suffer. Typically Linux VMs deal with this better than Windows VMs, which tend to have a shorter disk timeout period before the disk goes read-only.
For reference have a look at the following KB articles - these are from VMware but the concept applies whatever hypervisor you are using: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1014 https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009465 Regards, Dag Sonstebo On 19/05/2016, 09:37, "Lv Haijiao" <luhaij...@gmail.com> wrote: >The issue seems gone while we migrate a SSD+HDD mixed storage which has >much better I/O performance than previous NFS one. > >Thanks Dag, your advice is helpful. > >2016-05-05 21:55 GMT+08:00 Lv Haijiao <luhaij...@gmail.com>: > >> Hi, Dag >> >> Thanks for your hint ! >> >> We don't have chance to reproduce this on our production platform, but we >> notice most of these VMs hitting this issue are DB server. >> >> Even that, live migration is supposed to consume less bandwidth as >> majority of VM data is still on the shared storage, need no replication, >> except the data in memory. >> >> Is it right ? :-) >> >> 2016-05-05 18:04 GMT+08:00 Lv Haijiao <luhaij...@gmail.com>: >> >>> Hi, >>> >>> Here's our environment, >>> >>> >>> - ACS 4.7.1 >>> - Ubuntu 14.04 KVM >>> - NFS as shared, primary storage >>> >>> >>> While we do a couple of VMs live migration in sequence from physical >>> server A to B, the file system of some VMs goes into 'ready only' status >>> unless we reboot the VM again. >>> >>> No clue why we only hit this issue on some of VMs. >>> >>> Any advice or experience sharing is most appreciated ! >>> >> >> dag.sonst...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
