mvalkanov's Posts

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, You are correct. When "test failover" is executed, the replica disk snapshot hierarchy is forked. The test bubble VM operates in a separate branch compared to the ongoing replication. On... See more...
Hi, You are correct. When "test failover" is executed, the replica disk snapshot hierarchy is forked. The test bubble VM operates in a separate branch compared to the ongoing replication. Once "test cleanup" is executed, the test bubble part is discarded and the replica part is consolidated with the base VMDKs. Regards, Martin
Hi, hbrsrv.log is for the VR server. /opt/vmware/hms/logs/hms.log is for VRMS. Regards, Martin
Hi, Thanks for the doc pointer. I checked that the same topic exists in VR 6.0 documentation. You can grep VRMS logs at the target site for "MoveCollection" this should confirm that a real mo... See more...
Hi, Thanks for the doc pointer. I checked that the same topic exists in VR 6.0 documentation. You can grep VRMS logs at the target site for "MoveCollection" this should confirm that a real move is being done as part of the reconfigure. Regards, Martin
Hi, Starting with VR 6.0, there is integration with SDRS. If you put the two datastores in a datastore cluster and then invoke "Enter maintenance mode" on the old datastore, SDRS will tell VR... See more...
Hi, Starting with VR 6.0, there is integration with SDRS. If you put the two datastores in a datastore cluster and then invoke "Enter maintenance mode" on the old datastore, SDRS will tell VR to move the replica disks to the other datastores within the cluster. There won't be any additional checksums / seeding - the move functionality is provided by VR. AFAIK this move functionality is not exposed in the VR UI of existing releases, but it is only an internal API being used by SDRS. Regards, Martin
Hi, The WebClient should trust the VR plugin URL based on serverThumbrint value of the com.vmware.vcHms vCenter extension. See the vCenter ExtensionManager for com.vmware.vcHms, server proper... See more...
Hi, The WebClient should trust the VR plugin URL based on serverThumbrint value of the com.vmware.vcHms vCenter extension. See the vCenter ExtensionManager for com.vmware.vcHms, server property (use vCenter credentials when prompted for login at the Managed Object Browser): https://vcenter_address/mob/?moid=ExtensionManager&doPath=extensionList%5b%22com%2evmware%2evcHms%22%5d%2eserver If the thumbprint there does not match the one of https://vr_appliance:5480/client/ngcplugin-55.zip, it will fail. You can check the actual thumbprint by opening https://vr_appliance:5480/ in a browser and observe the certificate thumbprint when you click on the locker icon before the https URL. Doing "Save and restart" from the VR appliance VAMI UI will re-create the vCenter Server extension and you can try once again logout+login at the WebClient. If the issue persists - please file a SR, so that the support team can assist. 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, Please try looking at vsphere_client_virgo.log when doing a login to the Web Client. During login, the Web Client iterates over all vCenter Server extensions and attempts to load plugins s... See more...
Hi, Please try looking at vsphere_client_virgo.log when doing a login to the Web Client. During login, the Web Client iterates over all vCenter Server extensions and attempts to load plugins such as the one for VR. Perhaps there is another plugin causing conflict/version mismatch. Regards, Martin
Hi, To list all incoming replications: https://vrms_at_target_site:8043/mob/?moid=replica-manager&method=HmsReplicaManagerGetIncomingReplications&vmodl=1 start=0 count=2000 sorters - clear... See more...
Hi, To list all incoming replications: https://vrms_at_target_site:8043/mob/?moid=replica-manager&method=HmsReplicaManagerGetIncomingReplications&vmodl=1 start=0 count=2000 sorters - clear everything from the textbox filters - clear everything from the textbox Note the GID_... values - these are the IDs of the incoming replications. For such a value - to list all available PITS: https://vrms_at_target_site:8043/mob/?moid=replica-manager&method=HmsReplicaManagerFindGroupInstances&vmodl=1 <replicationGroup type="HmsGroup">GID-e91565d5-40a0-495c-b1e5-70ca53f08a78</replicationGroup> SRM does not provide any more support on multiple PITs with VR - only be able to recovery to one of those PITs. Better MPIT story for VR is on the roadmap for a future release, but I can not share specific timeline. Regards, Martin
Hi, The API different across different VR major versions, so I can't provide exact URLs. Please note that the Managed Object Browser is mostly for troubleshooting purposes. To see the VRMS A... See more...
Hi, The API different across different VR major versions, so I can't provide exact URLs. Please note that the Managed Object Browser is mostly for troubleshooting purposes. To see the VRMS API, you need the vmodl=1 argument. To see the complete API open https://vrms:8043/mob/?vmodl=1 To list the outgoing replications - look for methods at the replication-manager object. To list the incoming replications - look for methods at the replica-manager object. If using a single vCenter server (so called ROBO mode), there will be _PRIMARY and _SECONDARY suffixes to the GID_... values. Please consider opening a SR to get support from VMware. They should be able to quickly resolve the issue. 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, The ISO file contains: - the .ovf and .vmdks for fresh deployment - update repository - packages needed when upgrading from a previous version You should be able to mount the .iso ima... See more...
Hi, The ISO file contains: - the .ovf and .vmdks for fresh deployment - update repository - packages needed when upgrading from a previous version You should be able to mount the .iso image (to a drive letter in Windows or to a folder in Linux) or use some archive utility application to extract the .ovf and .vmdks needed for a fresh deployment. Regards, Martin
Hi, SRM can use either: - array based replication - per LUN data protection or - vSphere replication - per VM data protection SRM does not support replicating within the same vCenter Ser... See more...
Hi, SRM can use either: - array based replication - per LUN data protection or - vSphere replication - per VM data protection SRM does not support replicating within the same vCenter Server. SRM provides recovery plans (invoking DR operations on multiple replicated VMs), test recovery, IP customization and other higher level functionality. VR is per-VM and does not provide "test recovery" functionality. Regards, Martin
Hi, Yes - see How vSphere Replication Works - Replication In a Single vCenter Server diagram. But those replications are visible only in VR UI and can not be orchestrated by SRM. SRM does not... See more...
Hi, Yes - see How vSphere Replication Works - Replication In a Single vCenter Server diagram. But those replications are visible only in VR UI and can not be orchestrated by SRM. SRM does not support single vCenter for source and target of the same replication group. Regards, Martin
Hi, It is possible to use vSphere Replication to protect VMs running on ESXi 5.1.x or 5.5.x to datastore attached to ESXi 6.x. However, as the other answer said - the source site ESXi needs to... See more...
Hi, It is possible to use vSphere Replication to protect VMs running on ESXi 5.1.x or 5.5.x to datastore attached to ESXi 6.x. However, as the other answer said - the source site ESXi needs to be managed by vCenter 6.x (matching with the version at the target site). Is it an option to remove the source ESXi from source site vCenter and attach it to the destination site vCenter? 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, One setting that must be up to date is VirtualCenter.FQDN (see https://vcenter_address/mob/?moid=VpxSettings&doPath=setting%5b%22VirtualCenter%2eFQDN%22%5d - this should also be visible at... See more...
Hi, One setting that must be up to date is VirtualCenter.FQDN (see https://vcenter_address/mob/?moid=VpxSettings&doPath=setting%5b%22VirtualCenter%2eFQDN%22%5d - this should also be visible at the Web Client, but I don't remember the exact location). The VR appliance on every boot retrieves vCenter address from the OVF environment. This OVF environment is kept at the ovfEnv.xml you mention below. If the ovfEnv.xml is not empty, "Save and Restart" from the VR appliance VAMI UI should get you working with the new vCenter address (the Bad exit code: 1 error happens when ovfEnv.xml is empty - usually if the VR appliance is powered on directly from host, or if somehow the data in vCenter DB about the VR appliance OVF environment is missing - can happen if the host of the appliance is removed from vCenter and then re-added back - the VR appliance VM managed object id changes and the old environment is gone). Given that you have a non-empty ovfEnv.xml, it is strange that you hit the "Bad exit code: 1" error in the VAMI UI. The OVF environment is pushed to the VR appliance at each power on of the VR appliance through vCenter. Reboot is not enough, but a power off and power on (and the power on must not be through ESXi or command line, but through vCenter). The OVF environment source of truth is kept at vCenter DB at table VPX_EXT_DATA with key something like com.vmware.vim.vsm and VirtualMachine:vm-190 where vm-190 is the managed object id of the VR appliance VM in vCenter. Perhaps you can try to check if the OVF environment data at vCenter DB is correctly updated with the new vCenter address? If the above info does not help resolve the issue, please consider opening a support ticket. Regards, Martin
Hi, This limitation is a soft one and not a hard one. The product won't stop you from configuring more than 2K VMs for replications. However, be aware that the official testing has been per... See more...
Hi, This limitation is a soft one and not a hard one. The product won't stop you from configuring more than 2K VMs for replications. However, be aware that the official testing has been performed at the documented scale. If you attempt to use the product with higher load, it is likely that runtime issues can happen (various resources and timeouts have been sized according to the tested limits and performance criteria) and official support covers only the officially tested scale. Please note that even after initial full sync has completed, each replication will switch states OK -> Sync -> OK within each RPO window and having more replications eventually will increase the load. If official testing had passed with let's say 5K VMs, I don't think that 2K would have been documented. 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