I was just reading up on the PDF’s I gathered over the last couple of weeks and found the Scalable Storage Performance pdf extremely useful. It contains a good explanation about the queue depth setting and much more….

To reduce latency, ensure that the sum of active commands from all virtual machines does not consistently exceed the LUN queue depth. Either increase the queue depth as shown in the VMware Infrastructure 3 Fibre Channel SAN Configuration Guide (the maximum recommended queue depth is 64) or move the virtual disks of some virtual machines to a different VMFS volume. You can find the guide at
http://www.vmware.com/pdf/vi3_35/esx_3/r35/vi3_35_25_san_cfg.pdf.
Also make sure to set the Disk.SchedNumReqOutstanding parameter to the same value as the queue depth. If this parameter is given a higher value than the queue depth, it is still capped at the queue depth. However, if this parameter is given a lower value than the queue depth, only that many outstanding commands are issued from the ESX kernel to the LUN from all virtual machines. The Disk.SchedNumReqOutstanding setting has no effect when there is only one virtual machine issuing I/O to the LUN.

Via the Dutch VMUG site I landed on a new blog, well new… for me new. This blog is maintained by Toni Verbeiren and he created an excellent article about monitoring performance stats for the scsi controllers inside a VM:

A tool is available on ESX 3.5 that creates histograms by default (and complete traces if wanted) is VscsiStats. As an option, one provides the vSCSI handle ID and the VM World ID. In order to get some statistics at all, one first needs to start the monitoring:
./vscsiStats -s

After some time, the relevant statistics can be fetched by issuing a command like:
./vscsiStats -i 8260 -w 1438 -p ioLength

Read more at the source…

There also appears to be a pdf about the subject on the VMware website which contains good information on the subject.

EDIT: You can find the command here: /usr/lib/vmware/bin

I can’t seem to post anything or reply:

System Error

* The specified thread was not found.

It seems someone is reading my blog, the forum is almost up and running again!

System Error

We’re sorry but a serious error has occurred in the system. If you are a system administrator please click “more details” below for more information about this error.

VMware released 4 patches yesterday:
ESX350-200806401-BG – Critical – Updates to VMkernel and hostd
ESX350-200806402-BG – General – Update to the Service Console Kernel
ESX350-200806404-SG – Security – Security Updates to WebAccess Components Tomcat and JRE
ESX350-200806405-BG – General – Update to VMware-esx-vmx

Good luck with patching!

A couple of weeks ago I received a cool PDF via email, this week it appeared online(source blog). Check it out:

The Source PDF:
VMware has collaborated with Cisco to produce a guide for deploying VMware Infrastucture 3 with Cisco switches. This guide covers the physical and virtual data network and storage network deployment considerations for ESX Server with suggested topologies and designs.

Just noticed the following topic, which definitely contains some good info about how ESX deals with memory. Thanks to Kit for clearing things up. These posts are valuable, keep ‘em coming!

a short outtake:

Basically how aggressive do you want TPS to scan for shared pages? Obviously TPS has a cost to running in terms of CPU, but has benefits in terms of reduced memory usage. So there’s a tradeoff. We have a default that we think is a good balance, but we let the user modify that if they want.

Just dropped the following short script in a topic on the VMTN Community. It shuts down every VM on the host and than the host itself, but it will enter maintenance mode first, just to be sure that no other vm’s get migrated to this host.

VMLIST=’vmware-cmd -l’
for config in ${VMLIST}
do
vmware-cmd $config stop trysoft
done
vimsh -n -e /hostsvc/maintenance_mode_enter
shutdown -h now

addition: thanks forbes for the trysoft addition.