Independent Nonpersistent Disk Issue

[zephyrus1980]

Hi,

I have noticed that changes made on independent nonpersistent disk are discarded after a reboot. But as per documentation, it will be only discarded when the virtual machine is shutdown.

Version: 16.2.0 build-18760230

Host version: Windows 10 Enterprise, 64-bit (Build 22483.1011) 10.0.22483

Guest OS: Centos Stream 8

Thank you.

[Kevin24]

+1, the same problem. Version: 16.2.1 build-18811642

[Photubias]

+1 same bug here, really a problem when trying to install software the tries to reboot

Win 10 Enterprise 21H1 19043.1348

Guest OS does not matter (tested with Windows & Debian Guest OS'es)

VMware Workstation 16.2.1 build-18811642

[wardles]

Do we know if anyone has received any info about this?

Also having the same problem, 16.2.2 build 19200509

Really need this resolved.

[Sam2555]

Reproduce on 16.2.3 build-19376536.

[continuum]

Independant nonpersistent vmdks used to create a random-named redo-log file.
Are this files still created ?
When do the redo-logs disappear ?
Sorry - cant test this myself as I dont have hardware that would run WS 16 - but I would consider this a serious bug - worth to make some noise about it.
Please provide vmware.log files that illustrate the issue.

Ulli

[a_p_]

It's a known bug, which also existed in recent ESXi versions. In ESXi this has been fixed with one of the latest patches.

André

[Photubias]

Hi,

Indeed, this is a pretty big bug. I'm a professor at a University and about 100 of our students have reported the problem to us.

I have a Debian 11 on VMware Workstation 16.2.3 b19376536 on Windows 11 (but that shouldn't matter).

The scenario is launching a proper Debian 11 VM, logging in and running `mkdir /home/tempfolder` then running `reboot`.
After reboot, the folder is removed.

At first boot "Debian11.vmdk.REDO_a12484" is created, but then after typing `reboot` (which should be a normal Guest Restart), the REDO is discarded and replaced by Debian11.vmdk.REDO_a00236.

I attached the vmware.log. It seems the problem arises at line 1461 where Workstation "thinks" the virtual machine requests a hard reset, which is not the case.

Thanks in advance for looking at this.

[AlessandroDN]

Hi,

thanks for reporting I'm experiencing the same issue in latest version of Fusion (12.2.3). And this is somehow critical for me as well. I have some automation based on this behavior which is n

Is there are any ack/update from VMware on this?