Remote Console Very Very Slow

[GrahamC1066]

I've got a VI 3.5 u2/VC 2.5 u2 installation, when I boot a VM and open a console to it I can see that the response of the screen update in the console is very very slow. If I PXE boot a VM to provision it it can take 15-45 seconds before my key presses appear via the remote console.

I can see that there is a problem generally, as when I boot the machine and shadow it via the console I don't get screen updates, so it's like watching a slide-show of your VM at 5+ second intervals.

I get the same issue if I use the web-based console as well.

There are no other performance issues, only the screen updates via the remote console feature.

It's a bit of a show-stopper as we need to PXE boot our platforms first to provision them (hence no RDP at this point), and beacuse the screen updates are so sloooow we miss the PXE boot options!

Any guidance?

[java_cat33]

Hi - This is usually and indication that there is a network issue with the service console or the CPU usage is fairly high on the host. What speed network is connected to your service console? What is the host CPU usage?

[lfchin]

Not only the network perfomance, you may need to check the machine you launch the virtual infrastructure client, as the VI client take up a lot of resources and it could be the potential to slow down the console. 1 good example that sometimes you may feel slow when you log in through the console from VI client, but when you RDP to the server 2003 console using mstsc /admin, you found the speed is fast and your VM actually is performing as usual.

Rolando

[GrahamC1066]

Hi, the network performance is just fine to the service console (1Gbps connection) I can use a PuTTY session with no isssues, file transfers are fine.

I've used esxtop to monitor the CPU stats, with only 1 VM running on the host (4 x 2.8Ghz dual core) I get <10% pcpu overall utilisation and nothing in the %RDY column.

I've also checked teh memory stats (32Gb in the host and 4Gb on the VC and 256Mb allocated for each test VM), again the machine is practically asleep.

[GrahamC1066]

I should add I guess that I'm using a hugely complicated mecahnism to get to the VC (the joys of the government proivate network and a secure data centre), so I've now had one of the chaps go into the data centre and try it directly form the VC console in the rack - still the same issue.

I guess I'm frustrated as I don't experience any other performance hits elsewhere, it's just these very slow screen freshes that are driving me crazy!

[java_cat33]

I feel your pain!! Do you have any plugins installed/enabled on the VI client that you connect from? Latest VI client? Have you always experienced this problem? What version of Dot Net Framework are you running?

Do you have the same problems if you connect to the console of the VM via the web interface?

[GrahamC1066]

Thanks for your responses, and apologies for not responding earlier but I've been working flat-out on this problem all week! It looks like we might have traced our remote console problem...the VI client/web client gets upset when run on our windows builds which run on top of SUN x4600 M2s. As it happens this is the only platform we had available; I have now managed to find another platform, and the VI client/web access remote console work fine from that.

I need to look much harder at the build that is on the x4600 M2 and its BIOS settings, the build is a vanilla Windows Server 2003 Enterprise Edition (32 bit) build with SP2 on top.

[GrahamC1066]

OK, first off I must mention that my VI client was running on a SUN x4200 M2 (not an x4600 M2!), anyway I've found a solution to my problem and it looks like the fix actually is more to do with AMD multi-processor systems than anything else.

In a nustshell, there is a choice of hardware timers that a WIndows platform can choose as it boots - this decision is made according to the chipset features etc. Anyway, on an AMD multi-processor system (mine had 4 x dual core processors) if I don't use the /usepmtimer switch on the boot.ini then the VI client/web access goes seriously pear-shaped when trying to do a remote console session.

Just do a search on the web for "/usepmtimer and AMD" and you'll see plenty of information.

Easy when you know how. :smileycool: