The Basic Setup is:
- 2x vCenter 5.5 in linked mode wíth 2x srm 5.5
- vcenter service starts with domain-account
- srm service starts with local service-account
- both sites are connected with administrator@vsphere.local
- folders, nfs-disks, network, ... is configured for both sites (inventory-mapping done)
- vsphere replication is active and works fine
The Error:
If I try to make a protection group and protect a VM (vSphere-Replication based) the process stops at 20%,
the SRM service stops working and a MiniDump is generated.
The last logfile entries are attached.
The in my opinion important lines are:
error 'InventoryMapper' opID=545DC761-00000026] Could not retrieve primary folder information for VM 'vm-157'
warning 'InventoryMapper' opID=545DC761-00000026] Cannot make recommentations for VM 'vm-157' because failed to retrieve VM location properties
error 'Replication' opID=545DC761-00000026] Primary Folder Missing for VM 'vm-157' while querying protection group 'protection-group-3008'
error 'Replication' opID=545DC761-00000026] Primary resourcepool missing for non template VM 'vm-157' while querying protection group 'protection-group-3008'
Could please anyone have an idea on what went wrong here?
It was me - stupid self - but also a nasty Bug in SRM 5.5
I have some VMs configured with access rights only for me (my AD-domain account) and for all others including all at vsphere.local NO ACCESS.
So it's correct that SRM cannot read out their inventorymappings and so not being able to protect them.
I gave the SRM acount access rights and the error was gone.
But: That the SRM-service itself dies on that isn't an behavior I would expect in this situation.
Seems to me being a bug.
... solved with workaround ...
It was me - stupid self - but also a nasty Bug in SRM 5.5
I have some VMs configured with access rights only for me (my AD-domain account) and for all others including all at vsphere.local NO ACCESS.
So it's correct that SRM cannot read out their inventorymappings and so not being able to protect them.
I gave the SRM acount access rights and the error was gone.
But: That the SRM-service itself dies on that isn't an behavior I would expect in this situation.
Seems to me being a bug.
... solved with workaround ...