Yellow Bricks

by Duncan Epping

service console

How to show load balancing policy in the COS?

· ·

Kelly Olivier had a good question on the VMTN Communities. How can I check from the Service Console which network load balancing I’m using? Of course his first bet was “vmware-vim-vmd” but unfortunately there doesn’t seem to be an option to show which load balancing policy is being used.

As far as I know there’s another way to show this:

cat /etc/vmware/esx.conf | grep "teamPolicy\/team"

This would return the following:

/net/vswitch/child0001/teamPolicy/team = "lb_srcid"

Possible load balancing policies:
lb_srcid = Virtual port id
lb_ip = IP Hash
lb_srcmac = MAC Address

If anyone knows of any other methods of showing this info let me know and/or contribute to the topic on VMTN.

Update:

@lamw just posted that it is possible to get this info from vmware-vim-cmd:

vmware-vim-cmd hostsvc/net/vswitch_info | grep -E '(policy|name)'
      name = "vSwitch0",
         policy = (vim.host.NetworkPolicy) {
               policy = "loadbalance_ip",
      name = "vSwitch1",
         policy = (vim.host.NetworkPolicy) {
               policy = "loadbalance_srcid",
      name = "vSwitch5",
         policy = (vim.host.NetworkPolicy) {
               policy = "loadbalance_srcid",

Change the license server from the Service Console

· ·

Got a question today on how to change the licensing server from the Service Console or how to add the license server via a scripted install. Of course “vmware-vim-cmd” is the keyword here. If you want to use a license server you will need to use the first option, if you want to add a license file you will need to use the second option:

  1. vmware-vim-cmd vimsvc/license --source server
  2. vmware-vim-cmd vimsvc/license --source file

Don’t you just love “vmware-vim-cmd”….

The Basics: How to kill a VM that’s stuck during shutdown?

· ·

I just replied to a topic on the VMTN forums and thought it might be useful to write it down here as well. (I thought I already did, but a search didn’t turn up anything.)

When a VM gets stuck during shutdown or isn’t responding anymore you can easily kill the VM. First option is the command line version of vCenter’s “shutdown vm”, first list all the VMs running on the host so you can copy and paste the <config> in to the next command. The command “vmware-cmd <config> stop trysoft” will try to initiate a soft shutdown first, in other words a shutdown via the Guest OS, if that doesn’t work it will do a power off. Now, as most of you probably already experienced, sometimes it’s impossible to shutdown the VMs in a normal way. This is where 2nd, 3rd and 4th option come in to place. Option two uses vm-support to kill the VM, use “-x” to list the VM id’s and kill it with “-X”. The third option uses vimsh, in this case we use vmware-vim-cmd, “vmsvc/getallvms” lists all VMs and the id’s and with “vmsvc/poweroff” you can specify the VM that needs to be powered off. The fourth option is the Linux/Unix way of doing it, find the process id of the VM via “ps -auxwww” and just kill it.

  1. vmware-cmd -l
    vmware-cmd <config> stop trysoft
  2. vm-support -x
    vm-support -X <vmid>
  3. vmware-vim-cmd vmsvc/getallvms
    vmware-vim-cmd vmsvc/poweroff <vm id>
  4. ps -auxwww | grep <vm name>
    kill <process id>
  5. if option three isn’t successful do the following: 
    kill -9 <process id>

As VMwareWolf points out, there’s an excellent KB article on this subject to be found here: http://kb.vmware.com/kb/1004340

RE: ESXTOP Drilldown (Jason Boche)

· ·

I was working on an ESXTOP post when Jason Boche published his blog post “ESXTOP Drilldown“. My post was similar so I decided to dump the post and start over again within a few weeks or so.

Yesterday I encountered a performance issue at a customer site. One thing I’ve learned over the last couple of years is that “ESXTOP” can be very useful in pinpointing performance issues, so writing this article happened sooner than I expected. The customer measured all sorts of counters within the VM and all the symptoms made the customer conclude that the problem was related to the virtual SCSI controller and / or the virtual harddisks(vmdk’s). The symptoms were high “Physical Disk\Avg. Disk sec/Transfer” and peak “Physical Disk\Avg. Disk Writes/Sec” behaviour. In other words, transferring data to and from the disk took too long and there wasn’t a constant stream of I/O.

[Read more…] about RE: ESXTOP Drilldown (Jason Boche)