I am beginning the troubleshooting phase now of why my VM's are running very sluggish.
I am running ESXi 3.5 installed on a Dell T7400, dual quad-core CPU, 32gb ram. I have 2 arrays on the PERC6i controller, 2x 750gb RAID1 for my ISOs, and 3x 1TB RAID 5 for all my VM's. There are 2 physical NICs as well.
My VM's are eith XP or WIN2K. I have running at any given time about 5-7 VM's but there are a total of 19 VM's on this host. Each VM has about 2-3gb of RAM. The XP machines have 2 processors while the WIN2k have only 1 allocated.
The main problem I am having is with our Sieble compile of the .srf file. This process usually takes about 90 min, but now, it is taking well over 3 hours. I am not sure if there is an I/O issue with the RAID 5 on the PERC controller. The compile is doing a lot of writing on the drive. When I configured the PERC card, I kept the standard defaults, 64kb, No Read Ahead, and Force WB.
I was told before I installed ESXi 3.5 that it could handle about 12-16 VM's running on a single host. Is this true? If so, where did I go wrong?
Any help is greatly appreciated.
I was told before I installed ESXi 3.5 that it could handle about 12-16 VM's running on a single host. Is this true? If so, where did I go wrong?
That's true. However, you can stress a host with less guests with the right software running on it or due to missconfiguration.
How much vCPU's have you assigned to your guests?
AWo
VCP / VMware vEXPERT 2009
\[:o]===\[o:]
=Due to lack of employees, human beings work here. - Treat them carefully, they are rare.=
I have 2 vCPU's to all of my XP VM's and only 1 vCPU on my WIN2K VM's.
You can certainly run into contention for disk access. Do you have a battery enabled cache module on your disk controller? Most write caching is disabled without a battery. Without one you will get poorer disk performance especially in a virtualized environment. You might also want to consider faster SAS drives for better performance.
Depending on how active the VMs are, you may be running into CPU scheduling issues. 2CPUs must be available before a guest gets access. Try reducing vCPU counts.
I have been trying to find info out on the Battery for the PERC 6/i but with out any success. The cards came from Dell w/o any battery option. I called Dell and they didn't seem to understand what I was asking for and proved that by sending me the CMOS battery.
I do have the Force Write Back with no battery enabled. So I am assuming maybe this is the equivilent to having the battery installed, just only difference is the risk if my host loses power while writing to the drives.
As for the vCPU's, I can drop the XP VM's down to 1 vCPU and see if that has any effect.
I have been trying to gather $$$ to purchase Vsphere 4 but am getting a lot of push back from my company, so asking for new SAS drives might be a bit tough right now.
I just read the Perc6/1 specs and it has
256MB of Error Correcting Code (ECC) battery-backed, cache
So it looks like you are good.
Well, good for the WB option. Are there tests I can run to see if the is an I/O bottle neck?
Start with 1 vCPU. That's best practices because it is symmetric multiprocessoring and it is a difference when you have symmetric multiprocessoring and the OS owns the CPU all the time or if it has to share it. All guests having n vCPU's have to wait until all n cores are available.
AWo
VCP / VMware vEXPERT 2009
\[:o]===\[o:]
=Due to lack of employees, human beings work here. - Treat them carefully, they are rare.=
Okay, I will start with lowering the vCPU to 1 on all the machines. I will post back the results tomorrow, as this will take some time with todays work already going on.
Thank you for your help today.
Okay, moving the vCPU to 1 on the machine had no effect. I actually shut all other VM's off and just had this one machine running. I need to verify if writing to the drives is the cause of this problem.
With that said, is there a good, safe app to run on my VM's to test the reading/writing of my drives?
iometer works.
I would look at your cache settings. Make sure write caching is enabled. Pretty sure the controller comes standard with battery backed cache but check to make sure. Write caching is very important for performance in a virtualized environment.
You are referring to the cache settings on the PERC controller right? If I remember correctly, I have the default settings which are:
Stripe Element Size – Default value is 64KB
Read Policy – Default value is No Read Ahead
Write Policy – Default Value is “Write Back”
I also have checked the box saying, Force WB with no battery
I am going to looking into iometer, i'll post my results.
Thank you for the help on this, really do appreciate it.!file:///C:/DOCUME%7E1/uswmlb17/LOCALS%7E1/Temp/moz-screenshot-3.png!
