5 Replies Latest reply on Nov 17, 2008 12:20 PM by Craig Baltzer

    VM's very slow...

    staggs Lurker


      Hi all,



      I am having a problem with my esx 3.5 install. I have a Supermicro 6025BT, 2 x Dual core Xeon 1.86, 8GB ram, LSI 8380ELP, 2 x 300GB SATA (mirror), 4 x 500GB SATA (raid 5).



      After installing 3.5 on the 320GB mirror, I created a vmfs volume on the raid 5 LSI volume. I then created a 50GB VM, 2GB ram, 2 CPU's and installed Server 2008 64bit version on it. I then installed another VM, same config as the first and the two VM's were running fine. I proceded to install a third VM with the same config as the first two, but as soon as the file copy started, the first two VM's slowed down to a crawl and the install of the third VM took about a day and a half, litterally.



      After I finally got the third one installed, I started patching the first VM. Same thing, everything just slows down to a crawl. The install of the 10 patches has been going on now for almost 14 hours.



      I know that the server, drives and controller are all good as I have been using the system to hos Exchange for the past 8 months with and average of 40,000 emails a day.



      Any ideas as to why ESX is such a dog after 2 VM's?









        • 1. Re: VM's very slow...
          stvkpln Master

          Is there any reason you're giving each VM 2 vCPU's to start with?  The thing to keep in mind with ESX is that when you assign multiple CPU's to a VM, the scheduler has to assign 2 CPU's (in this case, cores) for any task, regardless of if the VM only needs one or two. That's just how it works. I'd recommend re-creating your VM's with 1 vCPU and see if the issue persists.

          • 2. Re: VM's very slow...
            Craig Baltzer Expert


            Are the VMs doing anything at this point or just sitting idle (i.e. are you just in the process of prepping the VMs for use or are they running a bunch of workload already)? If you shutdown one of the first 2 does the 3rd  get fast again? Connect to the ESX server with the VI Client, take a look at the Performance tab for the server as well as the VMs. Look for heavy utilization of particular resources as a place to start. Also flip over to the ESX console and see if there are errors being logged (particularly disk errors) in the /var/log/vmkernel* and /var/log/messages*






            • 3. Re: VM's very slow...
              Jae Ellers Master


              What's the ESX version?  Is it fully patched?



              How do top & esxtop look?  Anything using a lot of resources?



              I'm surprise at the level of slowness, but it may be that your systems are just slow enough with the sata disks to suffer when one starts to use some IOPS the rest suffer badly.  Alternatively, as others have pointed out, your cpus are contending for resources.  I'd certainly try the same setup with 1-vCPU guests and see if that help. 



              Are the guests running a virus scanner?



              • 4. Re: VM's very slow...
                staggs Lurker


                Thanks for the responses. Let me see if I can address them all in this post...



                No particular reason for 2 CPU. Can I set back to 1-vCPU without reinstalling?



                The CPU utilization is through the roof on all VM's. Disk IO isn't bad, a few spikes here and there but pretty steady.



                My version is 3.5, and it was a fresh install last week with the most recent version. They are vinallia installs of server 2008 and I installed SQL on one, but it is clean.



                I moved two of the VM's to my mirror set and left one on the raid 5 and this is didn't help any at all.






                Thanks again...






                • 5. Re: VM's very slow...
                  Craig Baltzer Expert

                  Yes, you can move back to 1 CPU without re-installing.


                  Is the high CPU utilization expected? Are the VMware Tools installed in the guest VMs? If you look inside the VMs what process(es) are taking all the CPU? No reason that two fairly vanilla W2K8 VMs should have the CPUs pegged...