Today, three Azure Virtual Desktop multisession hosts in West US 2 went through live migration at different times. Azure reported each migration as successful, but users were disconnected and could not reconnect afterward. The connection error was `ConnectionFailedUserHasValidSessionButRdshIsUnhealthy`.
The affected hosts became stuck in an updating state. The VM status showed `ProvisioningState/Unavailable`, `Not Ready`, and `VM Agent is unresponsive`, while the overall VM status remained `ProvisioningState/updating` and `PowerState/running`.
These are Windows 11 multisession VMs using the E8s_v6 size and managed through Nerdio. Console Connect, RDP by IP address, RDP by hostname, and Azure Run Command all failed. I placed the host in drain mode, but users with existing sessions were still directed to it, which appears to be expected behavior. Rebooting the affected hosts restored access.
Has anyone seen live migration leave an AVD host in this state? Is there a way to prevent it, or a recovery method other than rebooting when the VM agent becomes unresponsive? The hosts are behind a firewall, so I'm also wondering whether connectivity or agent updates could be involved.
3 Answers
Agent updates may also be contributing. Some environments have seen newer agents behave poorly, so schedule agent or image updates during a maintenance window and bring hosts back gradually rather than updating everything at once. Since these machines are reimaged daily, the image and agent version should be checked as well. Compare the affected hosts with a known-good image and review whether all three received the same agent or Windows update.
That is not typical live migration behavior. The expected memory-preserving pause should only last a few seconds. A VM agent reporting `Not Ready` while the VM remains running and stuck in `updating` points more toward the guest or platform agent becoming unresponsive. Capture Scheduled Events, VM agent logs, and WaAppAgent logs before rebooting if possible, then open an Azure support case with the exact timestamps. Once console access and Run Command both fail, rebooting is probably the practical recovery step rather than the underlying fix.
The reported memory-preserving pause was only about 1.4 seconds, but that was apparently enough for the hosts to stop functioning afterward.
A reboot resolving the problem suggests the guest or VM agent became wedged rather than live migration simply disconnecting users. Since the hosts are behind a firewall, check outbound connectivity and firewall logs around the migration time, especially anything affecting Azure platform communication or agent status updates. If the agent and Run Command are both unavailable, there may not be an in-guest fix until the VM responds again.
Rebooting did resolve it, and the hosts are behind a firewall, so I’ll check whether anything was blocked around those timestamps.
The machines are reimaged daily, so they usually have a current agent, but we’ve also noticed newer agent versions becoming less reliable over time.