|
Posted by
Ken Werneburg
Sr Tech Marketing Manager
I'm very pleased to announce a new SRM release!
It's not heavy on new features, but it's a great release with a couple of new major functions that are very import and a bunch of great bug fixes. I'll talk a bit about what's in here, but do take a look at the release notes as well for the full explanation.
VMware vCenter Site Recovery Manager 5.0.1 offers the following improvements:
Forced failover. If your arrays had failed at the primary site, many times you would view this as a reason to execute a recovery plan to fail over. A difficulty in the past has been that the recovery plan wants to shut down the protected VMs at the primary site, but could not do so gracefully if for example the storage platform was experiencing problems and unresponsive. Forced failover lets the recovery plan execute even without the ability to shutdown/poweroff/unregister the VMs.
This is a great improvement as obviously when things are having problems is when you most want to run a recovery to get things operational, without waiting for the storage platform or timeouts.
The other addition is support for customizing IP addresses on Ubuntu 10.04, 10.10, 11.04, and 11.10. A welcome change for our Linuxians.
Predominantly, however, there are a lot of great bug fixes in 5.0.1. In the interest of brevity I've removed most of the descriptions, but have left them in for the fixes I've heard come up a number of times. For the full description, of course go read the release notes!
Resolved Issues
-
Planned Migration May Result in Slowed ESX Hosts
-
SRM tasks that are cleaned up too quickly cause the ManagedObjectNotFound exception
-
Per-CPU license count is incorrect
-
Protecting a virtual machine in a replicated datastore spanning two disk partitions causes SRM to stop unexpectedly and fail to restart. If you protect a virtual machine that is contained in a replicated datastore that spans two disk partitions in the same device, SRM stops unexpectedly while recalculating the datastore group. The SRM logs show the error Panic: Assert Failed: "ok" @ d:buildobbora-474459srmpublicpersistence/saveLoadUtils.h:329. SRM Server then fails to restart. This issue has been fixed.
-
Short network communication interruptions can cause SRM Server to wait forever. If network communication between the protected and recovery sites is interrupted for less than five minutes, SRM Server can become unresponsive. This issue is caused by SRM Server missing update results and the timeout on the server side of waitforupdate calls from the remote site during the network interruption. This issue has been fixed by introducing client-side timeouts on the waitforupdate call. The default client-side timeout is 5 minutes.
-
Repeated host rescans during test and recovery reenabled SRM 4.1 provided a configurable option, storageProvider.hostRescanCnt, to allow you to repeatedly scan hosts during testing and recovery. This option was absent from SRM 5.0 but has been restored in the Advanced Settings menu in SRM 5.0.1. Right-click a site in the Sites view, select Advanced Settings, then select storageProvider. See KB 1008283.
-
Customization Specification Does Not Configure the Gateway for Red Hat Enterprise Linux 5.x
-
Recovery SRM Server stops unexpectedly after suspension with an error about the recovery plan being on the wrong context
-
Configuring vSphere Replication results in an invalid locale error when using SRM in the simplified Chinese locale with the vCenter Server Appliance
-
SRM stops unexpectedly during startup after starting to check CPU license use
-
Running SRM installer in repair mode deletes the exportConfig.xml
-
IP customization of virtual machines fails with Error Code 14010 IP customization of virtual machines fails with the error There was an error in communication' Error Code: '14010' when it attempts to configure adapters that are not specific to VMware. This has been fixed, and IP customization now skips non-default network adapters and only configures the physical adapter.
-
Test recovery can fail if SRA obtains duplicate snapshot IDs from multiple storage devices Running a test recovery can fail with the error Panic: Assert Failed: "runtimeInfo._results != 0 (Missing results in plan: recovery-plan-10257)" @ d:/build/ob/bora-474459/srm/src/recovery/engine/manager.cpp:1300^M. This issue occurs because storage replication adapters (SRA) allow snapshot IDs to be the same on different storage devices, but SRM requires snapshot IDs to be unique. This issue only affects test recoveries, and does not affect actual recoveries. The issue has been fixed, and SRM now accepts duplicate snapshot IDs.
-
Cannot scroll down network list for recovery plans when many network options are available If more than 30 networks are available in the SRM environment, the complete list of available networks that you can select when you create a recovery plan is not visible. This has been fixed, and you can now scroll down the complete list.
That's the bulk of the SRM 5.0.1 release. Give it a try and let us know what you think!
When the bits are made available you'll be able to find the full release notes at the Site Recovery Manager Documentation landing page. Be sure to check throughout the day!
-Ken
|
