Hi CollinChaffin,
I'm sorry that we appear to be failing to meet your expectations, while also being somewhat honored that you hold us to such high standards. I appreciate you are frustrated, but please do remember that the VMware engineers and volunteers here in the forum are all humans, and your tone of writing here would make it much less likely that anyone will assist. I'll go against my gut instinct and try to assist anyway; In return, I'd appreciate if you could put your emotions aside and work with us on understanding the problem.
Please also note that Ubuntu 17.10 is very early pre-release software, and as such it is nowhere near being qualified for use with VMware Workstation. Ubuntu 17.10 may itself contain severe data-loss bugs at this stage of its development cycle, which is one of the reasons we don't try to claim compatibility or interoperability at this stage... We would spend far too much time chasing bugs that aren't ours.
That doesn't explain the Kali situation, though... My first thought is that we have many (MANY) users running Kali inside VMware Workstation and Fusion -- it's a very popular combination for security work -- and this is the first I've heard of this happening.
My next thought is ... hmmm... this reminds me somewhat of a Linux kernel bug for which we posted a fix for back in 2014: Linux-Kernel Archive: [PATCH] Do not silently discard WRITE_SAME requests
That was a bug in the Linux kernel's block layer which just happened to only have an effect when writing to VMware's emulated SCSI disks. It was not due to any defect in our emulation (despite the incorrect comments to the contrary in that discussion thread)... it was caused by a set of perfectly-valid characteristics that our emulated SCSI disks happened to have and that the Linux kernel handled improperly. SATA disks were unaffected, as were other virtualization platforms and probably the vast majority of physical systems with SCSI disks.
I've looked into the latest Linux kernel sources, and it seems that the patch that we supplied was never fully accepted, despite all the effort we put into root-causing it and providing the patch. Parts of the problem were fixed, but seemingly not all... I can't quite tell if subsequent patches papered over the gaps we identified in the accepted fix. I think it should be "safe" because the particular feature in question (the WRITE_SAME command) was masked off for VMware LSI Logic SCSI/SAS controllers, but part of the underlying defect -- as far as I can tell -- still exists in part.
So far, that defect was only known to affect disks using LVM, but these things can always change as software evolves... The "worse with LVM, doesn't happen with SATA" factor reported in the Kali bug certainly sounds eerily similar.
Anyway, I've attempted to reproduce the problem with Kali here on my machine, and I have not yet succeeded. I'm testing with http://kali.mirror.garr.it/mirrors/kali-images/kali-2017.1/kali-linux-light-2017.1-amd64.iso , installing into a VM running on VMware-Workstation-Full-12.5.6-5528349.x86_64.bundle installed on a Debian 8.8 host running kernel 3.16.0-4-amd64. Kali bug 4017 (in the link you supplied) also seems to suggest that the problem is not reliably reproducible -- at least not on a host system other than the reporter's machine.
Here are my steps which failed to reproduce the problem:
- In the Workstation UI, choose File > New Virtual Machine, Typical, [Next], Choose Use ISO image, choose kali-linux-light-2017.1-amd64.iso, [Next].
- For Guest Operating System, choose 2. Linux, Version: Debian 8.x 64-bit, [Next].
- Virtual machine name: (whatever name you want...) [Next]
- Disk Size: Use defaults (20 GB, split into multiple files) [Next]
- At Ready to Create Virtual Machine, choose Customize hardware; Configure the virtual Ethernet adapter to NOT connect at power-on, [Close].
- Back at the Ready to Create Virtual Machine screen, choose [Finish]
- Choose [Start up this guest operating system].
- At Kali bootloader screen, down-arrow a few times to choose "Graphical install", and press Enter.
- Select a language: Use defaults (English/English). Choose [Continue].
- Select your location: Use default (United States). Choose [Continue].
- Configure the keyboard: Use default (American English). Choose [Continue]
- Configure the network: Network autoconfiguration failed. [Continue]
- Choose "Do not configure the network at this time". [Continue]
- Hostname: Use default ("kali"). Choose [Continue].
- Set up users and passwords. Root password: blank. [Continue].
- Full name for the new user: test. [Continue]
- Username: Default "test". [Continue].
- Password: "hello", re-enter to verify, "hello". [Continue].
- Configure the clock. Default "Eastern". [Continue].
- Partition disks: Default "Guided - use entire disk". [Continue]. (Alternatively, to test with LVM, choose "Guided - use entire disk and set up LVM", and there'll be two more screens below for partitioning the LVM device.)
- Select disk to partition: "SCSI1 (0,0,0) (sda) - 21.5 GB VMware, VMware Virtual S". [Continue].
- Partitioning scheme: Default "All files in one partition (recommended for new users)". [Continue].
- Partition disks: (This is an overview of your currently configured partitions...) Default "Finish partitioning and write changes to disk". [Continue].
- "If you continue, the changes listed below will be written to the disks." ... "Write the changes to disks?" Choose (X) Yes, then [Continue].
- Wait for "Install the system" to complete.
- Configure the package manager. "Use a network mirror?". Use default (No). Choose [Continue].
- Install the GRUB boot loader on a hard disk. "Install the GRUB boot loader to the master boot record?" Default (Yes). [Continue].
- Device for boot loader installation: Choose "/dev/sda". [Continue].
- Installation complete. [Continue].
- Graphical Kali login screen having blue background with subtle swirliness: Enter "test", password "hello". Choose [Log In]
- Dialog box: "Panel", "Welcome to the first start of the panel". Choose [Use default config].
- Top-right menu, labelled "test": Choose "Shut Down". Dialog box: [Shut Down] button.
- In the Workstation UI, choose [Start up this guest operating system]. Repeat the last few steps several times (and/or choose Restart instead of Shut Down) to ensure that everything works cleanly.
I tried quite a few variations on that process, including those given in Kali bug 4017 (choosing Custom instead of Typical, then choosing 2 GB of RAM and a 60 GByte virtual disk), including using LVM or not using LVM, etc., etc., but always using the LSI Logic SCSI controller for the virtual hard disks. Everything I've tried has worked 100% correctly, with no reports of disk corruption.
At this point, it'd be super helpful if you could do two or three things:
- Provide a copy of the vmware.log and other vmware-*.log files from a fresh virtual machine, gathered immediately after the first evidence of the disk corruption (with either Ubuntu 17.10 or Kali as a guest OS), and
- Try following the above steps exactly using Kali 2017.1 amd64 (light or non-light version) and see if the problem reproduces there, and/or
- Provide exact steps (to a similar level of detail to what I've given above) that you are using to reproduce the problem here, so that I can do precisely the same here.
I've scheduled a download of a nightly build of Ubuntu 17.10 amd64 from http://cdimage.ubuntu.com/daily-live/20170527/artful-desktop-amd64.iso, so hopefully I can test with that image tomorrow once my slow slow ADSL obliges... Hopefully that will be close enough to whatever disc image you are using there. With your help, we'll hopefully be able to figure out what's causing these problems (and indeed figure out if the Ubuntu 17.10 problem is the same as the Kali problem, and if either of those are related to the WRITE_SAME issue from 2014).
(P.S. This problem is unrelated to that reported earlier in this thread; mfelker is trying to run Workstation 12.5.6 on Ubuntu 17.10 and it's failing to launch, while you're trying to run Ubuntu 17.10 inside VMware Workstation 12.5.6 and ending up with corrupted filesystems in the guest. It's a totally different and likely unrelated problem space. I'll break this branch of the discussion out into its own thread... I hope that's OK with you!)
Thanks,
--
Darius