How to disable swap files in ESXi?

We are running a few Solaris / Linux VMs on ESXi that contain very sensitive encrypted data that eventually get decrypted as required in memory.

Everything is fine, except for the ESXi swap files which could potentially store some of the decrypted data, the cherry on top of the cake being that these files won't get removed in case of a host crash.

Is there any way to disable these files completely?

We already tried reserving the whole allocated RAM to the VMs on a per VM basis, but the files still get created.

What would it take to have ESXi swapping completely disabled for the entire host or only for some VMs?

Solution 1:

This is an interesting question. I've never thought about data security at the hypervisor level... usually security policies and hardening revolve around OS-specific tasks (limiting daemons, ports, disabling core files, filesystem mount options, etc.)

But after some quick research (and running strings against active VMWare .vswp files) shows that it's definitely possible to extract data from .vswp files residing on a VMWare datastore. This link helps explain the lifecycle of such files.

In your case, I think your approach is going to be determined security policy and requirements. In my experience in finance and dealing with audits, I think that an accepted approach would be to limit/secure access to the host server. Recall that by default, your ESXi host does not have SSH or console access enabled. Enabling those features throws an event/alert in vCenter that needs to be manually overridden, so the assumption is that auditing access is the best way to control access to this information.

If there are concerns about who may have access to the server, there may not be a technical solution to an administrative problem. I'll check some other sources to see if there's a way to limit use of .vswp files, though.

--edit--

You can reserve all of the guest RAM. You don't specify which version of VMWare you're using, but in my 5.1 installation, there's an option to Reserve all guest memory. Enabling this option creates a zero-length .vswp file, rather than one equal to the size of RAM allocated to the virtual machine. Pay no attention to the vmx-.vswp file. That's new to ESXi 5.x, and it's not related to the guest's operating system memory pressure (it's for VMX process heap, guest peripherals and management agents). In addition, the vmx-.vswp files can be disabled by setting sched.swap.vmxSwapEnabled to FALSE.

I think this will give you what you're asking for.

No memory reservation (default):

root@deore:/volumes/vol2/staging/Test_Bed# ls -al | grep vswp
-rw------- 1 nfs  nobody  3221225472 Dec 23 13:31 Test_Bed-ad493981.vswp
-rw------- 1 nfs  nobody   115343360 Dec 23 13:31 vmx-Test_Bed-2907257217-1.vswp

With memory reservation locked-in:

root@deore:/volumes/vol2/staging/Test_Bed# ls -al | grep vswp
-rw------- 1 nfs  nobody           0 Dec 23 13:38 Test_Bed-ad493981.vswp
-rw------- 1 nfs  nobody   115343360 Dec 23 13:38 vmx-Test_Bed-2907257217-1.vswp

Edit 20210711: Wayback Machine or Archive Today archived versions of the above links (of which some already were gone):

• quick research
• link
• manually overridden (note VMware KB 2007922 has been superseded by VMware KB 2003637)
• That's new to ESXi 5.x
• guest's operating system memory pressure

Solution 2:

It looks like your trying to solve the problem wrong. Trying to stop the machine swapping is no guarantee that sensitive data will not get on disk. What about core dumps etc ? Once you have a writable device that has been in a system that contains sensitive data it should not be considered 'clean' and should be destroyed when it's use is over.

If your data is that sensitive then you should physically secure the system. Everyone who needs access the system should be vetted appropriately and specifically authorized to do so. Their activities need to be authorized,logged and supervised etc.

The scenario you describe is easily managed. You should have procedures for destroying the devices that contain sensitive data commensurate with the sensitivity of the data. You simply do not let the device out of your secure environment unless it is signed for by an appropriate authority at which point it ceases to be your problem.