The VMguy

By now, most of you know how Site Recovery Manager works.  SRM requires a SRA (Storage Replication Adapter) which is basically a translator to allow SRM talk directly to the storage arrays.  6 of the SRAs were updated on VMware’s download site for SRM in January.  They were:

Dell EqualLogics, Version 1.0.2, Released 01/20/2010

EMC Celerra, Version 4.0.17, Released 01/29/2010

Fujitsu ETERNUS SF AdvancedCopy Manager, Version 1.3| Released 01/29/2010

IBM DS4000/5000, Version 01.01.35.05, Released 01/15/2010

IBM N-series SAN Adapter, Version 1.4.2, Released 01/07/2010

LSI, Version 1.01.30.05, Released 01/21/2010

You can find the updated SRAs on the SRM download site here.  As always, please check to make sure these updates are necessary for your environment.  I would have included the release notes but unfortunately the vendors are not keep track of them.  Upgrade at your own risk, and if you do, please test your recovery plans out fully with the new adapters.

At long last, Site Recovery Manager 4.0 has been released.  Here’s the what’s new section from the release notes:

This release of Site Recovery Manager introduces several 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.

I was going over the KB digest this morning and saw a few KB articles that hit home with a couple issues that customers have been asking me about regarding View.

The first is wondering how an admin can do more advanced things with the View Manager Server.  For instance: assign a default desktop out of a pool to a specific user or  listing orphaned desktops (users that no longer exist or have changed permissions and no longer have access to a desktop in a pool but still have one assigned to them) or cleaning up after removing a secondary View Manager server.  All of these items can be performed by a little-known command line utility included in View called vdmadmin.exe. Read the rest of this entry »

I’m a huge fan of Data Recovery.  It’s very bare-bones but it does what it sets out to do.  I’m hoping to have a review of Data Recovery completed later this week.  In the mean time, v1.0.1 was released Friday (the releases keep on rolling).  You can download the new version here.

This release is all bug fixes, here’s the list from the release notes:

The following issues have been resolved since the last release of Data Recovery. For a full list of known existing issues, see VMware Data Recovery 1.0 Release Notes. The list of resolved issues below pertains to this release of Data Recovery only. Read the rest of this entry »

I’m training all of my partner engineers this week and they always ask the toughest technical questions.  Thanks to Scott Phillips for asking me this one:

What does Fault Tolerance do to prevent a split brain if both Primary and Secondary VMs become isolated?

Fault Tolerance (FT) uses an on-disk generation number file.  When FT is enabled the primary VM creates a file on shared storage called generation.N where N is a counter number.  The secondary VM is started and when it connects to the primary, the primary tells the secondary what the generation number is.  Once the Primary or secondary detects that there is a failure in the other half of the VM pair, it will try to rename the generation.N file to generation.N+1.  If the rename succeeds, the VM takes over as being the Primary (or remains the primary if it already was) and takes corrective action to rebuild a secondary and become protected again.  If the rename of the generation.N file fails, that means that the other VM in the pair already renamed the file and took over and the current VM shuts down.

There you have it, the disk subsystem prevents both VM’s from becoming the primary at the same time and creating a split brain.