VMware Horizon Community
jay88
Contributor
Contributor

Migration 5.1.1 High Cpu

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.

Capture.GIF

Reply
0 Kudos
67 Replies
mittim12
Immortal
Immortal

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.  

Reply
0 Kudos
jay88
Contributor
Contributor

Yes a ticket has been opened.

Reply
0 Kudos
TSher
Enthusiast
Enthusiast

Hi Jay88,

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.

Thanks,

Tony.

Reply
0 Kudos
TSher
Enthusiast
Enthusiast

Hi Mittim12,

i have had my ticket open for around 2 weeks and they said they hadn't heard of this issue.

Thanks,

Tony.

Reply
0 Kudos
memaad
Virtuoso
Virtuoso

Hi All,

VMware has released new version of view 5.1.2,   use view agent 5.1.2 and test the performance.

Regards

Mohammed

Mohammed | Mark it as helpful or correct if my suggestion is useful.
Reply
0 Kudos
TSher
Enthusiast
Enthusiast

Hi,

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.

Thanks

Reply
0 Kudos
jay88
Contributor
Contributor

Hey Tony,

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.

- Jay

Reply
0 Kudos
TSher
Enthusiast
Enthusiast

Hey Jay,

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.

Thanks

Reply
0 Kudos
jay88
Contributor
Contributor

Yes any higher resolution than your clients connect with should be fine, you can leave the pool config as is.

Reply
0 Kudos
TSher
Enthusiast
Enthusiast

Hi,

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.

Thanks

Reply
0 Kudos
jay88
Contributor
Contributor

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. 

Reply
0 Kudos
andrey09
Contributor
Contributor

Is there any changes ? I have same issue with 5.1 (914609) vsphere  and 5.1.2 view agent.

In my case this issue is exposed on ~5%  VM's , reboot of VM is temporarily solve problem .

Reply
0 Kudos
TSher
Enthusiast
Enthusiast

Hi,

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.

Reply
0 Kudos
Linjo
Leadership
Leadership

Would you mind to post the SR-number so I can take a look?

// Linjo

Best regards, Linjo Please follow me on twitter: @viewgeek If you find this information useful, please award points for "correct" or "helpful".
Reply
0 Kudos
TSher
Enthusiast
Enthusiast

Hi,

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.

Thanks.

Reply
0 Kudos
Richard8037
Contributor
Contributor

Hi,

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...

Reply
0 Kudos
McBolo
Enthusiast
Enthusiast

Hi all

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 Smiley Sad ).

So if any of you will find any normal resolution please post here Smiley Happy

Best Regards

Piotr Iwaszkiewicz

Piotr Iwaszkiewicz piotr.iwaszkiewicz@udt.ov.pl http://www.udt.gov.pl
Reply
0 Kudos
mikeyes
Enthusiast
Enthusiast

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.

Reply
0 Kudos
C3LLC
Contributor
Contributor

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.

Reply
0 Kudos