Yellow Bricks

by Duncan Epping

vcenter

vCenter 2.5 Update 5 released!

· ·

VMware vCenter Server 2.5 Update 5 – includes Converter Enterprise

Latest Version: 2.5 Update 5 | 2009/07/10

The list of resolved issues is quite short this time. But a really important issue has been resolved and that’s why I recommend everyone who’s still running vCenter 2.5 to look in to this upgrade!
Support for High Consolidation in VMware HA Clusters – VirtualCenter 2.5 Update 5 includes significant performance and scalability improvements to VMware HA. Use VirtualCenter 2.5 Update 5 for environments with more than 35 virtual machines per host in an HA cluster.
For information on the ESX Server host settings required for this scalability improvement, see ESX Server host settings required for environments with up to 80 virtual machines per host in an HA Cluster (KB 1012002).
This is especially important for those with a high server consolidation rate or for instance for VDI. Make sure to read the KB article cause you will need to change several settings!

Howto: vCenter on Windows 2008 with Oracle

· ·

I received this how to in my email a couple of days ago from colleague Daniel Langenhan. Daniel was so kind to let my share this with you. If you are looking into installing vCenter on Windows 2008 with an Oracle database this might come in handy:

  1. Download 32bit Oracle client (even on a 64 bit system). Oracle 9i is not supported and the installer actually checks that. You only can use 10 or 11″.
  2. (10g) Download patch 5699495
  3. Install the 32 bit client using full Admin mode
  4. Use Net Manager to setup connection to Oracle server and test
  5. Use 32 bit ODBC [windows]/sysWOW64/obdcad32.exe
    The 64 bit is the one that shows up in Administrative tools and the installer will not use this.
  6. Create system DSN’s and test connection
    (10g) if error pop up doing so the patch from step 2 was not installed

VMFS/LUN size?

· ·

A question that pops up on the VMTN Community once every day is what size VMFS datastore should I create? The answer always varies,  one says “500Gb” the other says “1TB”. Now the real answer should be, it depends.

Most companies can use a simple formula in my opinion. First you should answer these questions:

  • What’s the maximum amount of VMs you’ve set for a VMFS volume?
  • What’s the average size of a VM in your environment? (First remove the really large VM’s that typically get an RDM.)

If you don’t know what the maximum amount of VMs should be just use a safe number, anywhere between 10 and 15. Here’s the formula I always use:

round((maxVMs * avgSize) + 20% )

I usually use increments of 25GB. This is where the round comes in to play. If you end up with 380GB round it up to 400GB and if you end up with 321GB round it up to 325GB. Let’s assume your average VM size is 30GB and your max amount of VMs per VMFS volume is 10:

(10*30) + 60 =360
360 rounded up -> 375GB

Cluster sizes and SRM

· ·

A couple of weeks ago I published an article on the maximum amount of VMs one could run on a ESX host. In short; if you enabled HA on your cluster it restricts the amount of VMs you can run on a host depending on the total amount of hosts in the cluster. This means that depending on your consolidation ratio you would need to limit the amount of hosts in a cluster.

Now, there might be another argument to take a good look at your cluster size. Site Recovery Manager. Currently vCenter 2.5 does not allow to simultaneously boot more than 16 VMs.

I’ve always been under the impression that the limit for SRM was 8 simultaneous boots but one of my colleagues notified me that the limit is actually 16. If all you care about is a low RTO, 16 would be a good cluster size wouldn’t it? There’s no point in having more than 16 hosts in a SRM enabled cluster if you don’t need the resources. However, don’t forget to take the HA “limitation” in account when designing your environment for availability.

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