This is somewhat of a longshot, but I am wondering if anyone might be able to explain the following:

I have a VMware Host Server running Ubuntu Server 8.04 LTS, and VMware Server 2.0. The User CPU usage on the host keeps climbing, until I reboot the server when it goes back down to almost nothing - and starts to climb again. This is ever since I swapped a Server 2003 VM for a Server 2008 one (upgraded my DC, and migrated to 2008). I can't find any problem with the Windows server though, or any abnormally high CPU usage on the VM itself.

I have been keeping up-to-date on the host, so I've been through about 3 kernel upgrades, numerous recompiles of VMware, and a whole new VMware Server version when the last one was released not too long ago. I just can't figure this one out.

Any suggestions would be very well appreciated, I'm now just looking for things to try!

alt text alt text

  • What process is the cpu usage listed under? That seems like the most obvious place to look. – davr Aug 14 '09 at 21:23
  • i have the same.. caused by 32bit w2003 & 64 bit w2008 guests. other [ vista, 32 & 64 bit linux vms ] do not cause this. will be interesting to see the answers. – pQd Aug 14 '09 at 21:23
  • Same here. Noticed it with Windows Server 2008 (32-bit) and three Ubuntu Server 8.04.3 guests. Using Ubuntu Server 8.04.3 as the host with VMware Server 2.0.1. When I reboot the Ubuntu guests it goes back to nothing then keeps climbing... – xeon Aug 14 '09 at 21:39
  • Presumably you have a vmware support contract, what do they say? – Chopper3 Aug 14 '09 at 22:22
  • It's a 64-bit host to allow me to address all the RAM, but all the guests are 32-bit. I plan to upgrade the CPU to one supporting VT, and then upgrade the DC to Server 2008 R2 - which means it would have to be a 64-bit guest. That might sort the problem out, as suggested by some answers below. – Rob Golding Aug 15 '09 at 10:13

I can't answer the question, but I can add an extra little bit of anecdotal evidence. I have noticed this too, with a Linux hosts (Debian/Etch and Debian/Lenny).

After some mucking around when I first noticed the issue, I came to the conclusion that the issue is VMWare, not the guests themselves. Upon stopping all services in the VMs on a particular machine the CPU use remained high despite the OSs in the VMs doing nothing. On shutting down each of the four VMs the excessive host CPU use dropped by about 25% per VM (I didn't measure this by any scientific means, but certainly no one VM seems to be imposing most of the load). After restrting the VMs the CPU use remained where it used to be, even with the services in the VMs active, and the load has begun to slowly rise over time with no related rise in apparent useful activity.

In both the cases that I have noticed this happen, the host OS has been 32-bit Linux and the guest OSs have also been 32 bit Linux.

I have not seen it in all cases though. On my home server (64 bit Linux kernel with 32-bit user-land running one large and two small 32-bit Linux VMS and occasionally Windows VMS for testing) and the main dev/test host at work (64-bit Linux (both kernel and userland) host running mainly Windows VMs, some 32-bit and some 64) this aberrant behaviour doesn't seem to be present. All the above are running VMWare Server 2.

So to cut a long story short: it isn't just you, and it isn't just Windows based guests, but it doesn't seem to be a consistent problem (as many arrangements don't see it as do, in my limited experience). Though unfortunately I can't help any further than that as I've not had the time to look into the problem in more detail.

  • Thanks for the help, it makes be feel a bit better that it's VMware and not the guests themselves - though it makes the problem harder to solve! Hopefully an Intel-VT CPU will help ease the issue, especially if I start moving guests to 64-bit. The new E6300 is a new chip that supports VT, and it's the cheapest out there at the moment. – Rob Golding Aug 15 '09 at 10:16
  • My main concern when I first noticed the unexpected CPU use my first fear was that something malicious had managed to get past my defences (I've since ruled this out to my satisfaction). At least when it happens it is not difficult to resolve (unless you are providing a HA service and so rebooting VMS occasionally is a problem) – David Spillett Aug 15 '09 at 10:56

First, I've seen this with VMware Server, too - on both Windows and Linux. In my experience it was related to running both 64-bit and 32-bit VMs at the same time.

Though it may not be an option for you, I'd suggest ESXi - the lightweight, free edition of ESX.

  • I would love to try ESXi, but I am using mdadm software RAID, so I can't get rid of the host linux O/S. – Rob Golding Aug 15 '09 at 10:14
  • I haven't tried running ESXi on software RAID, but would expect it would work OK since it's running linux underneath :) – warren Aug 16 '09 at 0:05
  • 2
    @warren - ESXi will not work with software raid. vmware is quite picky when it comes to hardware compatibility list, they support only 'real' raids / nfs / iscsi. – pQd Aug 16 '09 at 14:21
  • good to know, since that was how I was planning to deploy it at home – warren Aug 16 '09 at 23:06

I experience the same issue on a production server. Host OS is Debian Linux 64 bit. Guests are 4 Linux machines and 1 Windows XP. All guests are 32 bit. When i restart all VM services on the host, the CPU scheduling is fine and host CPU per VM is on par with real guest activity. However after some weeks the CPU scheduling increases until more or less the maximum available CPU time is consumed over the running VMs. The CPU usage on the host at that time is more or less 10x the initial CPU usage of the moment where the VMs just got started.

To me it seems a leak in the CPU scheduling on the host. Instaed of leaking RAM, it's leaking CPU cycles :-). How am I sure this doesnt happen on ESXi?


  • I have yet to hear of this issue in ESXi and if it was an issue, I am sure it would be fixed very quickly as its an enterprise level hypervisor. – xeon Jun 24 '10 at 16:05

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.