One of my colleagues, Michael White, just pointed out that VMware released a patch for Site Recovery Manager:

Site Recovery Manager 1.0 Update 1 Patch 4
File size: 7.9 MB
File type: .msi

Here are the most important fixes:

• a problem that could cause a recovery plan to fail and log the message
  Panic: Assert Failed: “_pausing” @ d:/build/ob/bora-172907/santorini/src/recovery/secondary/recoveryTaskBase.cpp:328
• a problem that caused the SRM SOAP API method getFinalStatus() to write all XML output on a single line
• full session keys are no longer logged (partial keys are used in the log instead)
• a problem that could cause SRM to crash during a test recovery and log the message
  Exception: Assert Failed: “!IsNull()” @ d:/build/ob/bora-128004/srm101-stage/santorini/public\common/typedMoRef.h:168
• a problem that could cause a recovery plan test to fail to create test bubble network when recovering virtual machines that had certain types of virtual NICs
• a problem that could cause incorrect virtual machine start-up order on recovery hosts that enable DRS
• a problem that could cause the SRM server to crash while testing a recovery plan
• a problem that could cause SRM to fail and log a “Cannot execute scripts” error when customizing Windows virtual machines on ESX 3.5 U1 hosts.
• support for customizing Windows 2008 has been added
• a problem that could prevent network settings from being updated during test recovery for guests other than Windows 2003 Std 32-bit
• a problem that prevents protected virtual machines from following recommended Distributed Resource Scheduler (DRS) settings when recovering to more than one DRS cluster.
• a problem observed at sites that support more than seven ESX hosts. If you refresh inventory mappings when connected to such a site, the display becomes unresponsive for up to ten minutes.
• a problem that could prevent SRM from computing LUN consistency groups correctly when one or more of the LUNs in the consistency group did not host any virtual machines.
• a problem that could cause the client user interface to become unresponsive when creating protection groups with over 300 members
• several problems that could cause SRM to log an error rmessage vim.fault.AlreadyExists when recomputing datastore groups
• a problem that could cause SRM to log an Assert Failed: “ok” @ src/san/consistencyGroupValidator.cpp:64 error when two different datastores match a single replicated device returned by the SRA
• a problem that could cause SRM to remove static iSCSI targets with non-test LUNs during test recovery
• several problems that degrade the performance of inventory mapping