KVM Performance - VM Guest 2008 R2 x64

[COS]

Anyone experience this? I scoured the web and came across one that had me change the wddm_video driver on the guest and it helped but not by much.

The issue is slow Guest KVM response from the vSphere Client 5 "Console". RDP is fast on the Guest.

Admittedly it's not my server but a colleague of mine. I checked it and all his NIC's are set to 100 FULL and it's a RAW/Vanilla install. Been testing on new hardware.

[RParker]

COS wrote:

The issue is slow Guest KVM response from the vSphere Client 5 "Console". RDP is fast on the Guest.

yes this is normal behavior, the console is translating a command from the VI client through the server, to the guest OS, it's not direct like RDP.  so since you know it's faster, why do you need the console?  just use RDP!

[ranjitcool]

Hello,

Are you traversing any networks to get to your friend's network. And by that I mean how many hops?

Also check for special parameters such as keyboard.typematic.mindelay and other such if they are set. I learnt that the mindelay is good for linux so we don't get the "$ reboottttttt" scenarios.

I can't really think of anything else that might be causing this sluggishness - may be vmtools might also be a shot.

RJ

[COS]

"the console is translating a command from the VI client through the server, to the guest OS"

Is it safe to assume that the data stream is coming from the "Management Network"?

The console needs to respond as best as possible. Some applications do not like being installed from an RDP session. Just ask many Citrix/XenApp admins.

Thanks

[COS]

When I was there, it was one switch hop, and slow as molllassssseeeesssssssss......

VMware Tools are installed. I don't know much about the "keyboard.typematic.mindelay". It's a RAW/Vanilla build. I have 3 ESXi 5 servers (RAW/Vanilla build) with many 2008 R2 x64 and they do not exhibit this slowness. It's also a single switch hop.

This is friggin weird mannnnn........

[RParker]

COS wrote:

Is it safe to assume that the data stream is coming from the "Management Network"?

The console needs to respond as best as possible. Some applications do not like being installed from an RDP session. Just ask many Citrix/XenApp admins.

Thanks

Well the data stream is coming from the VI client when you open the console, if that's your management console IP then yes.  There is an option in RDP to start as "console" meaning you CAN run and install apps in console mode even on RDP.  If you still need console access, then I suggest you install VNC.  That will solve the problem nicely.  I know /console will work on MSTSC in Windows 2003, Windows 2008 not so much, but if you google console mode, there are alternatives and other methods to use.  VNC might be the easiest, it also has some issues with responsiveness, but it will much less noticeable than using the VI console method.

[RParker]

RJ wrote:

Hello,

Are you traversing any networks to get to your friend's network. And by that I mean how many hops?

Also check for special parameters such as keyboard.typematic.mindelay and other such if they are set. I learnt that the mindelay is good for linux so we don't get the "$ reboottttttt" scenarios.

I can't really think of anything else that might be causing this sluggishness - may be vmtools might also be a shot.

RJ

As I already mentioned, this is a KNOWN issue, has nothing to do with network hops, configuration, the server or the VM tools.. open ANY VM console, that console will ALWAYS be slower (and much more so) than any RDP session.. it's just common sense.  If you open a VI client software, then connect to the server, then open a console window.. that's a LOT more layers than connecting direct, so it's natural to make the observation it WILL be slower than going direct.  It's not really slower, just more latency considering the intervening applications and multple conversion methods.

[COS]

Yeah, we've tried the /ADMIN switch for mstsc.exe. Even that fails sometimes.

So check this out. For kicks/testing, on my 3 ESXi5 hosts that have several 2008 R2 x64 VM's, I made the driver change in the guests for the wddm_video driver and..............great googly mooogly! The "console" from the vshere client is blazing fast. almost like I was in front of the physical console!

I don't understand why his is soo dang slow. :smileyconfused:

[TGSYMC]

Ah, this was a god send!

I've been fighting with ESX and the slow response for months now thinking there has to be a way to fix it.

Saw this thread and tried installing the WDDM_Video driver and it also fixed the problem. I boosted the video ram to 32MB as well, just to be safe.

I used this KB article to do the installation. (http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=101677...)

It works perfectly for ESXi 5, even though it only mentions ESX 4.x and Workstation 7.

Thank you COS!