Distinguish Dedicated Host restart from hardware relocation

Source facts

Restarting an Azure Dedicated Host also restarts its underlying VMs, but keeps the same physical hardware, host ID, asset ID and SKU. The documented host-redeploy preview instead moves the host and its associated VMs to a different node of the same SKU, changing the asset ID. Redeployment loses nonpersistent data such as data on ephemeral disks. Microsoft Learn.

Applicability

Use this distinction after authorized troubleshooting has identified whether the intent is a restart or relocation away from the current node. Treat host-level action as affecting the complete hosted workload set, not just the VM where a symptom was first observed.

DSE recommendation

Choose the host operation by its intended hardware outcome and account for every hosted workload. Have the platform owner record the host identity, asset identity and hosted VM list before selecting an operation. Coordinate the expected interruption with all workload owners. For a proposed redeployment, review current preview availability and save required work to persistent storage through the application’s supported process before the action.

Verification

After an approved restart, compare identities and verify every affected workload; unchanged hardware identity is expected for that operation. For an approved preview redeployment, check the changed asset ID alongside the actual host and VM status. Validate application state independently, including any deliberately rebuilt temporary content. Do not declare a hardware move merely because a restart completed or a VM resumed responding.

Official references

Microsoft Learn: Deploy VMs and scale sets to dedicated hosts. Source reviewed September 9, 2026.