mvalkanov's Accepted Solutions

Hi, You are correct - in current SRM/VR releases it is not possible to choose the VR server in the reprotect dialog and VRMS chooses the one with least number of replications on it. You can e... See more...
Hi, You are correct - in current SRM/VR releases it is not possible to choose the VR server in the reprotect dialog and VRMS chooses the one with least number of replications on it. You can either: A. Configure manually the replication in the reverse direction by using VR UI and explicitly choose the VR server. SRM on re-protect will discover the already configured replication in the reverse direction and use it in the protection group. or B. Re-configure manually the replication after the initial sync has been started after the reprotect. You don't need to wait for the sync to complete in order to switch to a different VR server. Both options use the VR UI and the configure / re-configure is for one VM at a time. I'm not sure if the vRO plugin for VR exposes functionality for moving replications from one VR server to another. Regards, MArtin
Hi, Current VR versions generally require matching major version of vCenter. For example - if vCenter is upgraded to 6.5, then VR must also be upgraded to 6.5. The interop matrix can be check... See more...
Hi, Current VR versions generally require matching major version of vCenter. For example - if vCenter is upgraded to 6.5, then VR must also be upgraded to 6.5. The interop matrix can be checked at VMware Product Interoperability Matrixes Please note that current VR versions also require matching major version at source site and at target site. Underlying replications will continue during upgrades, but management functionality will be restore only after the major versions match across the source site and target site and between VR and vCenter. Regards, Martin
Hi, Information on the MPITs is available only at the target site VR server (hbrsrv) and thus is not available through source ESXi vim-cmd hbrsvc. The VRMS API is not public. It is possible t... See more...
Hi, Information on the MPITs is available only at the target site VR server (hbrsrv) and thus is not available through source ESXi vim-cmd hbrsvc. The VRMS API is not public. It is possible to browse available PITs using that API but through Managed Object Browser - still this would be manual. I'm not sure if the vRO plugin for VRMS exposes this or not, but should be easy to implement - perhaps you can file a feature request for that. About resizing replicated VMDK - the VR server uses a chain of redolog-based snapshots at the target site - a base disk and each delta stored as a separate child disk. This format of "redolog-based snapshots" does not allow different sizes of the different PITs. This is planned to be addressed by a new vSphere snapshot format (quickly looking at Internet this seems to be not yet publicly announced). So short answer is no - the old PITs would be lost. Unless you do a recovery without power on and clone the recovered VM, before using its disks as initial seed for the new replication (w/ resized disk). Regards, Martin
Hi, VR 6.0 and next support file-system level quiescing for Linux guests. See "Linux guest OS quiescing: introducing Linux guest OS quiescing service to provide file-system level crash consis... See more...
Hi, VR 6.0 and next support file-system level quiescing for Linux guests. See "Linux guest OS quiescing: introducing Linux guest OS quiescing service to provide file-system level crash consistency to replicated Linux-based VMs." at VR 6.0 release notes - VMware vSphere Replication 6.0 Release Notes See also "Linux Quiescing Support" section at Interoperability Pages for vSphere Replication 6.5 after selecting category "Guest OS Quiescing Support" at the dropdown. AFAIK the mechanism is freeze and thaw. It has been supported for backup tools (VDP and similar) and with VR with version 6.0 and next. Earlier VR versions (before 6.0) did not have such integration. I have filed feedback on KB 2041909 to be updated. Regards, Martin
Hi, You can update the incorrect value using the vSphere Web Client: vCenter -> Manage -> Settings -> Advanced vCenter Server Settings -> Edit -> VirtualCenter.FQDN Afterwards, power off t... See more...
Hi, You can update the incorrect value using the vSphere Web Client: vCenter -> Manage -> Settings -> Advanced vCenter Server Settings -> Edit -> VirtualCenter.FQDN Afterwards, power off the VR appliance and power it back on. Once the correct VirtualCenter.FQDN value appears in the ovfEnv.xml, open the VAMI UI, verify the vCenter address is correct, hit "Save and Restart" and everything should be fine. Regards, Martin
Hi, If you take the route with deploying fresh VR appliances after the vCenter upgrade - this will definitely work and save you from entering the sql commands. However, please note that the n... See more...
Hi, If you take the route with deploying fresh VR appliances after the vCenter upgrade - this will definitely work and save you from entering the sql commands. However, please note that the new VR appliances will automatically disable the old replications and when you configure the new replications, there will be some period of initial full-sync. If you use the existing .vmdks at the target site as seeds only checksum will be calculated, so the actual data transfer won't be much, but be prepared to wait for the reads for the checksum calculation. > I assume that I can't simply get the ISO for VR 6.1.1 and attempt an upgrade from the current state, but I guess I should confirm, just in case there is some kind of magic which will allow that. You first need to fix the current state before attempting upgrade to 6.x (or whatever new release). To open the SQL prompt: 1. Establish SSH session to the appliance (I don't remember if SSH is enabled or disabled by default at VR 5.8, but there should exist documented steps for enabling ssh). It will be much more easy to type the sql commands in ssh session compared to using the VM console. 2. Type /opt/vmware/vpostgresql/current/bin/psql -U vrmsdb 3. Enter each of the upgrade statements one by one followed by semicolon (;). Be careful to not paste multiple statements at once, as some of these are changing the schema, and if something fails you can retry. It might be helpful to have a second SSH session opened to browse through the sql file, or to copy it with scp and copy each individual statement via some text editor. I haven't tried if copying all the statements to a new file (without the line insert into PendingChangeRecordEntity...) and passing that file to psql would work or not. 4. Type \q to exit the sql prompt. 5. Disable the ssh access if necessary. Regards, Martin
Can you try from another browser (or clear cache and cookies)? There is a known issue with the VAMI UI pages not always automatically refreshed after upgrade.
Hi, For the problematic VR appliance, can you check the content of /opt/vmware/etc/vami/ovfEnv.xml file? Normally there is deployment_scenario property is this file and this is what determine... See more...
Hi, For the problematic VR appliance, can you check the content of /opt/vmware/etc/vami/ovfEnv.xml file? Normally there is deployment_scenario property is this file and this is what determines how the appliance should behave - as combined (VRMS+VR server+embedded DB) or VR-server-only one. If the ovfEnv.xml file is empty, please double check that the appliance has been deployed and powered on through vCenter. If the appliance is powered on through ESXi, the OVF environment will be empty and VRMS won't work. This is covered in the troubleshooting section of the admin guide. If the ovfEnv.xml is non-empty, perhaps you should file a SR and have VMware support team assist. Regards, Martin
Hi, With all VR releases so far, for vCenter to vCenter replications, VRMS version must match at source and target site (only this configuration is officially tested and supported), for exampl... See more...
Hi, With all VR releases so far, for vCenter to vCenter replications, VRMS version must match at source and target site (only this configuration is officially tested and supported), for example: 1.0.x <-> 1.0.x. 5.1.x <-> 5.1.x. 5.5.x <-> 5.5.x. 5.6.x <-> 5.6.x. 5.8.x <-> 5.8.x. 6.0.x <-> 6.0.x. 6.1.x <-> 6.1.x. For vCenter to vCloud Air DRaaS replication, there is no such restriction. For both vCenter to vCenter and vCenter to vCloud Air DRaaS, based on source ESXi version and target VR server version different replication capabilities are supported. Regards, Martin
Hi Aleksandar, Which VR version you are using? With recent releases (VR 5.6 and next) there is option for single-sided force stop and you should be able to delete the orphaned incoming replica... See more...
Hi Aleksandar, Which VR version you are using? With recent releases (VR 5.6 and next) there is option for single-sided force stop and you should be able to delete the orphaned incoming replications at site B using the UI. For all releases you can also use the VR MOB (managed object browser). If you know the replication identifier (GID-....), you can follow the steps at VMware KB: Enabling Replication for a virtual machine may fail due to stale replication group GIDs in the VRM databa… to invoke the destroy task. To get the GID-.... identifier for all incoming replications at site B, open: https://vrms_address:8043/mob/?moid=replica-manager&method=HmsReplicaManagerGetIncomingReplicationExtendedInfoPage&vmodl=1 using vCenter server credentials and set: - site, sorters and filters to empty value - start to 0 - count to 2000 Regards, Martin
Hi, Today VRMS requires the vCenter server versions at source site and target site to match (e.g. 5.1.x <-> 5.1.x, 6.0.x <-> 6.0.x). Perhaps you could temporarily upgrade the vcenter 5.1 to 6... See more...
Hi, Today VRMS requires the vCenter server versions at source site and target site to match (e.g. 5.1.x <-> 5.1.x, 6.0.x <-> 6.0.x). Perhaps you could temporarily upgrade the vcenter 5.1 to 6.0 at the old site and then configure the replications. Regards, Martin
Hi, Thank you for the feedback, the admin guide content will be updated. ESXi < 5.5 supports replicated disks with size below 2032GB. ESXi >= 5.5 supports replicated disks with size below ... See more...
Hi, Thank you for the feedback, the admin guide content will be updated. ESXi < 5.5 supports replicated disks with size below 2032GB. ESXi >= 5.5 supports replicated disks with size below ~ 62TB. The VR 5.5 admin guide also contains the same content, as the one you quoted - see vSphere Replication Limitations The VR 5.5 release notes mentions the 62TB limit: https://www.vmware.com/support/vsphere5/doc/vsphere-replication-55-release-notes.html vSphere Replication supports a maximum disk size of 62TB. Regards, Martin
Hi, VR 5.5.x and 5.8.x is compatible with vCenter 5.5.x. Following links on vmware.com, these are the download pages: For VR 5.8.x: https://my.vmware.com/web/vmware/details?downloadGrou... See more...
Hi, VR 5.5.x and 5.8.x is compatible with vCenter 5.5.x. Following links on vmware.com, these are the download pages: For VR 5.8.x: https://my.vmware.com/web/vmware/details?downloadGroup=VR5802&productId=353&rPId=7710 For VR 5.5.x: https://my.vmware.com/web/vmware/details?productId=353&rPId=7710&downloadGroup=VR5514 The .zip file contains the .ovfs (of the combined VR appliance and VR-server-only appliance) and two .vmdks. The .iso image contains the same files and additionally .rpms for CDROM-based upgrade from previous releases. The OSS .tar.gz file that you have found are the sources of the base OS packages and other open source / third party packages, whose license requires VMware to publish their sources along with VR bits. Regards, Martin
Hi, There is internal interface that allows you to do this. Please contact VMware support team for assistance. Go get the current "recovered by" value: https://vrms_address:8043/mob/?moid=... See more...
Hi, There is internal interface that allows you to do this. Please contact VMware support team for assistance. Go get the current "recovered by" value: https://vrms_address:8043/mob/?moid=recovery-manager&method=HmsRecoveryManagerGetGroupsRecoverySolution&vmodl=1 To reset the "recovered by" value to VR: https://vrms_address:8043/mob/?moid=recovery-manager&method=HmsRecoveryManagerSetGroupsRecoverySolution&vmodl=1 Invoke the method after replacing MOID with the GID-... value of the replication and clear the value (empty string) for recoveredBy property. To retrieve the GID-... value - either look at the names of the replica files at the target datastores, or check GroupEntity table in VRMS DB. To get SQL prompt to the embedded VRMS DB - use /opt/vmware/vpostgres/current/bin/psql -U vrmsdb and \q to quit Please note that all of the above is officially unsupported and might change with different VR releases. Regards, Martin
Hi Jared, Yes, you can use VR to create copies of the original VMs into another vCenter server inventory. Once the initial full-sync completes, all changes from the original VMs will be repli... See more...
Hi Jared, Yes, you can use VR to create copies of the original VMs into another vCenter server inventory. Once the initial full-sync completes, all changes from the original VMs will be replicated based on the RPO settings. Once you decide to stop the replication, you can first invoke "Recovery wizard" and bring up the replicated files as VMs in the target vCenter inventory. Power on step is optional in the "Recovery wizard". Please make sure that you use the latest available sync-point - this won't touch the original VMs. After the "recovered" VMs are registered in the target vCenter inventory, the replications will turn into "Recovered" status. Then you can safely stop the replication from the UI and from this moment on, there won't be anything VR related to the VMs or in the UI. VR today does explicitly disconnect the network cards of the recovered VMs. There is no sysprep integration. Perhaps you can build your own customization using Powershell or similar. SRM offers some customization options, but requires separate license. Regards, Martin
Hi, There is no need to completely reset VRMS database. If you know the GID-... value of the orphaned replication, you can use the VRMS MOB (https://vrms_address:8043/mob/?moid=GID-...&vmodl=... See more...
Hi, There is no need to completely reset VRMS database. If you know the GID-... value of the orphaned replication, you can use the VRMS MOB (https://vrms_address:8043/mob/?moid=GID-...&vmodl=1) to invoke the destroy method - this is single sided replication removal at either source or target site. If you don't know the GID-... value, it can be looked up from VRMS DB or log files. Please file a SR for assistance. This procedure is already documented in internal KB articles and VMware support help will assist: Internal KB article 2056086, section "Cannot replicate virtual machine as there is another virtual machine with the same instance UUID" and also internal KB article 2060751. The admin guide topic will be updated as it is confusing as of now by only suggesting to reset the DB. Regards, Martin
Hi, Please open a SR to get assistance with adding additional disk space and moving the embedded vPostgres DB to a partition with additional space. Once the DB is up and running, the DB table... See more...
Hi, Please open a SR to get assistance with adding additional disk space and moving the embedded vPostgres DB to a partition with additional space. Once the DB is up and running, the DB tables can be analyzed to see the root cause for the full DB. In hms-configuration.xml file there is a setting hms-eventlog-maxage that can be lowered (for example to 604800, which is 7 days), in order to limit old data kept in IncomingEventLogEntity and OutgoingEventLogEntity tables. Without dump of the DB it would be hard to know what is the cause of the full DB, but there have been reported issues with highly loaded environment and occasional VR server disconnects that have led to large number of notifications between VRM servers and that filled the IncomingEventLogEntity and OutgoingEventLogEntity tables. Regards, Martin
Hi, Which VR version are you using? There have been fixes for support of custom port for the vCenter reverse proxy. Also, if using VR <5.8, which UI are you using to configure the VR pairing?... See more...
Hi, Which VR version are you using? There have been fixes for support of custom port for the vCenter reverse proxy. Also, if using VR <5.8, which UI are you using to configure the VR pairing? C#-based one or the one in the WebClient? Details for the failure will likely be available at VRMS logs at source site (/opt/vmware/hms/logs/hms.log) and/or vsphere-client-virgo.log (if pairing is being done via the WebClient) at vCenter machine. Regards, Martin
Hi, It is not different from what I described. Recovery is driven by VRMS at the target site. If target site VRMS is down - operation can not be invoked from UI, there is no one to tell VR... See more...
Hi, It is not different from what I described. Recovery is driven by VRMS at the target site. If target site VRMS is down - operation can not be invoked from UI, there is no one to tell VR server to consolidate the redologs on top of the replica base disks and no one to register the resulting .vmx and .vmdks as VM in vCenter inventory. Regards, Martin
Hi, If doing svMotion of the appliance to another datastore - there won't be any issues. If you are doing cold migration and also changing the host - you might need to manually configure Netw... See more...
Hi, If doing svMotion of the appliance to another datastore - there won't be any issues. If you are doing cold migration and also changing the host - you might need to manually configure Network Protocol Profile (IP pool), if the network is changed, before being able to power on the appliance. Regards, Martin