When Virtual Machines Leave Physical Traces
Virtualisation has transformed how organisations deploy and manage IT workloads. Virtual machines (VMs) run on physical servers through hypervisors like VMware ESXi, Microsoft Hyper-V, and KVM, allowing multiple isolated environments to share the same hardware. But when that physical hardware is decommissioned, the relationship between virtual and physical storage creates data destruction challenges that are often misunderstood.
Deleting a virtual machine from the hypervisor management console does not eliminate the data from the physical storage. Understanding where VM remnants persist is essential for thorough data destruction.
How Virtual Machine Data Maps to Physical Storage
A virtual machine’s storage is typically one or more virtual disk files (VMDK files in VMware, VHDX in Hyper-V, QCOW2 in KVM/QEMU) stored on the hypervisor’s physical storage. These virtual disks are essentially large files that contain the VM’s file system, operating system, applications, and data.
When a VM is deleted through the hypervisor, the virtual disk files are removed from the file system, but as with any file deletion, the underlying data on the physical storage is not immediately overwritten. The space is marked as free, but the original data persists until it is overwritten by new data.
On shared storage systems like SANs (Storage Area Networks) or NAS devices, VM data from deleted machines may persist for extended periods, especially if the storage is not heavily utilised. Even on local server storage, remnant VM data can survive until the physical sectors are reused.
Where VM Data Hides
Beyond the primary virtual disk files, VM data can persist in several other locations on the physical hardware.
Swap files and memory state: Hypervisors create swap files (.vswp in VMware) that mirror the VM’s allocated memory. When a VM is suspended or checkpointed, its entire memory state is written to disk. These files can contain anything that was in the VM’s RAM at the time, including decrypted data, session tokens, passwords in memory, and database contents.
Snapshots: VM snapshots capture the state of a virtual disk at a point in time. Snapshot files contain all changes made since the snapshot was taken, meaning they hold a partial copy of the VM’s data. Snapshots may accumulate over time, and each one represents an additional data location that must be addressed during disposal.
Templates and clones: VMs that were used as templates for creating other VMs, or that were cloned for testing or development purposes, may have copies of their data spread across multiple storage locations. The original template or source VM’s data exists independently of the clones.
Replication data: Organisations using VM replication for disaster recovery (such as VMware vSphere Replication or Hyper-V Replica) maintain copies of VM data on secondary storage, potentially at a different physical location. These replicas must be addressed alongside the primary copy.
Backup data: VM backups created by products like Veeam, Commvault, or Nakivo contain full or incremental copies of VM data. These backups may reside on dedicated backup storage, tape media, or cloud storage, all separate from the physical server being decommissioned.
Thin Provisioning Complications
Many virtualisation environments use thin provisioning, where virtual disks only consume physical storage for blocks that have actually been written. A 500GB thin-provisioned disk may only occupy 100GB of physical storage if only 100GB of data has been written.
When data is deleted within the guest operating system of a thin-provisioned VM, the guest file system marks the space as free, but the hypervisor may not immediately release the corresponding physical storage. The data remains on the physical media even though both the guest OS and the hypervisor consider the space available. This creates an additional layer of remnant data that standard VM management tools do not address.
Hypervisor-Level Data
The hypervisor itself stores data that is separate from the VMs it manages. ESXi, for example, maintains configuration files, event logs, performance data, and core dumps on its boot media or local storage. Hyper-V stores VM configuration in XML or VMCX files, and the Windows Server host maintains extensive event logs.
This hypervisor-level data can contain information about the VMs that were running on the host, including VM names, network configurations, storage paths, and resource allocation details. For organisations concerned about revealing their infrastructure layout, this data should be cleared during disposal.
Proper Disposal of Virtualisation Hosts
Disposing of physical servers that hosted virtual machines requires a layered approach.
Before physical disposal: Delete all VMs, snapshots, templates, and swap files through the hypervisor management console. Delete replication configurations and remote replicas. Verify that backup copies are handled according to your retention schedule. Unmap or disconnect shared storage LUNs from the host.
Storage sanitisation: Sanitise all local storage on the server, including boot media, local datastores, and cache drives, using NIST 800-88 compliant methods. For shared storage that was used by the decommissioned host, coordinate with your storage team to ensure that the LUNs or volumes previously assigned to the host are sanitised before being reassigned or disposed of.
Firmware and management: Clear the server’s BMC/iLO/iDRAC configuration, reset the BIOS/UEFI to factory defaults, and clear the TPM. These components may contain credentials and configuration data from the virtualisation environment.
Shared Storage Considerations
In environments where VMs run on shared storage (SAN or NAS), the physical server may not contain any VM data on its local drives. However, the shared storage volumes that hosted the VMs still contain that data and must be addressed when the storage is eventually decommissioned.
Maintain records of which storage volumes hosted which VMs, so that when the storage hardware reaches end of life, the disposal team knows what data was stored on each volume and can apply appropriate destruction methods.
The abstraction that virtualisation provides during operations becomes a complication during disposal. A systematic approach that accounts for every physical location where virtual machine data may reside is essential for thorough data destruction.