All Posts

I'm trying to setup SRM replication on a single VM and receive this error whn configurating the final step of replication:   Configuring Virtual Macince for Replication....failed. VRM Server Generic Error: Please check the documentation for any troubleshooting information. The detailed exception is: 'java.lang.NullPointerException'   I have rebooted VRMS servers at both sites, remove the VM from inventory and added it back as a couple of troubleshooting steps but still have same errors on any VM I try to configure to replicate.   Anyone else have this issue before?

Hello experts,   In SRM DR options, can we retain the same IP address during VM failover to the DR site? If we are already running Google Cloud VMware Engine and looking at different disaster recovery options just exploring at this point the idea for VMware Engine workloads is to create a new VMware Engine cluster in a different Google Cloud Region and the question is... Is it possible to maintain the same IP address for the VMs if it's restored in the new cluster? I suppose that we need to configure the "same network" or a network extension between both clusters and should work right?   Regards PK  

So i have configured and replicated a LUN on a HPE 3PAR Storage. Now the first thing i notice in the SRM Array Pairs Tab under "DISCOVERED DEVICES" the datastore is invisible (as shown in the attached screenshot), wonder where i went wrong. How do i get the replicated datastores to be visible?

I have been trying to find some documentation on the fact that SRM appliances (8.6) currently lives on the Photon 3.0 platform and that OS is EOL In march 2024.  Does anyone know if there is a patch to a higher version or is it supported still as is?

Hi, I'm looking to run a custom srm script and would appreciate ay advice Scenario: SQL VMs with in-guest iscsi configured for wsfc volumes, srm will protect and failover the VMs of course but I need to synchronise the handover of the in-guest volumes. Storage: Nimble HF20 vCenter: 7 Update 3 SRM: 8.6 If anyone has any experience of doing something similar and could share that would be amazing. I think I know the commands to send to the storage array to 'handover' the volume collection but not exactly sure how to do this when writing a custom script for srm. I assume a bash script will suffice and have read the srm documentation on this. https://docs.vmware.com/en/Site-Recovery-Manager/8.7/com.vmware.srm.admin.doc/GUID-75F89A6E-87F1-45D5-B2F1-15DE991F7A7F.html 

Hi all Anyone know SRM can support the storage use different type of transport in protected and recovery site? Say protected site use FC between the ESXi and storage, but recovery site use iSCSI? Or it depends on the SRA? Best regards   Alex

Hi all, My SRM license capacity shows 500 VMs on bothe vCenters (License tab).  After configuring the SRMs and assigning the asset license the capcity (License --> asset --> solution) shows 75.   Can i have some directions or to understand why 75 instead of 500?   Thanks  

I'm running SRM 8.7.0 Build 22359471 and am trying to install a new certificate. I would use the built-in CSR generation, but it requires specifying the IP address as an alternate name and our InCommon certificate request process won't accept that. Since SRM won't let me generate one without it I have to do it manually. We've moved to using ECDSA private keys. I generate the key and CSR using the following method: openssl ecparam -out ecdsa_key.pem -name secp384r1 -genkey && openssl req -new -key ecdsa_key.pem -nodes -out ecdsa_csr.pem -subj "/C=US/ST=REMOVED/L=REMOVED/O=REMOVED/OU=REMOVED/CN=example.com" Once I receive the certificate, I create the file: openssl pkcs12 -export -out example.com_2023.p12 -inkey ecdsa_key.pem -in example.com.pem However, if I try to install this in SRM I get the following error: "The certificate does not have the minimum required key length." I know the SRM 8.7 documentation states "The private key in the PKCS #12 file must match the certificate. The minimum length of the private key is 2048 bits." but that's with RSA.