I was trying to gather logs from three hosts for a SR, but when I kicked off the export of the system logs from the C# client, it would take forever. I wasn’t sure what was wrong, so I found this kb that indicated that you could download the logs directly via http.
When I downloaded the files via that method, it took forever and seemed to stop around 11 or 12 GB EACH.
That’s just plain crazy, so I copied the tgz to a linux box and extracted it (tar xzf <filename>)
In another ssh session changed to the directory that was created and did a du -sh *
The tar command was still running to extract and the vmfs file was already in the gigs (32 gigs shown here).
I went into vmfs/volumes and ran another du -sh
At that point I saw that a specific datastore was using all of the space. Going into that datastore folder I saw that .dvsdata was using the space, which is crazy because that folder should only be small files. BUT, there was a VM folder in there! (the path was [datastore]:/.dvsdata/vm).
I checked at the root of the datastore and there was a similarly named folder, so I wasn’t sure which one the VM was actually using. The folder under the root was later timestamps, so that was a good indicated.
To know for sure I followed this kb to query the SQL database to find the full vmfs path to the vmx file that was in use.
The sql query told me that the vmx’s vm folder was at the ROOT of the datastore, so the .dvsdata copy was just a copy (confirming my thoughts).
I deleted the folder and tried to export the logs again. Oddly enough, from the C# client, it still was hanging but if I used the http method the exports completed and each support bundle was only around 40MB!