I am running a single Windows XP guest instance on a Ubuntu Desktop Linux (8.04) host via VMWare Server (2.0.0). When I initially start up the guest, it puts roughly 1.2GB of memory resident for the process (observing RES column for vmware-vmx in top). After the vm runs for as little as 15 or 20 minutes, the resident memory goes down to ~80MB and the rest goes to swap. For reference, VIRT = 1746m, RES = 79m, SHR = 63m. I have allocated 1GB of memory for the XP guest but almost all of that is now in swap.

As you might expect, the performance of the VM gets quite sluggish at this point. Doing almost anything causes thrashing. To get performance back to an acceptable level, the VM has to be shut down and then started back up. A regular restart is not a good idea because lots of things have to be swapped back in during the startup process.

So, my question is how can I keep my Linux host from pushing all this memory to swap? The host is a Dell Optiplex 755 with a Intel Q6600 processor and 4GB of memory. It is not being taxed at all and I could easily afford to pin 2GB of memory to this XP VM if I could figure out how to.

I have read about the swappiness kernel parameter and have set vm.swappiness to 0 in /etc/sysctl.conf (and rebooted) in hopes that that would help but it seems to have made no difference. I have also tried vm.overcommit_memory = 1 and that hasn't seemed to do much either.

Anyone have any suggestions?


In the host settings in the VMWare Server Console there is an option that tweaks memory/swap use. The options are "all in RAM", "allow some swap" and "allow as much swap as needed".

  • That sounds like the ticket. I wish I had seen that earlier. I just changed this parameter via VMWare Infrastructure Client (2.5.0) and I get a popup error dialog with this message: "A specified parameter was not correct. spec.virtualMachineReserved" – Ben Jul 7 '09 at 16:44
  • If you are trying to change it with the VM(s) running it might winge if the current VMs are already swapping. Try stopping or pausing them and then changing the setting. – David Spillett Jul 7 '09 at 16:49
  • I found this thread which suggested changing the setting in the Web UI instead. communities.vmware.com/thread/177426 I have done that and I get no error. Now I just need to see how well it ends up working. – Ben Jul 7 '09 at 16:53
  • Well, seems like the setting took, but I can see the resident memory falling off in top just like it did before I made this change. It's only been a few minutes and the resident memory shown in top is already down below 200m for the process. I suspect it will get back down to 80m or so just like before. Any idea how this setting is supposed to work? How could vmware influence the host OS such that it doesn't swap stuff out? My intuition was to think that the solution to this problem was going to have to be some host OS level tweak. – Ben Jul 7 '09 at 17:11
  • After reading more about the setting you have mentioned (or at least the one I am thinking you were referring to), it seems the setting is really more for the purpose of limiting the cumulative size of the VMs running simultaneously on the system. You set some max total memory size and then VMWare will not allow you to start up more VMs than will fit in that total space. Alternatively you can tell it you're ok with using swap and it will let you start more VMs at a performance penalty. – Ben Jul 7 '09 at 17:26

Actually there is no way to force a process to stay in ram (vm are processes) except the kernel...

First, do you really need to avoid swap? perf issue, io issue etc... if not stay like you are.

But you can do some tuning. If you are sure to have enough ram, set swapiness (kernel option) to a low value (ie 10-15). default is 60 if i remember well.

look at "Linux 2.6 Host I/O Performance" of http://peterkieser.com/technical/vmware-server-issues/

It should help a little.

But understand that there is no magic trick for what you want to do. All operating systems are supposed to do swapping and they try to whenever possible.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy