by Duncan Epping
Today I visited a customer that wanted to enable the VMware tools timesync during an automated install of a Windows VM. The customer didn’t want to use powershell / perl or anyother SDK enabled tool. So what’s left?
“C:\Program Files\VMware\VMware Tools\VMwareService.exe” –cmd “vmx.set_option synctime 0 1”
So this command ticks the checkbox for timesync via VMware Tools, which can come in handy when doing RIS alike installs.
A few weeks ago I posted a document which contains valuable information on implementing VMware HA. I just received an update on this document and uploaded it. I’ve also changed the link in the original post.
As most of you know I work for VMware which means I receive a huge amount of email and documents with excellent technical info. Some I can’t blog about but some I can. Last week I received this VMware HA implementations notes document by Seva Semouchin. Seva is a Technical Account Manager based in Germany!
This document deals about VMware HA clusters and all the advanced options you have with the use cases for these options. And that’s what makes this document very useful, the use cases! So everyone dealing with HA clusters should definitely read this document. Thanks Seva for letting me distribute it, and thanks for a great document!
Team Fusion wrote a great post on “defragging” vm’s and why you shouldn’t do it. Or at least be very careful about it. Make sure to read it!
Before we begin, it’s important to note that defragmentation isn’t a necessary task – your virtual machine will still work just fine even if you never defrag, and the effects of fragmentation are usually not noticeable. Personally, I’ve never feel the need to defrag. However, if for some reason you do feel the need to defrag, here’s how to do it. Note that snapshots get in the way of proper defragmenting.
So you’ve heard this probably from a few dozens of people by now when you don’t hit the expected SAN performance: Set your queuedepth to a larger size.
So how do you set this queuedepth? Find out for which module you’ll need to set this option:
vmkload_mod -l | grep qla
Now set it to a depth of 64 for module qla2300_707
esxcfg-module -s ql2xmaxqdepth=64 qla2300_707
esxcfg-boot –b
So now you’ve set the queue depth to 64 for your HBA cards, but why? Well I hope the answer is:”because I monitored my system with esxtop and I noticed that the “QUED” value was high”.
So there’s your when. You’ll need to set this setting if you notice a high “QUED” value in esxtop. Take a look at the following example I borrowed from a great blog on this subject:
As you can see in the example, the “ACTV” has a value of 32. Indeed 32 active commands cause that’s the default queue depth for qlogic cards. And 31 outstanding commands, in other words if we bump up the queue depth to 64 than all the commands should be processed instead of queued in the VMkernel.
What will this result in?
So I’ve been collecting some HA best practices lately. I just wanted to have them all in one place so I can use them myself for the VMTN forum and/or customers. The first two are obvious in my opinion but still often overlooked: