VMware Workstation Pro has a documented disk setting designed for this outcome: an independent, nonpersistent virtual disk. It is more consequential than a convenient snapshot habit, but it is not a magic security boundary. Understanding what it resets, what it does not reset, and how networking changes the risk is essential before treating a disposable VM as a safe place for risky work.
What nonpersistent mode actually does
With a nonpersistent virtual disk, VMware Workstation redirects changes made to the virtual disk into a redo log while the virtual machine is in use. When the virtual machine is powered off or reset, that redo log is deleted. The next boot therefore sees the original disk baseline rather than the modified session.
In plain terms, Windows can behave normally during a session. You can install software, alter settings, create files, and accumulate the usual clutter. Those writes can be visible and usable while the VM remains on. But they are not committed back into the underlying baseline disk through the normal nonpersistent-disk workflow.
That has an important practical distinction from manually restoring a snapshot. A snapshot workflow asks the user to remember to revert the machine. Independent nonpersistent mode makes the loss of disk writes part of the disk’s configured lifecycle. It is a better fit where repeatability matters and operator mistakes are likely: a training lab, a temporary browsing machine, a software-evaluation workstation, or a clean Windows environment for reproducing a problem.
The word independent matters too. Workstation documents that an independent disk is excluded from snapshots. A user should not assume that a conventional snapshot plan will capture, restore, or provide a fallback for that disk. This is not “snapshots, but automatic”; it is a different disk-persistence model with its own trade-offs.
The useful mental model: baseline, session, discard
The safest way to plan such a VM is to divide its life into three stages:
- Build the baseline. Install Windows, apply the intended updates, install software you want available in every session, and make the privacy and usability choices you actually need.
- Enable disposable operation. Configure the relevant disk to be independent and nonpersistent only after the baseline is in the desired state.
- Treat every session as temporary. Work inside the VM knowing that its disk changes are meant to disappear when the documented discard event occurs.
This design makes baseline maintenance deliberate. If you later need a new application, a Windows update, or a changed configuration to survive, you must update the persistent baseline through a controlled maintenance process rather than expect an interactive session’s changes to remain.
It also means users need an honest answer to a common question: “Where did my file go?” If it was stored only on the nonpersistent virtual disk, it is supposed to disappear. That is a feature, not a fault. Any document, browser download, report, or test output that must survive needs an intentional export route, such as an approved destination outside the disposable disk. That route itself becomes part of the threat model: moving a file out of a test VM can also move an unsafe file into a place where it persists.
Power state is not a minor detail
Vendor documentation ties discard behavior to powering off or resetting the VM. That makes shutdown handling central to the design, not an afterthought.
A normal Windows restart initiated inside a guest is not conceptually the same operation as powering off or resetting the virtual machine from the hypervisor. Modern Windows Sandbox documentation illustrates why this distinction matters: Sandbox deletes its state when closed, but Windows 11 version 22H2 and later can preserve data across restarts that are initiated within the Sandbox. “Restart” and “close the environment” are separate lifecycle events.
For a Workstation nonpersistent disk, the documented guarantee is specifically about a VM power-off or reset. Do not generalize an anecdote about a particular guest’s Start-menu shutdown or restart into a universal rule across Workstation releases, VM settings, and host configurations. If a workflow depends on exact behavior, validate it on that VM with harmless test files before using it for sensitive tasks.
A sensible validation routine is straightforward:
- Create a clearly named file inside the guest.
- Change an identifiable Windows setting or install a small, nonessential test application.
- Use the exact power-down procedure intended for normal operation.
- Start the VM again and verify that the expected baseline is back.
- Repeat after Workstation, VMware Tools, Windows, or VM configuration changes.
This does not prove that a VM is secure against malware, and it does not prove that every virtual component is untouched. It does establish whether the disk-reset behavior you rely on is operating as expected in your own environment.
A disposable disk is not a complete privacy solution
Nonpersistent mode primarily addresses writes to the configured virtual disk. It should not be mistaken for proof that no trace exists elsewhere.
The host still runs the hypervisor. It may retain its own logs, crash artifacts, backups, monitoring records, or other data depending on the host setup. Files copied to a mapped folder, downloaded to a host location, or deliberately exported from the guest are no longer confined to the disposable virtual disk. Accounts used inside the VM can also leave records with the online services they contact; discarding local guest storage does not erase activity from remote systems.
There is a usability-versus-isolation tension here. Shared clipboard support, drag and drop, shared folders, USB pass-through, and similar integration features can make a test VM pleasant to use. They also create routes between the guest and the host. For a VM intended merely to install trustworthy software temporarily, that may be acceptable. For one that will open untrusted files or execute unknown code, minimizing such integrations is the more cautious approach.
The practical question is not whether a feature is always good or bad. It is whether the convenience it brings is worth the path it creates for data to leave the VM or for guest activity to affect the host environment.
Networking determines much of the exposure
A resettable Windows disk does not automatically mean a network-isolated machine. Workstation’s network mode has a direct impact on which systems can reach the guest and what the guest can reach.
NAT networking is often a useful compromise for ordinary disposable browsing or installer testing. The VM can access an external network using the host’s IP address while participating in a private network shared with the host and other NAT VMs. Systems on the physical LAN cannot initiate a connection to the NAT VM unless port forwarding is configured. That makes NAT materially different from simply placing the guest directly onto the same LAN as the host.
However, NAT still provides outbound Internet access. A malicious program inside the guest may be able to contact external infrastructure, download additional components, or transmit information available to it. NAT reduces unsolicited inbound exposure from the physical network; it does not make risky software harmless.
Bridged networking is a different proposition. It places the guest in a more direct relationship with the physical network, which can be required for some legitimate lab tasks but may increase visibility and exposure on a home or work LAN. It should be chosen because the test needs it, not because it is the default someone happens to understand.
Host-only networking is the more suitable documented topology for an isolated test environment. It is a better starting point when the VM must communicate only with the host or other deliberately connected local VMs and does not need Internet access. For static analysis of an unknown installer or a document, fully disconnecting the guest network may be more appropriate still.
Before enabling networking, define the task. Does the application need to activate, download dependencies, or reach a test server? NAT may be justified. Does it need no network at all? Disable it. Is the goal to observe network behavior without exposing a production LAN? Build a controlled lab rather than using bridged mode casually.
Why this is not a malware containment guarantee
Automatic disk rollback can remove many ordinary consequences of a compromised guest, including installed payloads, altered registry entries, and local files that exist only within the virtual disk session. That is valuable. But it cannot be presented as an invulnerable barrier between hostile guest code and the host.
Broadcom has disclosed critical VMware Workstation vulnerabilities in which a guest administrator could execute code on the host. The affected classes included virtual networking and communication or storage components such as VMXNET3, VMCI, and PVSCSI. The precise applicability of any vulnerability depends on versions, patch levels, and enabled hardware, but the broad lesson is unambiguous: a guest can sometimes be more than a contained guest.
For that reason, a nonpersistent VM is appropriate for reducing persistence and making routine testing repeatable, not for confidently executing highly dangerous malware on a personal workstation. Patch Workstation and its relevant components promptly. Keep the host operating system protected and current. Avoid unnecessary virtual devices and guest-host integrations. Do not use personal accounts, confidential files, or privileged credentials in an environment meant for untrusted code.
Where the stakes are high, stronger separation may be necessary: a dedicated non-sensitive host, a purpose-built lab, restricted networking, and procedures designed for the specific threat. The right level of isolation depends on the consequences if the host is compromised, not simply on whether the guest disk resets cleanly.
Windows Sandbox and VirtualBox: similar goals, different lifecycle rules
Windows Sandbox is attractive when the goal is immediate, short-lived Windows isolation without building and maintaining a full personal VM image. Closing Sandbox deletes its software, files, and state, and its next launch begins fresh. Software installed interactively during one Sandbox session will therefore not be there after it is closed.
That does not mean Sandbox must begin as a wholly manual blank slate. Its configuration system can control elements such as networking and mapped folders and can invoke a command at logon. That can support a repeatable initialization routine. But automation at startup is different from retaining the applications and changes made during a prior closed session.
There is another lifecycle nuance: on supported Windows 11 releases beginning with version 22H2, Sandbox data can persist through a restart initiated within Sandbox. Users should therefore distinguish a restart from closing the Sandbox when judging what is disposable.
VirtualBox offers a related concept through immutable disk images. Its documented behavior is that writes are remembered temporarily while the VM runs and are lost at the next power-on. It also documents exceptions involving saved-state VMs and current online snapshots. The comparison reinforces the underlying point: disposable virtual-machine behavior is governed by storage mode and power-state details, not by a generic promise that all VM activity always vanishes.
A disciplined way to use a resettable Windows VM
The best disposable VM is intentionally boring. Keep a patched, minimal baseline. Install only the tools needed in every session. Use NAT only where external connectivity is genuinely required, and choose host-only or no network for more isolated tasks. Avoid host sharing features when opening unknown material. Export only the artifacts you have consciously decided to keep.
Finally, test the reset behavior after meaningful changes to your Windows guest, hypervisor, VM configuration, or operational procedure. The goal is not a dramatic claim that the machine “forgets everything.” The goal is a verified, repeatable workflow in which the configured virtual disk reliably returns to a baseline at the documented lifecycle point—while you remain clear-eyed about the data paths and security risks that disk rollback alone cannot remove.