Archive for the ‘VMware’ Category

Just a quick post on a problem I had this week at a customer site running VMware Site Recovery Manager 5 with EMC Celerra and VNX mix.

I actually had everything up and running for a couple of weeks before I logged in again to notice in the “Array Manager” section, both arrays showed status “Error” and when I browsed through to refresh the list of replicated datastores I received the error “SRA command ‘discoverDevices’ didnt return a response”.

I logged a case with EMC and was supplied a new version of the enabler which is not yet available on PowerLink. “EMC_VNX_Replicator_Enabler_for_VNX_SRA_v5.0.11.zip

Once this was installed, I performed a refresh under the devices tab and the errors vanished.

As noted above, everything was working perfectly for a couple of weeks before it broke and it turns out what broke it was the vdm (virtual datamover) replication I had set up post the SRM install. The old 5.0.5 verision of the enabler does not filter vdm replication  sessions and I think its fair to say that it breaks the SRA.

I would recommend anyone running the 5.0.5 enabler or below, request the 5.0.11 version from EMC and upgrade.

Advertisements

This week I’ve been in Sydney Australia doing EMC Recoverpoint training and its seems there have been two big things happen while I’ve been here.

Firstly vSphere 5.0 has been released, I opened my email Monday morning to find a tone of marketing emails from VMware about the launch.

Secondly, it seems Lady GaGa is in Sydney at the same time I am.

I was sitting in my hotel room the other night watching some TV when I heard screaming and shouting, it sounded like a large group of people (mob), at the time I figured it must have been Lady GaGa leaving her hotel room causing mass fan hysteria.

Well today after a mate txt me asking about VMware’s new licensing scheme, I rushed back to the hotel to download the licensing guide and to be honest im now not sure the screaming was GaGa fans, It may well have been VMware customers walking down the street with pitch forks and machete’s protesting the new licensing scheme.

I have had a really quick read over the document and ill be honest, my first impressions I admit were quite cynical, but to be fair im going to read over the document properly and try to get my head around it.

The reason I am cynical about the change initially is because over the last couple of years I have seen a common trend where customers (and myself included) have replaced ESX host hardware with the same number of physical CPU sockets, but doubled or tripled the amount of memory per host. This was something which came about when the Nehalem CPU was released, the result was more logical cores and more VM’s you could run per core.

 

In the meantime if your interested in seeing a couple of good examples of how the changes might not be as bad as everyone’s saying it is, check out this post by Gabe of Gabes’s Virtual World.

When it comes to VMware integration, two of my favorite pieces of software now support the new EMC VNX/VNXe product range.

The first link below is to one of Chad’s latest posts covering the latest release of the VMware vCenter plugin.

The second link goes to PowerLink where you can read more on the new features and support in Replication Manager 5.3 SP2.

EMC vCenter Plugin update-VNX/VNXe support

EMC Replication Manager 5.3 SP2 VNX/VNXe support

I was working on a VMware SRM with EMC CLARIION implementation when I come across another gotcha and thought id post about it.

I had to change the IP Address’s for the CLARIION management ports at the DR site and with doing so I went into SRM and edited the array manager configuration so the DR array information used the new management IP Address’s for SPA and SPB.

After performing a rescan of the storage and getting a hideous error, I went looking in the logs and found the following error.

The actual error “Operation denied by Clariion array – You are not priveliged to perform the request” is rather misleading, it looks like the CLARIION is refusing to authenticate the user ( which has been working for months )

After a bit of poking around on PowerLink I found an article which listed the exact same error and listed this as a known issue when changing the IP’s for the SP management ports.

The Fix

  1. Stop the VMware SRM service
  2. Rename the symapi_db.bin in C:\Program Files\VMware\VMware vCenter Site Recovery Manager\scripts\SAN\MirrorView SRA\
  3. Start the VMware SRM service

After doing this I performed a rescan and everything worked as expected.

Looking at the error above it looks like the CLARIION is not authenticating the user “Admin” but im guessing the symapi_db.bin file still references the old management IP’s which no longer exist, and because of this the SRA returns with an authentication error.

Working for an EMC Partner and being involved in Beta testing means I have to be careful not to blog about anything which could violate the Non Disclosure Agreement we sign as part of the Beta program.

Considering the following information can be found in the NetWorker Community forums, I can say the following;

  • NetWorker 7.6 SP2 will support VADP with change block tracking
  • The Beta program has been delayed till late January
  • The final release according to EMC is still due Q1 in 2011

Since Celerra NFS datastores have become supported by both Replication Manager and VMware Site Recovery Manager, I’ve been migrating Celerra customers off iSCSI to NFS mainly because of the overhead needed to facilitate Snapshots/Replication of iSCSI luns.

In versions prior to 5.3 you needed to have a Linux host configured as the VMware Proxy to allow snapshots of NFS datastores, but the 5.3 release now supports this on a Windows operating system.

 

Ive come across the same problem at a number of customer sites recently, so I thought this might be something worth posting about.

The problem typically comes about as customers who’ve traditionally had vCenter running on a 32bit Operating System, now move to a x64bit Operating System to support vCenter 4.1 which enforces x64 bit architecture.

Now the actual root cause of the problem is the NetWorker 64bit client does not have the necessary nsrvim binary which is responsable for communicating with vCenter.

The good news is the fix is actually very simple, within the properties of the vCenter server youve configured in the NetWorker Management Console, just change the command host to any other networker system running a 32bit version of the client ( 7.5 and above ).

Typically the command host and the end point field have the same server configured, but as you can see from the screenshot below Ive just changed this to one of my test clients named “Client1”

 

Save the changes and away it goes again. Hope this helps.