Out of space on a datastore

[kkbass]

ESXi 5.1.0, 1065491 (single server)

Guest - a linux server, (currently powered off)

Resides on its own datastore “datastore2_vmfs5” which is 558.25GB, it has 2.40GB free

vmdk is a single thin provisioned 450GB disk which looks to be 450GB....

There is a snapshot that is about 105GB

Datastore1 is used for other production guests, only has ~200GB free, so not a candidate for storage vmotion (besides, it is only 550GB so empty it would still not be a candidate)

No additional space in the Dell T110 II or on the raid controller to add additional disks

AFAIK to delete the snapshot you have to have the space of the snapshot free + a little additional? In this case that means there is no way to delete this snapshot unless we add another datastore (perhaps via iSCSI/NFS NAS?), move it over to that ~800GB datastore & then run a snapshot delete? Is there anything that can be done with it as it is now (guessing not)?

Thanks for the assist!

[a_p_]

AFAIK to delete the snapshot you have to have the space of the snapshot free + a little additional?

The disk space required for deleting a snapshot of a thin provisioned virtual disk (i.e. merging the snapshot's delta data into the base .vmdk file) could be anything between zero, and the size of the snapshot .vmdk file, or the provisioned size minus the used disk space, whichever is lower. If the thin provisioned virtual disk has already been inflated to its maximum size, you shouldn't need additional disk space if you delete the snapshot while the VM is powered off.

With the file sizes you mentioned it would be interesting to get the exact numbers. Please run ls -lisa in the VM's folder from the command line, and post the output.

André

[kkbass]

/vmfs/volumes/52ab5660-b536b40c-2287-bc305bd94b38/servername # ls -lisa

79721860      8 drwxr-xr-x    1 root     root          3500 Jul 21 21:46 .

      4   1024 drwxr-xr-t    1 root     root          1260 Jul 21 20:31 ..

369128836 109970432 -rw-------    1 root     root     112609599488 Jul 21 20:33 192.168.2.15 servername-000002-delta.vmdk

373323140      0 -rw-------    1 root     root           342 Jul 21 20:32 192.168.2.15 servername-000002.vmdk

8418692 471859200 -rw-------    1 root     root     483183820800 Jul 21 21:46 192.168.2.15 servername-flat.vmdk

352351620   1024 -rw-------    1 root     root          8684 Jul 21 20:33 192.168.2.15 servername.nvram

188773764      0 -rw-------    1 root     root           534 Jul 21 21:46 192.168.2.15 servername.vmdk

92304772      0 -rw-r--r--    1 root     root           422 Feb 13 23:28 192.168.2.15 servername.vmsd

360740228      8 -rwx------    1 root     root          3071 Jul 21 20:32 192.168.2.15 servername.vmx

398488964      0 -rw-------    1 root     root             0 May 10 15:11 192.168.2.15 servername.vmx.lck

356545924      8 -rw-------    1 root     root          3333 Feb 13 23:28 192.168.2.15 servername.vmxf

507540868      8 -rwx------    1 root     root          3071 Jul 21 20:32 192.168.2.15 servername.vmx~

415266180   4096 -rw-------    1 root     root       3470683 Jul  6 15:48 vmmcores-1.gz

436237700   2048 -rw-------    1 root     root       1821176 Jul  6 15:50 vmmcores-2.gz

457209220   2048 -rw-------    1 root     root       1799583 Jul  6 16:57 vmmcores-3.gz

478180740   4096 -rw-------    1 root     root       3294652 Jul 11 15:17 vmmcores-4.gz

499152260   2048 -rw-------    1 root     root       1825984 Jul 11 15:19 vmmcores-5.gz

520123780   2048 -rw-------    1 root     root       1816130 Jul 21 20:33 vmmcores.gz

390100356   1024 -rw-r--r--    1 root     root        144526 May 10 15:10 vmware-15.log

406877572   1024 -rw-r--r--    1 root     root        106766 Jul  6 15:48 vmware-16.log

427849092   1024 -rw-r--r--    1 root     root        104896 Jul  6 15:50 vmware-17.log

448820612   1024 -rw-r--r--    1 root     root        103902 Jul  6 16:57 vmware-18.log

469792132   1024 -rw-r--r--    1 root     root        108245 Jul 11 15:17 vmware-19.log

490763652   1024 -rw-r--r--    1 root     root        103926 Jul 11 15:19 vmware-20.log

511735172   1024 -rw-r--r--    1 root     root        104440 Jul 21 20:33 vmware.log

[a_p_ · Accepted solution]

According to the size in Bytes and the usage in kB, the -flat.vmdk file has already reached its provisioned size of 450GB, so it shouldn't grow anymore if you delete the snapshot. Did you already try delete the snapshot from the Snapshot Manager? Does it complain about free disk space, or something else?

André

[kkbass]

I have not actually tried it yet, with only ~2.4GB free I didn't want to try it in fear of it failing or other potential horrors. From the sounds of it there shouldn't be in this case. I am not able to delete the snapshot right now but I should be able to try to do it later today. I'll report (hopefully good news) what happens.

Thanks!

[a_p_]

... I didn't want to try it in fear of it failing or other potential horrors ...

That's why one should always have a good backup in place 😉

André

[kkbass]

André,

This is that one client that no matter how much you try to convince them, they don't do backups.....

That said, you are correct, it allowed me to delete the snapshot & it now shows ~100GB of free space on that datastore. The guest is running again and all seems to be AOK now. Perhaps this scare will convince him to at least get veeam/trilead/something to do backups....