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