Biliana's Posts

vSphere Replication can use vCenter 5.5 as long as the vCenter is registered to SSO which is 6.0 version.
This is a supported configuration. Remember that if you would like to use new VR features such as Linux quiescing or Network compression, you would need to have ESX 6 at source site as well.
Hi, Here is the procedure: Let's say that you have replication configured from A->B. 1) To remove site A's knowledge about this replication you can select the replication entry in Outgoi... See more...
Hi, Here is the procedure: Let's say that you have replication configured from A->B. 1) To remove site A's knowledge about this replication you can select the replication entry in Outgoing Replications view, Invoke Stop action and then on the popup select "Force stop" checkbox and click OK 2) To remove site B's knowledge about this replication you can select the replication entry in Incoming Replications view, Invoke Stop action and then on the popup select "Force stop" checkbox and click OK You can also have a look at this documentation page: vSphere 5.5 Documentation Center Having performed that you can try to configure a new replication. Hope this helps!
Which version of vSphere Replication are you using? In VR 5.5 and above, you can force stop any leftover-ed replication entry before attempting to configure a new replication.
Thanks for your reply. You said that the VRA is on a cluster, is thatcluster HA-enabled? Because in case HA needs to restart the VRA on another host, it does this through the ESX host and this mi... See more...
Thanks for your reply. You said that the VRA is on a cluster, is thatcluster HA-enabled? Because in case HA needs to restart the VRA on another host, it does this through the ESX host and this might have cleared out the OVF environment. And at at the same you will still have a working configuration until you start the upgrade or try to perform any operation through VAMI configuration page. To be on the safe side, I think that before upgrade, you can do power off and then power on the appliance (simple reboot is not enough) to make sure that the OVF env is recreated.
My suspicion is that before upgrade, the OVF environment of the appliance has somehow been lost. For example this may happen if you have powered on the appliance directly through the ESXi host wh... See more...
My suspicion is that before upgrade, the OVF environment of the appliance has somehow been lost. For example this may happen if you have powered on the appliance directly through the ESXi host which must be avoided, or the host on which the appliance runs has been removed and then added back to the inventory. The OVF environment is stored in the VC database and if lost the appliance cannot authenticate with its vCenter Server. If you happen to see this again, I can advise you to open a SR and provide logs for investigation.
When you would like to uninstall VRA and deploy a new appliance, you should always follow these steps: 1) Unregister from vCenter server in the VAMI 2) Power off the appliance and then delete... See more...
When you would like to uninstall VRA and deploy a new appliance, you should always follow these steps: 1) Unregister from vCenter server in the VAMI 2) Power off the appliance and then delete from disk. This way when you deploy a new VRA, you will not get a message that there is always an appliance registered to that vCenter Server.
Hi, What is the version of vSphere Replication that you are using? Could you check if your disk is of supported size? Is it an RDM file? Could you also check what is the cause of the failing c... See more...
Hi, What is the version of vSphere Replication that you are using? Could you check if your disk is of supported size? Is it an RDM file? Could you also check what is the cause of the failing configure replication task?
Could you articulate more with examples on what use cases you would like to address with automation?
Hi, You can select several VMs at once and use the multi-VM configuration wizard to setup them for replication all at once.
Yes, you are correct, this is a discrepancy in our doc that we will resolve soon. Thanks for your feedback.
Hi, From your post, I see that you are using VR with SRM on top of it. What you can do is to configure the VM for replication and exclude that specific disk for replication. Then, when you ad... See more...
Hi, From your post, I see that you are using VR with SRM on top of it. What you can do is to configure the VM for replication and exclude that specific disk for replication. Then, when you add the replicated VM in SRM protection group, you can Configure protection properties and detach the disk.
Have you upgraded the vCenter Server to 5.8 ? If so, it may have changed its certificate and VR appliance needs to be powered off and then powered on in order to get the new certificate. See vSph... See more...
Have you upgraded the vCenter Server to 5.8 ? If so, it may have changed its certificate and VR appliance needs to be powered off and then powered on in order to get the new certificate. See vSphere Replication is Inaccessible After Changing vCenter Server Certificate in the admin guide.
Are you using standalone version of VR , or you have SRM on top installed? When replicated VMs with VR are included in SRM protection groups, the Recover option is greyed out in the vSphere Repli... See more...
Are you using standalone version of VR , or you have SRM on top installed? When replicated VMs with VR are included in SRM protection groups, the Recover option is greyed out in the vSphere Replication UI. Is that your case?
Hi, If you have successfully recovered your VMs from site B to site A, then you can safely remove the replication using the Remove replication button. This will just clear your replication. It... See more...
Hi, If you have successfully recovered your VMs from site B to site A, then you can safely remove the replication using the Remove replication button. This will just clear your replication. It won't remove the running recovered VMs at site A.
Well, if you want to be able to recover at all times, the best option is to have another VCenter/VR appliance acting as your recovery site. The second vCenter Server can manage the hosts/clusters... See more...
Well, if you want to be able to recover at all times, the best option is to have another VCenter/VR appliance acting as your recovery site. The second vCenter Server can manage the hosts/clusters to which you are replicating. The main assumption in a two-site setup is that your recovery site is “far enough” so that disaster events that happen on the primary site won’t affect the recovery site. In the case where a single vCenter is managing several hosts/clusters and you replicate between them, you can recover in situations  such as host/cluster errors, VM errors, network outages,etc. Recovering without vCenter Server/VR appliance in a single setup is not supported. There are posts on Internet describing process of  registering manually the replicated files on the target but all this is highly error-prone and officially unsupported. You may replicate any VM with VR, VR cares only for the disks changes, not what is running on the VM. If appliances are lost you would need to redeploy and configure them from scratch.
Hi, You can leverage vSphere Replication in different topologies: 1) The classic two sites setup, where each site is geographically separated from its pair site. This setup requires a vCen... See more...
Hi, You can leverage vSphere Replication in different topologies: 1) The classic two sites setup, where each site is geographically separated from its pair site. This setup requires a vCenter Server and a vSphere Replication Appliance at both sites. When the primary site faces a disaster event, the recovery can be performed on the secondary site. 2) Single vCenter setup, in which you have several hosts/clusters managed by a single vCenter Server and you are replicating VMs between your hosts/clusters. In that case when one of the hosts “dies”, you could perform recovery on another host. This requires that your vCenter Server and VR Appliance are operational. The vSphere Replication Appliance consists of both a vSphere Replication Management Server and a vSphere Replication Server. The latter listens for the replication traffic on the target site and applies it on the target datastores. In an increased scale you can deploy up to 9 additional vSphere Replication Server appliances  to distribute the replication load. In a single site setup, you may have also additional vSphere Replication Servers deployed  for optimization purposes, so that they are  “closer” to the target datastores. After you have performed successful recovery and your primary site is back, you can power off your VM on primary site (if it is running), remove it from inventory (but do not delete its disks) and then configure replication of the recovered VM to be replicated back to the original site using its original disks as replication seeds. In that way, VR will just copy the blocks that have been changed on the recovered VM since the disaster happened and you will reduce the traffic spread over. Hope this hleps!
VR Appliance is an extension to vCenter Server. If your hosts are both managed by a single vCenter Server, then you would need only just VR appliance and you can replicate VMs between your hosts.... See more...
VR Appliance is an extension to vCenter Server. If your hosts are both managed by a single vCenter Server, then you would need only just VR appliance and you can replicate VMs between your hosts. If your second host is managed by a different vCenter Server you will need VR appliance registered at each vCenter Server. VR is storage agnostic - that means you could replicate between one type of storage on one site to another type of storage on the other site (e.g iSCSI to local storage).
If you are using vSphere Replication without SRM on top of it, Test Recovery is not available. The process you could follow in case you would like to keep your primary site online: 1) Perform ... See more...
If you are using vSphere Replication without SRM on top of it, Test Recovery is not available. The process you could follow in case you would like to keep your primary site online: 1) Perform Recovery using the second option (Recover with latest available data). In this way you would not need to power off source VMs and your primary site will be online. 2) After recovery is complete, stop the replications (which will be in Recovered state) 3) Power off recovered VMs, unregister them from VC inventory, but keep the disk files intact. 4) Manually configure all replications using the disks that were left over as initial seeds. This will cause only changes to be synced. To ease step 4, you could use vSphere Replication multi-vm configuration wizard. Just make sure that on the target datastore each disk that will be used as initial copy is put in the folder with VM name. Then, you could try to configure all VMs at once, performing searching for seeds and confirming to use them.
You might also have a look at that thread: Re: SRM replication sync time