Hi WoodyZ,
Please find attached the file.
Please note that I removed extra information for other VMs to 'protect the innocent' 
Thanks
Well the primary issue I'm seeing in the support bundle is you do not has adequate free disk space to perform disk level actions of this type on the virtual hard disk due in part to the fact that you're using monolithicSparse type virtual hard disk.
-rwxrwxrwx 1 _unknown _unknown - 333118439424 Nov 14 05:08 POSServer VM_1-000001.vmdk
-rwxrwxrwx 1 _unknown _unknown - 255579652096 Nov 14 05:08 POSServer VM_1.vmdk
And on the FreeAgent GoFlex Drive you only have 71.27 GB (71,272,636,416 bytes) available! 
Also you appear not to have enough free space available on any volume attach when the support bundle was collected. So unless you can free up space you're stuck! 
Also I'd opt to use vmware-vdiskmanager to manually create a new .vmdk while pointing to POSServer VM_1-000001.vmdk to consolidate the two into a new merged disk and then swap them out.
BTW I just noticed the FreeAgent GoFlex Drive is using UFSD_NTFS_COMPR for the File System and while I occassionaly allow OS X to write directly to NTFS Volumes nonethe less it's the exception not the rule and I wouldn't do it with a running Virtual Machine and would instead use HFS+ as it is native, faster and more robust.
televisi wrote:
In relation to HFS, as I'm using this drive between MAC and PC, unfortunately, I need to use NTFS format; unless you can let me know a way to read HFS format in PC?
Do you need Read & Write HFS+ support or just Read Only? The reason I ask it there are some HFS+ Read Only drivers included in the Boot Camp Drivers. If you need Read & Write HFS+ support then MacDrive comes to mind and I believe Paragon has something for this as well.
FWIW I believe it's always best to eliminate extra layers of software when ever possible and especially when running Virtual Machines. I guest one way to choose which to use is on which Host do you use it the most or what more convenient with your work paradigm. In either case it's imperative one maintain proper on going backups especially when using VM's cross platform on different filesystems especially.
I guess, I need to move the VM into bigger free space HDD and do "vm cleanup" and put back in again?
As I said, "Also I'd opt to use vmware-vdiskmanager to manually create a new .vmdk while pointing to POSServer VM_1-000001.vmdk to consolidate the two into a new merged disk and then swap them out." this will be faster then having to move twice. Let me know if you need more help with using vmware-vdiskmanger to resolve this issue. BTW if you want to maintain the snapshot then this is not an option and you'll just need to copy it to where you'll have adequate free space and use the VMware Fusion GUI.
mandasoft wrote: This is some seriously bad advice. The vmsd file contains the information about snapshots. If you remove it, you lose your snapshots.
In the proper context it is not bad advice! It is actually quite necessary when applicable, obviously as in the case of a corrupted/truncated .vmsd file or a .vmsd file that does not contain all relevant information to the actual state of all Snapshots. This unfortunately occurs for a number of reasons and has to be dealt with when necessary and when applicable the most expeditious method is to delete the .vmsd file, take a Cold Snapshot and immediately delete it to consolidate the orphaned snapshot(s). If consolidation is not acceptable at that time then if necessary the .vmsd file can be manually edited/repaired/recreated to a functional degree from information in the vmware.log files although it may not be identical to the original before the issue occurred. The bottom line is, there is never any good excuse not to have and maintain proper regular and ongoing backups of at the very least User Data, of which I consider a Virtual Machine to be, as well as the Host system itself!
Additionally deleting the .vmsd file does not delete the Snapshots, the Snapshots are still there, they just don't show in the Snapshot Manager!
If the future don't make statements when you really don't know what your talking about!
Additionally deleting the .vmsd file does not delete the Snapshots, the Snapshots are still there, they just don't show in the Snapshot Manager!
Great. So how can we use the snapshots if you can't see them in the manager? To me it's the same as if they were gone.
mandasoft wrote:
Additionally deleting the .vmsd file does not delete the Snapshots, the Snapshots are still there, they just don't show in the Snapshot Manager!
Great. So how can we use the snapshots if you can't see them in the manager? To me it's the same as if they were gone.
Well first of all if one is doing as one is supposed to, keeping proper backups, then it really wouldn't be an issue however if the .vmsd file becomes corrupted and there is no backup to replace it then one can either... Remove the corrupted .vmsd file and then consolidate the existing snapshots by taking a snapshot and then immediately delete it, or manually create a generic working .vmsd file at which point one might be able to annotate it so it's not totally generic and continue to the the Virtual Machine with the snapshots intact.
The bottom line is removing the .vmsd file, if necessary, does not cause the loss of contents of the Virtual Machine itself however depending on how many snapshot are in play and whether or not the chain is lineal then having to manually recreate the .vmsd file could lessen the overall functionally when working with a large number of snapshots which include branching.
Keep one's system properly backed up!