Yellow Bricks

by Duncan Epping

ESX

ESX Deployment Appliance v0.90

· ·

For those who don’t own vSphere Enteprise Plus licenses it’s a bit more difficult to set up a consistent virtual environment. I’m glad Herco van Brug aka Brugh put a lot of time and effort in developing the ESX Deployment Appliance.

Herco just released a brand new version, v0.90. Here are the release notes:

  • ESX 4 support
  • ESXi 4 support (installable and stateless!)
  • ESX 4 script parts (post any good scriptparts on this forum or PM me and I’ll integrated it into the appliance)
  • new first config screen
  • some bugs removed (patch system, backups, host input routine, apache tweaks)

Download it now!

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”.

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!

MSCS VM’s in a HA/DRS cluster

· ·

We(VMware PSO) had a discussion yesterday on the fact whether it’s supported to have MSCS(Microsoft Clustering Services) VM’s in a HA/DRS cluster with both HA and DRS set to disable. I know many people struggle with this because it doesn’t make sense in a way. In short: No, this is not supported. MSCS VM’s can’t be part of a VMware HA/DRS cluster, even if they are set to disabled.

I guess you would like to have proof:

For ESX 3.5:
http://www.vmware.com/pdf/vi3_35/esx_3/r35u2/vi3_35_25_u2_mscs.pdf
Page 16 – “Clustered virtual machines cannot be part of VMware clusters (DRS or HA).”

For vSphere:
http://www.vmware.com/pdf/vsphere4/r40/vsp_40_mscs.pdf
Page 11 – “The following environments and functionality are not supported for MSCS setups with this release of vSphere:
Clustered virtual machines as part of VMware clusters (DRS or HA).”

As you can see certain restrictions apply, make sure to read the above documents for all the details.