Since migrating to a newly built cluster running ESXi 5.1 build 838463 and View 5.1.1 build-799444 we experience high cpu utilization on the esx side. It appears to be related to PCoIP because if I expand the cpu process in esxtop the vmx-svga process ID sits at a constant 20% cpu. There is nothing going on inside the VM at that time as we were able to duplicate it by just logging into a vm and letting the session sit there. Once the session is disconnected and logged back into the cpu seems to consistently return to normal for that process. SVGA driver in use is the version that is installed with the agent not the vmtools, we have removed and re-installed the tools and agent per KB articles, it is very random as not all vms experience this at the same time.
Just curious if you have also opened a ticket with VMware support regarding this? I haven't moved to ESX 5.1 yet and haven't seen the problem but maybe support is already aware of this issue.
I am experiencing this exact problem in my environment. It is causing no end of problems for me. I have a ticket opened with VMware but not getting anywhere too fast. I have had to do a lot of research myself to try and get some normality back. I have downgraded a host and this host behaves how it used to behave with VM's. On the v5.1 host I get high CPU when a Zero connects, the end user isn't logged in at this point to the VM O/S and if I migrate it to the v5.0 U1 host the CPU when the Zero connects is absolutely normal.
It can be random, some VM's do have normal CPU usage but more often than not it is high. I too had the SVGA driver KB but it makes no difference in my environment. I feel it is related to PCoIP and is not limited to Zero Clients as it does affect the View Client as well.
VMware has released new version of view 5.1.2, use view agent 5.1.2 and test the performance.
I noticed that but on the compatibility release notes it says that the view agent v5.1.2 is not compatible with the current ESXi v5.1.0a tools. So for now I will be waiting until I hear back on the tools and agent.
I have been playing around with so many settings and have come up with a possible work around, I would love to know if this works for you as well. I had set the resolution higher than any of my users connect with in my master image and recomposed with that snapshot.
It looks promising but I am still testing while I continue to wait for some progress with the ticket.
My golden image is currently set to a resolution of 1280x1024, so are you saying you want me to put the resolution of the image to 1600x1200 for example? What about the setting within View? Currently I have my View - Settings - Pool Setting - Max Res... at 1920x1200.
The workaround certainly helps. The cpu on the host returned to normal for one pool. I will do more testing. Have you heard back from VMware yet? I'm still waiting on their performance team to review all the logs.
No word.....it took multiple escalations and many hours on my end to prove there was a problem. Last I heard the engineer assigned to the case did not have time to replicate my work around in order to escalate again.....very disappointing. This will have to get us by until a fix is found unfortunately. Not impressed with support these days! I will keep you posted as we roll this out over the next few weeks so please do the same.
No change my end. VMware seem to be dragging their heels on this one. So much for support! Maybe there should be more communication between the ESXi and View teams when releasing updates. Very disappointing.
Would you mind to post the SR-number so I can take a look?
My support number is 12254202812. Raised on the 4th December. I was recently told there is unlikely to be a quick solution to the problem. I have recently created a Windows 7 image from scratch in the hope the problem would be eliminated, no such luck. It has got better and more manageable, but the problem is clearly there still as can be seen by monitoring the hosts with ESXTOP and drilling down to the SVGA worlds.
Experencing exactly same issues, high CPU usage for vmx-svga running esxtop. Tried multiple things already. Temporary workaround is setting our pools "Refresh OS disk after logoff" to "Always". Definitely helped a lot, because issues usually are not occurring on the first day or within the first few hours.
Case is still open, was recently moved to vSphere-Team.
Quick solution would be very appreciated...
I have the same issue two times in my environment. Changing resolution to higher or refreshing disks helps as workaround.
It happened to me after i have done reboot to all desktops (without refreshing, I have just down entire environment, and after start, today I have the same issue) - ticket already started with number 13283089702
In my environment no one can work today with that cpu utilization (all 16 hosts are in 100% cpu utilization permanent state ).
So if any of you will find any normal resolution please post here
Just upgraded to 5.1 same build and View 5.1. Ran into the same problem.
Opened SR with VMware # 13284706502
TSR said there is a bug open and lots of TSR's asking for updates but nothing from engineering. Pretty disapointed so far in the "new face" of VMware.
We are in the same boat. SR #13286190002
See the attached performance graphs...these are just two samples of View desktops that have gone haywire after ESXi 5.1 upgrade. If you look at the charts, you can probably guess that we upgraded from 5.0 to 5.1 on February 17th!
These two desktops happen to be Win XP 32, single CPU. Problem exists on Win 7 as well. Guest OS's both show low/normal CPU utilization yet ESXi thinks the guests are hammering the CPUs.
Even more interesting, on an hourly/real-time graph, the Usage in MHz for the VMs is 800-1200 MHz higher than the Usage in MHz for Processor 0 for the same VM. This is a bit unnerving when they are single CPU machines!
Something is definitely broken here...
I brought this over to the genius bar today at VMware PEX and stumped two engineers there as well.