Yellow Bricks

by Duncan Epping

service console

Remote CLI Update!

· ·

I just noticed that VMware also updated the Remote CLI, which was heavily criticized when it first came out because of the lack of commands. Now it contains almost every single command out there. And there’s a great PDF file about all the commands and the options.

I guess the Remote CLI matured, I was wondering what the benefits were of a Remote CLI. But know it makes sense. Start using ESXi, install the Remote CLI virtual appliance and you’ve got only 1 console to handle them all instead of “x”.

Howto: Check if a LUN is being locked by the host?

· ·

I just came across the following on the VMTN forum which is a very useful command in my opinion. When metadata changes for a LUN, that LUN is being locked by a host. Sometime the lock isn’t released, which can cause weird situations. In this case you would want to know which host is locking the LUN, especially when you’ve got over a dozen hosts. Rubeck posted a reply on Vliegenmeppers question on the forum:

esxcfg-info -s | grep -i -B 12 pending

Thanks guys,

Queuedepth, and what’s next?

· ·

I’ve seen a lot of people picking up on the queuedepth settings lately, especially when there are QLogic adapters involved. Although it can be really beneficial to set the queuedepth to 64 it’s totally useless when one forgets about the “Disk.SchedNumReqOutstanding” setting. This setting always has to be aligned with the queuedepth because if the Disk.SchedNumReqOutstanding 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. In other words if you set a queuedepth of 64 and a Disk.SchedNumReqOutstanding of 16, only 16 commands get issued at a time to the LUN instead of the 64 your queuedepth is set to.

You can set Disk.SchedNumReqOutstanding via the command line and via VirtualCenter:

  1. VirtualCenter -> Configuration Tab -> Advanced Settings -> Disk -> Disk.SchedNumReqOutstanding
  2. Commandline -> esxcfg-advcfg -s 64 /Disk/SchedNumReqOutstanding

Disk.UseDeviceReset section is deprecated, see this article for more info.

NIC reordering

· ·

I’ve seen this happen a lot, you’ve got multiple vendor nics in your ESX hosts and for some reason the numbering is all screwed up. So the onboard nics are vmnic0 and vmnic2 the pci nics are vmnic1 and vmnic3, this can be really confusing, and even more confusing when the renumbering is inconsistent. Instead of manually editing your esx.conf file Allen Sanabria created a python script which fixes this issue. Check out this blog for the full article and the script:

Could you beleive that VMWare says that a feature of there software will reorder your NICs after the kickstart???
So if this was the order of our NICS
03:02.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01)
03:02.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01)
eth0 == 03:02.0
eth1 == 03:02.1
When VMWare comes up it will reorder them so that vmnic0 will point to 03:02:01 when it should be 03:02:00 Now this only happens when you have a box with multiple nics from multiple vendors. This script will take care of it for you.

Command line tips and tricks #3

· ·

Enter maintenance mode from the ESX command line:

vimsh -n -e /hostsvc/maintenance_mode_enter

Backup every running vm via vcb in just one command:

for /f “tokens=2 delims=:” %%i in (’vcbvmname -h <virtualcenterserver> -u <user> -p <password> -s Powerstate:on ^| find “name:”‘) do cscript pre-command.wsf “c:\program files\vmware\vmware consolidated backup framework\” %%i fullvm

Enable VMotion from the command line:

vimsh -n -e “hostsvc/vmotion/vnic_set vmk0″