vSphere Replication

[arjanhs]

I have replicated some virtual machines using vSphere Replication, after doing a restart of the vSphere Replicaton virtual appliance, one of them isn't replicating anymore, I got the message:

Permission to perform the operation is denied

I can't remove the replication and I'm unable to change the configuration, how can I solve this problem, so I'm able to replicate the virtual machine again ?

Arjan

[mmarinov]

Do you use standalone VR or as part of SRM?

If the first - does this replication performed within the same VC environment or between different VCs?

By "isn't replicating anymore" does the replication results in error state?... or where do you see this permission error?

[arjanhs]

I'm using the stand alone VR and the replication is done between to different VC environments. The replication has worked for some time cause the initial replication has be done. After a restart of the environment, caused by some storage changes one particular virtual machine isn't replicated anymore.

When i try to change or start the replication of the particular virtual machine, the mentioned message is showed. Other virtual machines which are replicated on the same way, are replicating without problems.

[UmeshAhuja]

Hi,

While installing the SRM client in the VM which is not replication , have you installed with the same user you are using with the SRM , because One of the big limitations to VMware SRM is that the user of VMware SRM must be the same as the user who installed SRM. Therefore, it is better to create a dedicated account (that has administrative permissions) and use that account for installation than to use a generic administrator account or your own personal account

[arjanhs]

I'm using the standalone vSphere Replication, so i haven't installed any client within the VM.

[mmarinov]

Two things come to my mind:

1) permission message is shown the new location of the VM   inherits permission roles that does not include Virtual   machine.replication.Configure replication privilege. For more   information about vSphere Replication Roles see http://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.replication_admin.doc%2FGUID...

2) SDRS involved. VR is not compatible with SDRS thus I'm not sure what could happened actually.

I'd   encourage you to check what is the difference between this VM and some   other that everything is OK from host/datastore perspective.

[arjanhs]

I will check the permissions when I'm on the customer site, currently I'm accessing the vSphere Web client with the local root account instead of a domain account. Will try the same with the domain account to.

The environment is not using SDRS.

I will post the updates when available.

[mmarinov]

Hi, did you have any chance to check the story?

[arjanhs]

The Customer needs to fulfil some additional requirements, I will be on site when they are fulfilled.

[arjanhs]

I have checked the configuratoin and i have used the administraotr role, which includes the needed permission. When doing a reconfigure, the following message apears:

Reconfiguration task at remote site failed for replication group 'DC01' (managed object ID: 'GID-e45d5cb5-2acf-4fb9-8a27-0827f19c9b7c'): task 'HTID-5caab9ba-5783-4407-a4d9-18c34bbe42e7'.

Cause:
VRM Server generic error. Please check the documentation for any troubleshooting information. The detailed exception is: 'Failed to resolve replication target disk for com.vmware.hms.db.entities.DiskEntity@342618238 : replicatedDiskId=RDID-e8c14d79-1213-45d4-b075-cc2a5e3c224a, deviceKey=2001, sourceDiskFileName = [esx10-local] DC01/DC01_1.vmdk, diskUUID = 6000C29c-483f-ffaa-d5c3-e7616a5dbe92, destinationDatastoreMoid = datastore-183, destinationPath = DC01, destinationDiskFileName = DC01_1.vmdk, capacityInKb = 52428800, isExcluded = false, destinationDiskType = thin, adapterType = lsiLogic, isOfflineCopy = false, vm = com.vmware.hms.db.entities.SecondaryVirtualMachineEntity: MoId = HMSVM-42c1d1df-505f-4a08-822e-fa5472f43610, locked by com.vmware.hms.db.entities.LockableEntity@52e06503'.

Is a possible solotution to Reset the Embedded Database, after that i need to reconfigure the replicaton, but will it work after that?

[mmarinov]

I'll dig further into this but it might be a good idea to move this discussion to the vSphere Replication community for better response.

[arjanhs]

It's ok to move the thread, but I don't know how to move it.

From two of the eight replicated machines, II'm unable to change anything, when I try to reconfigure, I got the message access denied.

[mmarinov]

As you started the discussion, you should have move discussion action in your Actions panel on the right.

[arjanhs]

When trying to reconfigure a replicated virtual machine, the message from the picture is displayed.

[mvalkanov]

Hi,

You could grep VRMS logs for NoPermission and see the vCenter Server managed object id and privilegeId. Having the vCenter Server managed object id, you could lookup the object though the vCenter Server MOB https://vc_ip/mob/?moid=<managed object id value> - it could be a datastore, a host, a vm or other.

The logs are located at /opt/vmware/hms/logs/ at the VR appliance.

Please repeat this for the VR appliance at the primary site and for the VR appliance at the secondary site.

Regards,

Martin

[arjanhs]

I have done the grep, but i don't get any usefull information back.

[mvalkanov]

How about grep -C 15 NoPermission hms.log - so that the lines around can be seen?

[arjanhs]

Now i got some output, thanks.

When i access the vcenter server with https://vcenter02/mob/?moid=@6e3a094c no output is displayed

[mvalkanov]

Hi,

Unfortunatelly it appears that the object property logged for the NoPermission does not reveal the real object (its type, value and server uuid). This is improved in the upcoming 2013 release.

From the log excerpts I can say that there is issue in the communication between the two VRM servers (the NotAuthenticated error which inherits the NoPermission).

Please open an SR and attach VR support bundles for both the primary site and the secondary site:

http://pubs.vmware.com/vsphere-51/topic/com.vmware.vsphere.replication_admin.doc/GUID-98AFCDF0-7FBB-...

This might be a known issue that will be fixed in 5.1.1 release. A workaround that can be tried is to not restart the VRM servers at the same time, i.e. restart one of them, wait a couple of minutes and then restart the other (/etc/init.d/hms restart after SSH login at the VR appliance).

If there were other NoPermission errors, you could copy all the .gz files from /opt/vmware/hms/logs/ (for example to /tmp/), gunzip them and grep there:

mkdir /tmp/logs-unpacked

cd /tmp/logs-unpacked

cp /opt/vmware/hms/*.gz .

gunzip *.gz

grep -C 15 NoPermission *.log

cd /tmp

rm -r logs-unpacked

Regards,

Martin

[arjanhs]

What will happen when I do a reset of the database and start over, will it sole me problem, cause it worked for some time?

Is resetting the database and removing the replicated virtual machines enough?