Yellow Bricks

by Duncan Epping

update

SRM 4.0 released

· ·

VMware just released version 4.0 of SRM. Just to be clear this is not the 4th version of SRM, the version number is aligned with vCenter and ESX. I’ve highlighted the new features which I think are really really useful or exciting.

Site Recovery Manager 4.0 | 05-October-2009 | Build 192921

Release Note
New Features:

  • Full compatibility with vCenter 4.
  • Full support for NFS-based arrays.
  • Support for shared recovery sites.
    Enables many-to-one pairings of protected sites with a recovery site. For more information, see the technical note Installing, Configuring, and Using Shared Recovery Site Support, which is available at http://www.vmware.com/support/pubs/srm_pubs.html.
  • Resilience in the face of vCenter unavailability during a test recovery.
    Placeholder virtual machines can be quickly repaired after the protected site vCenter becomes available again.
  • New repair-mode installation features.
    You can run the SRM installer in repair mode if you need to change configuration parameters such as vCenter credentials, database connection information or credentials, and certificate details.
  • Graphical interface to advanced settings.
    Eliminates most requirements to edit the XML configuration file
  • Support for DB2 as an SRM database server.
  • New licensing options.
  • Improved scalability.
    A single protection group can now include up to 1000 virtual machines.
  • Full Compatibility With DPM (Distributed Power Management)
    SRM recovery plans can now power-on or power-off a host that is in standby mode.
  • New Option to dr-ip-customizer Utility
    The dr-ip-customizer utility now logs less verbose diagnostic output by default. To force dr-ip-customizer to log the same level of diagnostic output that it produced in earlier releases, use the -verbose option.
  • Change in Certificate Validation
    When you select certificate authentication, the SRM installation validates the certificate you supply before continuing. Certificates signed with an MD5 key are no longer allowed.
  • Support for Protecting Fault-Tolerant Virtual Machines.
    SRM can now protect virtual machines that have been configured for fault-tolerant operation. When recovered, these virtual machines lose their fault tolerance, and must be manually reconfigured after recovery to restore fault tolerance.
  • Improved context-sensitive Help.
  • PDF documents available on release media
    Current versions of the PDF documents for this release are available in the docs folder at the root of the SRM 4.0 CD. Updated versions of these documents may be available at http://www.vmware.com/support/pubs/srm_pubs.html.

Keep in mind that if you want to do an upgrade you need to use a specific method to be successful. It’s described here. Now go ahead, download it and try it out!

vCenter Server 4.0 Patch 1

· ·

Don’t think many people have noticed this KB article yet or even experienced this issue with HA but nevertheless it’s worth mentioning. Apparently there’s an issue with HA in vCenter 4.0 when a class A network is being used. When a node fails this will not be detected and thus the fail-over of VMs will not occur. Although not many customers are using these class A ranges it is something I think you all should be aware of. This issue has been resolved and VMware released the following KB article which contains a link to the patch:

http://kb.vmware.com/kb/1013013
A vSphere 4.0 VMware High Availability cluster may not failover virtual machines when ESX is configured with certain IP addresses

You experience these symptoms:

  • In vCenter 4.0, VMware HA might not failover virtual machines when a host failure occurs.
  • When the ESX host’s IP address in a VMware HA enabled cluster is configured with certain IP addresses, the node failure detection algorithm fails.
  • You are susceptible to this issue when all of your Service Console Port(s) or Management Network IP address(s) on your ESX host fall within the following range:
    3.x.x.x – 9.x.x.x
    26.x.x.x – 99.x.x.x

Note: You are not affected if one of Service Console Port(s) or Management Network IP address(s) on your ESX host falls outside of this range.

ESXi and the update manager part II

· ·

A couple of days ago I posted about Update Manager wanting to install updates regarding the Nexus while I did not have the Nexus installed. I’ve rebuild my entire test environment with the latest(GA) build and noticed that I’m not experiencing these issues anymore. Now I’ve either had an outdated version of VUM, a screwed up database or I was sleeping when I wanted to apply the patches. Normally I take screenshots when things like this happen but because I did not have much time I did not take them.

I reinstalled my test environment again this morning and again I’m not able to reproduce it. The patch only installs when the Cisco Nexus 1000v is installed. It seems like my observation was wrong, I do however think it’s a smart thing not trust on technology for 100%, check your baseline before you apply it.

vSphere ESXi and the update manager

· ·

I was playing around with vSphere ESXi 4.0 and the Update Manager. As Jason Boche already reported several patches have been released and I wanted to test Update Manager. After downloading all the patches I noticed that there was a patch regarding the Cisco Nexus 1000v.

Although I did not have the 1000v installed Update Manager did want to install the patch. Kind of weird because why install the patch when you are not using the plugin? I decided to exclude it from my baseline to make sure I did not install it.

I was lucky to notice it because according to this KB article it can and probably will cause issues. If you did install it read the KB article on how to remove the patch!

Now this made me rethink my patching strategy. Normally I just install every single patch out there to make sure I am running the latest and greatest version, but apparently this is not the best practice anymore. My recommendation: review your patches and if it doesn’t apply to you exclude them!