In addition to the two workarounds I provided above, I've also digged a little bit further and found that the issue doesn't happen only when the machine is shutdown, but when vmware tools exit, which also happens during shut down (actually right, after the user request the shutdown).
Continuing the investigation, I've isolated the VMCI driver in VMWare tools as the culprit of triggering the issue (by uninstalling this specific driver). Later, I've found a better and less radical approach that is to disable the vmci virtual hardware instead of uninstalling its driver from VMWare tools.
The VMCI virtual hardware enables two features: 1) allows two Virtual machines to communicate to each other circumventing the network layer; 2) allows the use of shared folders (mount host files in guest os). I actually use none of them (I use actual samba exports in a physical server to share files instead). If this is also your case not to need any of these features, this third workaround is for you. The procedure is very simple: With the virtual machine stopped, first make a backup copy of your .vmx file, then edit it and change the line containing:
vmci0.present = "TRUE"
to
vmci0.present = "FALSE"
OBS: It is important to back the .vmx file up because after the first boot with the vmci disabled, other options will also be changed automatically (like the pci slot of the vmci hardware being changed to -1, so the backup will allow you to re-enable it in the future in case you want.
In summary there are currently 3 workarounds available:
1) Use file system other than ext4 for holding the virtual machine files (like btrfs or xfs)
trade off: requires a separate partition just for the VM files (or a reformatting of the current one);
2) bindfs (fuse) mount the directory containing the virtual machine files on top of itself before turning on the virtual machine
trade off: a small hit in performance;
3) disable the vmci virtual hardware in the .vmx file
trade off: cannot use shared folders