You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ms.custom: sap:VM restarted or stopped unexpectedly
17
17
---
18
18
# Understand a system reboot for Azure VM
@@ -98,13 +98,13 @@ The VM is hosted on a physical server that is running inside an Azure datacenter
98
98
99
99
Server faults are usually caused by hardware failure, such as the failure of a hard disk or solid-state drive. Azure continuously monitors these occurrences, identifies the underlying bugs, and rolls out updates after the mitigation has been implemented and tested.
100
100
101
-
Because some host server faults can be specific to that server, a repeated VM reboot situation might be improved by manually redeploying the VM to another host server. This operation can be triggered by using the **redeploy** option on the details page of the VM, or by stopping and restarting the VM in the Azure portal.
101
+
Because some host server faults can be specific to that server, a repeated VM reboot situation might be improved by manually redeploying the VM to another host server. This operation can be triggered by using the [redeploy](redeploy-to-new-node-windows.md#use-the-azure-portal) option on the details page of the VM, or by stopping and restarting the VM in the Azure portal.
102
102
103
103
### Auto-recovery
104
104
105
-
The Azure platform is designed to handle host node issues with minimal impact on VM performance. When a host node encounters a problem, Azure first attempts the least disruptive recovery method, which is to reboot the host. If rebooting the host isn't possible or if the original issue is hardware-related, the platform service heals all VMs on the affected host to a healthy node. While rebooting a host generally has a lower impact, service healing VMs can be more complex and time-consuming, depending on the number of VMs, their deployment constraints, and local resource availability. Service healing is typically used as a last resort for hardware failures because it ensures that VMs continue to operate without significant downtime.
105
+
The Azure platform is designed to handle host node issues with minimal impact on VM performance. When a host node encounters a problem, Azure first attempts the least disruptive recovery method, which is to reboot the host. If rebooting the host isn't possible or the issue is hardware-related, Azure initiates an automatic recovery action to take the faulty host out of rotation for further investigation. As part of this automatic recovery, a process known as service healing will automatically relocate all VMs on the faulty host to another healthy one. This process is usually completed within 15 minutes, although the recovery time can vary depending on factors such as the host's memory size and recovery methods used. Service healing is typically used as a last resort for hardware failures to ensure that VMs continue to operate without significant downtime.
106
106
107
-
If a host server can't reboot, Azure initiates an automatic recovery action to take the faulty host out of rotation for further investigation. During this auto-recovery process, all VMs on the host are automatically relocated to another healthy host server. While this process usually completes within 15 minutes, the recovery time can vary based on factors such as the host's memory size and the recovery methods used. For more details about how Azure handles these scenarios, see [Service Healing – Auto-recovery of Virtual Machines](https://azure.microsoft.com/blog/service-healing-auto-recovery-of-virtual-machines/).
107
+
For more details about how Azure handles these scenarios, see [Service Healing – Auto-recovery of Virtual Machines](https://azure.microsoft.com/blog/service-healing-auto-recovery-of-virtual-machines/).
108
108
109
109
### Unplanned maintenance
110
110
@@ -117,7 +117,12 @@ Unplanned maintenance include the following:
117
117
118
118
### VM crashes
119
119
120
-
VMs might restart because of issues within the VM itself. The workload or role that's running on the VM might trigger a bug check within the guest operating system. For help determining the reason for the crash, view the system and application logs for Windows VMs, and the serial logs for Linux VMs.
120
+
VMs might restart due to internal VM issues or hardware issues, such as an OS disk issue, as described earlier. The workload or role running on the VM might trigger a bug check in the guest OS. To find the reason for the crash, check the system and application logs for Windows VMs and the serial logs for Linux VMs. Collecting a memory dump is usually the best way to identify the root cause.
@@ -127,8 +132,8 @@ VMs in Azure rely on virtual disks for operating system and data storage that is
127
132
128
133
In rare circumstances, a widespread issue can affect multiple servers in an Azure datacenter. If this issue occurs, the Azure team sends email notifications to the affected subscriptions. You can check the [Azure Service Health dashboard](https://azure.microsoft.com/status/) and the Azure portal for the status of ongoing outages and past incidents.
129
134
130
-
## Diagnose VM Restarts
135
+
## Diagnose VM restarts
131
136
132
-
You can use the Diagnose and Solve blade on the VM blade to run additional diagnostics. This may uncover more specific reasons for your recent VM restart. If there is any Guest OS issue, collect memory dump and contact support.
137
+
You can use the **Diagnose and Solve** blade on the VM blade to run additional diagnostics. This may uncover more specific reasons for your recent VM restart. If there is any guest OS issue, collect a memory dump and contact support.
133
138
134
139
[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)]
@@ -222,11 +222,11 @@ If you back up the database to a disk or back up the transaction log to a disk,
222
222
223
223
For more information about antivirus considerations on a cluster, see [Antivirus software that isn't cluster-aware may cause problems with Cluster Services](../../../windows-server/high-availability/not-cluster-aware-antivirus-software-cause-issue.md).
224
224
225
-
### Arcenabled SQL Server
225
+
### Arc-enabled SQL Server
226
226
227
-
You might see the following files and executables (also referred to as system objects) being flagged when running antivirus software on an [Arc enabled SQL Server](/sql/sql-server/azure-arc/connect). Consider excluding these [necessary system objects](/sql/sql-server/azure-arc/agent-extension-files) from antivirus scanning.
227
+
When you run antivirus software on an [Arc-enabled SQL Server](/sql/sql-server/azure-arc/connect) instance, some files and executables (also referred to as system objects) might be flagged. However, these [system objects](/sql/sql-server/azure-arc/agent-extension-files) are necessary for Arc-enabled SQL Server to function properly. To ensure optimal performance and stability, we recommend that you exclude these [necessary system objects](/sql/sql-server/azure-arc/agent-extension-files) from antivirus scanning.
228
228
229
-
Starting with SQL Server 2025, SQL Server instances can use the Azure Arc machine's managed identity. You might need to add an exemption for the token folder. Follow the steps in [Setup managed identity for Arcenabled SQL Server](/sql/sql-server/azure-arc/managed-identity) for the proper setup and the folder path.
229
+
Starting with SQL Server 2025, SQL Server instances can use the Azure Arc machine's managed identity. You might need to add an exemption for the token folder. Follow the steps in [Configure a managed identity for Arc-enabled SQL Server](/sql/sql-server/azure-arc/managed-identity) for the proper setup and the folder path.
230
230
231
231
We also recommend that you keep the extension up to date, as it includes ongoing security and feature updates. For more information, see the [latest extension release](/sql/sql-server/azure-arc/release-notes).
0 commit comments