Skip to content

Commit 8427f33

Browse files
author
Ankita Dutta
committed
content QS
1 parent 9d2db9e commit 8427f33

File tree

1 file changed

+13
-13
lines changed

1 file changed

+13
-13
lines changed

articles/site-recovery/vmware-azure-troubleshoot-replication.md

Lines changed: 13 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -17,15 +17,15 @@ This article describes some common issues and specific errors you might encounte
1717

1818
Site Recovery uses the [process server](vmware-physical-azure-config-process-server-overview.md#process-server) to receive and optimize replicated data, and send it to Azure.
1919

20-
We recommend that you monitor the health of process servers in the portal to ensure that they are connected and working properly, and that replication is progressing for the source machines associated with the process server.
20+
We recommend that you monitor the health of process servers in the portal to ensure that they are connected and working properly, and that replication is progressing for the source machines that are associated with the process server.
2121

2222
- [Learn about](vmware-physical-azure-monitor-process-server.md) monitoring process servers.
2323
- [Review best practices].(vmware-physical-azure-troubleshoot-process-server.md#best-practices-for-process-server-deployment)
2424
- [Troubleshoot](vmware-physical-azure-troubleshoot-process-server.md#check-process-server-health) process server health.
2525

2626
## Step 2: Troubleshoot connectivity and replication issues
2727

28-
Initial and ongoing replication failures often are caused by connectivity issues between the source server and the process server or between the process server and Azure.
28+
Connectivity issues between the source server and the process server or between the process server and Azure often cause initial and ongoing replication failures.
2929

3030
To solve these issues, [troubleshoot connectivity and replication](vmware-physical-azure-troubleshoot-process-server.md#check-connectivity-and-replication).
3131

@@ -36,12 +36,12 @@ When you try to select the source machine to enable replication by using Site Re
3636
* **Two virtual machines with the same instance UUID**: If two virtual machines under the vCenter have the same instance UUID, the first virtual machine discovered by the configuration server is displayed in the Azure portal. To resolve this issue, ensure that no two virtual machines have the same instance UUID. This scenario is commonly seen in instances where a backup VM becomes active and is logged into our discovery records. Refer to [Azure Site Recovery VMware-to-Azure: How to clean up duplicate or stale entries](https://social.technet.microsoft.com/wiki/contents/articles/32026.asr-vmware-to-azure-how-to-cleanup-duplicatestale-entries.aspx) to resolve.
3737
* **Incorrect vCenter user credentials**: Ensure that you added the correct vCenter credentials when you set up the configuration server by using the OVF template or unified setup. To verify the credentials that you added during setup, see [Modify credentials for automatic discovery](vmware-azure-manage-configuration-server.md#modify-credentials-for-automatic-discovery).
3838
* **vCenter insufficient privileges**: If the permissions provided to access vCenter don't have the required permissions, failure to discover virtual machines might occur. Ensure that the permissions described in [Prepare an account for automatic discovery](vmware-azure-tutorial-prepare-on-premises.md#prepare-an-account-for-automatic-discovery) are added to the vCenter user account.
39-
* **Azure Site Recovery management servers**: If the virtual machine is used as a management server under one or more of the following roles - Configuration server /scale-out process server / Master target server, then you will not be able to choose the virtual machine from the portal. Management servers cannot be replicated.
39+
* **Azure Site Recovery management servers**: If the virtual machine is used as a management server under one or more of the following roles - Configuration server /scale-out process server / Master target server, then you won't be able to choose the virtual machine from the portal. Management servers cannot be replicated.
4040
* **Already protected/failed over through Azure Site Recovery services**: If the virtual machine is already protected or failed over through Site Recovery, the virtual machine isn't available to select for protection in the portal. Ensure that the virtual machine you're looking for in the portal isn't already protected by any other user or under a different subscription.
41-
* **vCenter not connected**: Check if vCenter is in a connected state. To verify, go to Recovery Services vault > Site Recovery Infrastructure > Configuration Servers > Click on respective configuration server > a blade opens on your right with details of associated servers. Check if vCenter is connected. If it's in a "Not Connected" state, resolve the issue and then [refresh the configuration server](vmware-azure-manage-configuration-server.md#refresh-configuration-server) on the portal. After this, virtual machine will be listed on the portal.
42-
* **ESXi powered off**: If the ESXi host under which the virtual machine resides is in a powered-off state, then the virtual machine will not be listed or will not be selectable on the Azure portal. Power on the ESXi host, and [refresh the configuration server](vmware-azure-manage-configuration-server.md#refresh-configuration-server) on the portal. After this, virtual machine will be listed on the portal.
43-
* **Pending reboot**: If there is a pending reboot on the virtual machine, then you will not be able to select the machine on the Azure portal. Ensure to complete the pending reboot activities and [refresh the configuration server](vmware-azure-manage-configuration-server.md#refresh-configuration-server). After this, virtual machine will be listed on the portal.
44-
* **IP not found or Machine does not have an IP address**: If the virtual machine doesn't have a valid IP address associated with it, then you will not be able to select the machine on the Azure portal. Ensure to assign a valid IP address to the virtual machine, and [refresh the configuration server](vmware-azure-manage-configuration-server.md#refresh-configuration-server). It could also be caused if the machine does not have a valid IP address associated with one of its NICs. Either assign a valid IP address to all NIC's or remove the NIC that's missing the IP. After this, the virtual machine will be listed on the portal.
41+
* **vCenter not connected**: Check if vCenter is in a connected state. To verify, go to Recovery Services vault > Site Recovery Infrastructure > Configuration Servers > Click on respective configuration server > a blade opens on your right with details of associated servers. Check if vCenter is connected. If it's in a "Not Connected" state, resolve the issue, and then [refresh the configuration server](vmware-azure-manage-configuration-server.md#refresh-configuration-server) on the portal. After this, virtual machine is not listed on the portal.
42+
* **ESXi powered off**: If the ESXi host under which the virtual machine resides is in a powered-off state, then the virtual machine is not listed or is not selectable on the Azure portal. Power on the ESXi host, and [refresh the configuration server](vmware-azure-manage-configuration-server.md#refresh-configuration-server) on the portal. After this, virtual machine is listed on the portal.
43+
* **Pending reboot**: If there is a pending reboot on the virtual machine, then you won't be able to select the machine on the Azure portal. Ensure to complete the pending reboot activities and [refresh the configuration server](vmware-azure-manage-configuration-server.md#refresh-configuration-server). After this, virtual machine is listed on the portal.
44+
* **IP not found or Machine does not have an IP address**: If the virtual machine doesn't have a valid IP address associated with it, then you is not able to select the machine on the Azure portal. Ensure to assign a valid IP address to the virtual machine, and [refresh the configuration server](vmware-azure-manage-configuration-server.md#refresh-configuration-server). It could also be caused if the machine does not have a valid IP address associated with one of its NICs. Either assign a valid IP address to all NICs or remove the NIC that's missing the IP. After this, the virtual machine is listed on the portal.
4545

4646
### Troubleshoot protected virtual machines greyed out in the portal
4747

@@ -67,7 +67,7 @@ Over and above ensuring that there are no connectivity, bandwidth, or time sync-
6767

6868
**To resolve the issue:**
6969
- Ensure that the target storage account type (Standard or Premium) is provisioned as per the churn rate requirement at the source.
70-
- If you are already replicating to a Premium managed disk (asrseeddisk type), ensure that the size of the disk supports the observed churn rate as per Site Recovery limits. You can increase the size of the asrseeddisk if required. Follow the below steps:
70+
- If you are already replicating to a Premium managed disk (asrseeddisk type), ensure that the size of the disk supports the observed churn rate as per Site Recovery limits. You can increase the size of the asrseeddisk if necessary. Follow these steps:
7171
- Navigate to the Disks blade of the impacted replicated machine and copy the replica disk name
7272
- Navigate to this replica managed disk
7373
- You may see a banner on the Overview blade saying that a SAS URL has been generated. Click on this banner and cancel the export. Ignore this step if you do not see the banner.
@@ -128,10 +128,10 @@ To resolve the issue, use the following steps to verify the service status:
128128

129129
Enhancements have been made in mobility agent [9.23](vmware-physical-mobility-service-overview.md#mobility-service-agent-version-923-and-higher) & [9.27](site-recovery-whats-new.md#update-rollup-39) versions to handle VSS installation failure behaviors. Ensure that you are on the latest versions for best guidance on troubleshooting VSS failures.
130130

131-
Some of the most common issues are listed below
131+
Following are common issues:
132132

133133
#### Cause 1: Known issue in SQL server 2008/2008 R2
134-
**How to fix**: There is a known issue with SQL server 2008/2008 R2. Please refer this KB article [Azure Site Recovery Agent or other non-component VSS backup fails for a server hosting SQL Server 2008 R2](https://support.microsoft.com/help/4504103/non-component-vss-backup-fails-for-server-hosting-sql-server-2008-r2)
134+
**How to fix**: There is a known issue with SQL server 2008/2008 R2. Refer this KB article [Azure Site Recovery Agent or other non-component VSS backup fails for a server hosting SQL Server 2008 R2](https://support.microsoft.com/help/4504103/non-component-vss-backup-fails-for-server-hosting-sql-server-2008-r2)
135135

136136
#### Cause 2: Azure Site Recovery jobs fail on servers hosting any version of SQL Server instances with AUTO_CLOSE DBs
137137
**How to fix**: Refer to Kb [article](https://support.microsoft.com/help/4504104/non-component-vss-backups-such-as-azure-site-recovery-jobs-fail-on-ser)
@@ -141,7 +141,7 @@ Some of the most common issues are listed below
141141
**How to fix**: Refer to Kb [article](https://support.microsoft.com/help/4493364/fix-error-occurs-when-you-back-up-a-virtual-machine-with-non-component)
142142

143143
#### Cause 4: App-Consistency not enabled on Linux servers
144-
**How to fix**: Azure Site Recovery for Linux Operation System supports application custom scripts for app-consistency. The custom script with pre and post options will be used by the Azure Site Recovery Mobility Agent for app-consistency. [Here](./site-recovery-faq.yml) are the steps to enable it.
144+
**How to fix**: Azure Site Recovery for Linux Operation System supports application custom scripts for app-consistency. The custom script with pre and post options is used by the Azure Site Recovery Mobility Agent for app-consistency. [Here](./site-recovery-faq.yml) are the steps to enable it.
145145

146146
### More causes due to VSS related issues:
147147

@@ -154,7 +154,7 @@ Search for the string "vacpError" by opening the vacp.log file in an editor
154154

155155
`Ex: `**`vacpError`**`:220#Following disks are in FilteringStopped state [\\.\PHYSICALDRIVE1=5, ]#220|^|224#FAILED: CheckWriterStatus().#2147754994|^|226#FAILED to revoke tags.FAILED: CheckWriterStatus().#2147754994|^|`
156156

157-
In the above example **2147754994** is the error code that tells you about the failure as shown below
157+
In the above example **2147754994** is the error code that tells you about the failure as shown:
158158

159159
#### VSS writer is not installed - Error 2147221164
160160

@@ -206,7 +206,7 @@ This error occurs when trying to enable replication and the application folders
206206
- *C:\thirdparty\rrdtool-1.2.15-win32-perl58\rrdtool\Release\**
207207

208208
## Troubleshoot and handle time changes on replicated servers
209-
This error occurs when the source machine's time moves forward and then moves back in a short time, to correct the change. You may not notice the change as the time is corrected very quickly.
209+
This error occurs when the source machine's time moves forward and then moves back in a short time, to correct the change. You may not notice the change as the time is corrected quickly.
210210

211211
**How to fix**:
212212
To resolve this issue, wait till system time crosses the skewed future time. Another option is to disable and enable replication once again, which is only feasible for forward replication (data replicated from on-premises to Azure) and is not applicable for reverse replication (data replicated from Azure to on-premises).

0 commit comments

Comments
 (0)