VMDK Ran Out Of Space - All Other VMDK Drive Shares Become Inaccessible - Why?

[admin]

Hi All,

We have been migrating from in-guest iscsi attached volumes to vmdk's. We have recently experienced a problem where one volume on a server that has five additional volumes, ran out space. This caused the other five volumes and their shares to become inaccessible, until the alert in vcenter stating the vmdk file that had run out of space, was increased and acknowledged.

I am trying to understand why one vmdk volume running out of space would have caused these additional volumes, that are each separate vmdk's by the way, to have become inaccessible until such time as that one volume that was out of space was expanded, and the alert was acknowledged. This is behavior unlike anything I have experienced with using in-guest iscsi connections - in which case it is expected that if one volume runs out of space it does NOT impact any other volumes on the same server.

I am hoping someone is able to provide some additional clarification around this behavior.

Thank you

[a_p_]

Are you working with thin provisioned virtual disks? In case a thin provisioned virtual disks cannot be increased due to disk space issues on the datastore, ESXi will pause the VM to avoid guest OS issues. In such a case, the guest OS - which is not aware that it runs on a thin provisioned virtual disk - would not be able to write its data although it can see available disk space.

André

[admin]

Hi Andre,

We are using thin provisioning at both the ESX and SAN level. I think you are right in that this must have been what occurred. Obviously thick provisioning the average volume really isn't an effective approach, I guess over-provisioning to the point of being positive the volume.

However I am surprised that the default action would be to pause the OS if the volumes are not even on the OS drive. This seems counter-productive although I understand why that might happen. I guess maybe it makes sense not to thin-provision data volumes on VMDK but rely on SAN thin-provisioning for those same volumes instead.