Thursday, June 30, 2016

Unable to Detect NFS Datastores in VMware SRM

Setup


VMware vCenter 5.1 Update 3a
SRM 5.1.3
ESXi 5.1 Update3

Issue


When trying to configure SRM we were unable to detect NFS datastores

Analysis


Upon analysis we figured out that there was mismatch between NetApp SRA configuration and ESXi. NetApp  SRA had IP Address of NFS Server and Datastores were mounted using host name



Resolution


If NFS datastores need to be protected through SRM, then you need to enter the NFS address of your Storage Array. This Address should exactly match the address of NFS server, which you used to access NFS volumes on your ESXi hosts. SRM cannot detect the NFS datastores, if you use host name on ESXi hosts and IP address on SRA configuration

Unable to Protect VM with Snapshots in VMware SRM

Setup


VMware vCenter 5.5 Update 3a
SRM 5.5.1
ESXi 5.1 Update3

Issue


When trying to Configure Protection for the VM it goes till 99% after getting an error. The error details

Internal error: Received unexpected exception from multi-site operation.

Analysis


We tried usual steps such as

  • Restarting SRM Service/Server
  • Ensure it is not licensing issue
  • VM Hardware version upgrade from 8 to 9


Upon log analysis we found Customer had 90 snapshots for the VM which was for SQL. Surprisingly it didn’t appear under normal place of Right Click Manage Snapshots however when we check datastore folder it appeared there


Resolution


As per VMWare ESXi only supports 32 levels of snapshot on a VM however VM in question had 93 levels of snapshots, and this is making it fail to be protected on SRM.  We were able to protect VM once snapshots were consolidated



VMware SRM Recompute Device Groups Occurence

Setup


VMware vCenter 6.0 Update 1b
SRM 6.1
NetApp SRA 2.1P1

Issue


We have upgraded DR vCenter Server to 6.0 U1b and DR SRM Server to 6.1. After upgrading and configuring SRM we observed that Production vCenter keeps generating Re-compute Device Groups tasks every 30 seconds

Analysis


The re-computes are triggered by the SRA. Under normal circumstances Datastore Group computation is triggered by the following events:

  • Existing VM is deleted or unregistered
  • VM is storage vmotioned to a different datastore
  • New disk is attached to VM on a datastore previously not used by the VM
  • New datastore is created
  • Existing datastore is expanded


In our case none of this was happening, there are APD for other datastores in PROD vCenter however it is not included in the SRM Configuration. SRM is configured with single datastore in Array Managers Volume include list

I am wondering if anyone else has come across similar issue like this

VMware SRM Fault

Setup


VMware vCenter 5.5 Update 3
SRM 5..8.1

Issue


Protection Group summary page shows 25 VMs as not configured. When checked in the in protection group, VMs with warnings are not getting displayed.

Analysis


Upon troubleshooting with VMware Support, we got notified that they suspect this might be a defect in the software that we will have to escalate to engineering. Engineering confirmed this to be fault and working on developing hot patch

I am wondering if anyone else has come across similar issue like this


Tuesday, June 28, 2016

VMware SRM Test Failover/ Planned Migration Fails with Error - There are not enough licenses installed to perform the operation (2145522)

Symptoms
· Running a Test Recovery from Protected and/or Recovery site fails
· Running a Plan Migration  from Protected and/or Recovery site fails
· Even after adding the license to the vCenter Server, you see error:
There are not enough licenses installed to perform the operation.
Cause
This issue occurs when a license is not assigned to an individual asset. 
If you have re-installed vCenter Server or never used the SRM from Recovery to Production site, the license for an SRM asset can be unassigned. 
Resolution
To resolve this, ensure the key is assigned to the SRM solution in the vCenter Server for re protecting the virtual machines on both production and disaster recovery site. You have to login to each vCenter separately and check.


The procedure to assign the license if not available is:

For 5.x C# Client:
1. In the vSphere Client, select Home > Administration > Licensing.
2. Click Manage vSphere Licenses.
3.  Click Next to navigate to the Assign Licenses page.
4. Click the ESX, vCenter Server, or Solutions tab to display the available assets.
5.  Select the assets to show.
6.  In the Asset window, select one or more assets to license.
7. To select multiple assets, use Ctrl-click or Shift-click.
8.  In the Product window, select an appropriate license key and click Next.


For 6.x Web Client:
1.  In the vSphere Client, select Home > Administration Licensing.
2. Click the Assets tab.
3. Click Solutions session.
4. Identify and select the SRM extension.
5.  In the All Actions Menu, select Assign License.
6. In the Assign License window, select an appropriate license key and click Next.    

If the license key you assign has a strong limit, the license capacity must be greater than or equal to the required license use for the asset. Otherwise, you cannot assign the license key. Check the EULA of the license to determine whether it has a strong limit.

Note: If you are Reprotecting your virtual machined, ensure that this has been done for both Protected and Recovery vCenter Servers.


Friday, June 3, 2016

Microsoft Convenience Update and VMware VMXNet3 Incompatibilities

Microsoft recently released a “Convenience Update” patch for Windows 7 and Windows Server 2008 R2 SP1. This update has incompatibility issues with virtual machines running on the VMware vSphere virtualization platform. This incompatibility is confined to one specific configuration scenario – It impacts VMs that use the VMware VMXNet3 virtual network adapter type

Here is the incompatibility issue as described in Microsoft’s announcement of the Update:


Known issue 1


Symptoms


A new Ethernet vNIC may be created with default settings in place of the previously existing vNIC, causing network issues.  Any custom settings on the previous vNIC are still persisted in the registry but unused.

Resolution


To resolve this issue, uninstall the convenience rollup.

Status


Microsoft is investigating this issue to determine proper course of action with VMWare. To resolve this issue uninstall the convenience rollup. Further information will be posted here as the investigation continues.