Yellow Bricks

by Duncan Epping

Archives for 2009

Thanks vSphere, you will cost me my job!

· ·

As some of you know I did a health check in Saudi Arabia a couple of weeks ago. A health check is a relatively short engagement. A couple of days on-site and a day off-site for a report. When vSphere went GA I started thinking about all the things I discovered during this particular health check. Now some might say that the things I discovered were low hanging fruit. The truth is that during health checks the things discovered are usually low hanging fruit. Usually it is not because the Sys Admins don’t have enough knowledge, but because they either don’t get any time to manage their environment properly or they’ve been doing it for so long they don’t see the obvious anymore… Don’t get me wrong, there is more to a health check than just the obvious stuff, but I merely want to point out the improvements vSphere brought us in terms of consistent installation / configuration and alarms / actions.

Here’s a short list of the obvious things I usually discover during a health check:

  • Snapshots
  • Lack of redundancy on Service Console or VMkernel
  • Inconsistent naming schemes(Port groups)
  • Inconsistent configuration
  • DNS configuration issues
  • Missing advanced HA settings
  • Faulty hardware
  • Free space on VMFS volumes

Unfortunately for me vSphere will catch most of these issues.

  • Snapshots
    Storage view
  • Lack of redundancy on Service Console or VMkernel
    HA will not configure correctly
  • Inconsistent naming schemes(Port groups)
    Host Profiles or Distributed vSwitch
  • Inconsistent configuration
    Host Profiles
  • DNS configuration issues
    Host Profiles (partly)
  • Missing advance HA settings
    currently not addressed
  • Faulty hardware
    Alarms
  • Free space on VMFS volumes
    Storage view & Alarms

Thanks vSphere, you will cost me my job… Only thing left is “DNS configuration issues” and “missing advanced HA settings”.

What port numbers must be open for SRM and VirtualCenter / vCenter Server?

· ·

Every time I do a Site Recovery Manager jumpstart or start a project the same questions pops up. What port numbers must be open for SRM and VirtualCenter / vCenter Server to be able to communicate?

kb.vmware.com/kb/1006738:

The following ports are used for the respective products and must be open for remote communication:

VMware VirtualCenter / vCenter Server:

  • 80 (HTTP)
  • 443 (SSH)
  • 902 (VMware)
  • 8096 (Tomcat)

VMware Site Recovery Manager:

  • 80 (HTTP)
  • 8095 (SOAP Listen)
  • 8096 (HTTP Listen)
  • 9007 (API Listen)
  • 9008 (HTTP Listen)

vSphere ESXi on a USB memory stick

· ·

***Please use this supported method instead of the one below***

The procedure has not changed much since ESXi 3.5 but I thought I would document it anyway. A lot of people seem to end up here by googling “USB ESXi vSphere”.


Here you go:

  1. First get the following tools: 7-Zip(Free), WinImage(Demo)
  2. Download the ESXi ISO (VMware-VMvisor-Installer-4.0.0-164009.x86_64.iso)
  3. Open the ISO with 7-Zip
  4. Open “image.tgz” with 7-Zip
  5. Browse to “image.tgz.temptarusrlibvmwareinstallerVMware-VMvisor-big-164009-x86_64.dd.bz2”
  6. Extract “VMware-VMvisor-big-164009-x86_64.dd”
  7. Open WinImage and go to Disk, click on “Restore Virtual Harddisk Image on physical drive”
  8. Select a physical drive
  9. Select “VMware-VMvisor-big-164009-x86_64.dd”
  10. And click “yes” to write the DD image to the USB Disk

Done! Now, let’s see if I can get my old Dell GX620 running with vSphere ESXi

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",

Per processor licenses for your application

· ·

Some vendors license their application per processor, also in a virtualized environment. So if your VM has 4 vCPU’s your vendor will want you to buy a 4 processor license for the application. But you can avoid this by telling the VM that it has cores instead of processors. In others words, instead of having 4 processors you would have 1 processor with 4 cores:

  1. Power off the VM
  2. Right click on the VM and select “Edit Settings…”
  3. Select the “Options” tab
  4. Click on “General” (in the “Advanced” options section)
  5. Click “Configuration Parameters…” (in the pane on the right)
  6. Click “Add Row”
  7. Enter “cpuid.coresPerSocket” in the “Name” column
  8. Enter a value (try 2, 4, or 8) in the “Value” column
  9. Click “OK”
  10. Power on the VM

The VM will now appear to the OS as having multi-core CPUs with the number of cores per CPU given by the value that you selected. For example, if you create an 8 VCPU VM and set “cpuid.coresPerSocket = 2” it will be recognized as 4 dual-core CPU’s by the OS while it’s actually utilizing 8 physical cores.

Keep in mind that this feature is currently unsupported!