VMware Horizon Community
JayArr
Contributor
Contributor

VMWare View Linked Clone Deployment Pummels the Service Console

Greetings, I've been chasing my tail on this issue with a fresh VMWare View trial installation.

Host: Dell R900 4 x 4 Core Xeon (2.13Ghz ea.) 32GB of ram and 540GB 15k RPM Raid 5 DAS storage.

Virtual Desktop Manager is a VM on another VMI cluster - all devices are on dual gig ethernet links to our core switches (Cat 6509s with gig ethernet cards)

I've created a Windows XP master workstation and installed the agent and tools onto the workstation. When I create a linked clone from this, my CPU usage typically pegs one vCPU. But after four or five clones - the service console load skyrockets to more than 5, sometimes peaking at 8. During this time the virtual center server loses performance data, times out on tasks, and all sorts of bad stuff.

I've ramped up the available memory to the service console from 256MB to 800MB which didn't seem to help as I'm still seeing deployments fail during customization. I then decreased the number of concurrent provisioning tasks from 2 to 1.

I'm at a loss on where to go from here... why would the service console take such a beating during these linked clone deployments - and how is anyone else able to deploy these in such massive numbers?

Reply
0 Kudos
5 Replies
krismcewan
Enthusiast
Enthusiast

What Version of View are you using? Composer 1.1 has a problem deprovisioning and reporvisoning that VMware are working on. Try downgrading to View 3.01 and Composer 1.01

Whats the Spec of your VDM broker? View needs 2Gb memory minimum, If you have the memory available slap it up to 3. Also make sure its a SINGLE cpu VM. (need more power increase the VDM brokers)

Is VCenter 2.5 U5? Is that Virtual? whas the specsof the vCenter server.

Your Xp. was it a fresh install? have you done all the Windows updates on it? (make sure its not a problem with your VM)

check your server naming convetion. no character, spaces and keep it under 8 in legnth.

DNS should be up to date, DHCP should have enough scope (remember with View you need to double the address leases. 1 for the client deice and one for the Virtualised desktop)

fimnally make sure you are using Domain logins, no local admins should be used for anything View related.

A VMware Consultant in Scotland

A VMware Consultant in Scotland for Taupo Consulting http://www.taupoconsulting.co.uk If you think I'm right or helpful award me some points please
Reply
0 Kudos
JayArr
Contributor
Contributor

Thanks for the helpful tips - I have a list to go through.

I'm running the latest composer, so 1.1 and View 3.1. So a downgrade could be a possible fix.

My VDM broker is a 2GB 2 vCPU VM - I could destroy this one and deploy two single CPU, but I don't see performance issues on the VDM - it's on our production VDI cluster which is pretty robust, but that's an option too.

The XP machine could be the culprit - it was given to me by our desktop engineers - I'm going to go interagate him and see if he followed the deployment guide for XP.

Naming convention is kosher - pretty standard for VMs.

I will follow up today hopefully with a solution, thank you again.

Reply
0 Kudos
krismcewan
Enthusiast
Enthusiast

point your desktop engineer towards Nlite. Thining down the Gold Build makes a difference to deployment times.also make sure the XP has the minimal memory it needs to run and then put it up as you test it.

When deploying VM servers I have found that its always best to go for sungle CPU and higer memory as much as possible. expanding out to 2 or 3 VDM's is always better than upping CPU.

A VMware Consultant in Scotland

If you think I'm right or helpful award me some points please

A VMware Consultant in Scotland for Taupo Consulting http://www.taupoconsulting.co.uk If you think I'm right or helpful award me some points please
Jae_Ellers
Virtuoso
Virtuoso

I did notice that the ESX 3.5 Service Console memory allocation has very few shares relative to normal VMs. One of the servers I looked at had the SC CPU shares set at Custom 500. Normal was 4000, Low 2000, High 8000. So if you're running a lot of processing thru the system console you might want to bump this up. I'd assume it's also the same with the memory as well.

Try bumping the shares up a bit and see if it helps.

Did you ever get any improvement on this?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-=-=-=- http://blog.mr-vm.com http://www.vmprofessional.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-
JayArr
Contributor
Contributor

Sorry for the delay, our environment was in a beta test - and the problem never went away.

I decided to fix it with an atom bomb instead. I ran all of the firmware updates on all of the R900's hardware (for both servers - to bring them up to the same patch levels). Then blew away the ESX 3.5 install and installed vSphere 4.0 U1.

After I performed the upgrade I consolidated our VMware View environment to use the same vCenter server that was controlling our VMI.

So to answer your question - I was never able to find the root cause, but I'm running our View 4 environment very well on the same server today.

I'm also enjoying the power management features in vCenter that allow me to power down one of these monster servers to save over 600watts of electricity sitting idle!

Reply
0 Kudos