Today, three Azure Virtual Desktop multisession hosts in West US 2 went through live migration at different times. Azure reported each migration as successful, and the expected memory-preserving pause was only about 1.4 seconds. However, users were disconnected and then unable to reconnect, receiving the error `ConnectionFailedUserHasValidSessionButRdshIsUnhealthy`.
The affected hosts became stuck in an updating state. The VM agent showed `ProvisioningState/Unavailable`, `Not Ready`, and `VM Agent is unresponsive`, while the VM itself still showed as running with `ProvisioningState/updating`. The hosts use the E8s_v6 size, Windows 11 multisession, and are managed through Nerdio.
Nerdio Console Connect, RDP by IP address and 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 hosts restored service.
The VMs are behind a firewall, and the machines are reimaged daily, so they generally have current agents. Is there a way to prevent this kind of disruption, or a better recovery process than rebooting the host when the VM agent becomes unresponsive after live migration?
3 Answers
A reboot resolving the issue suggests the guest or VM agent became wedged rather than live migration simply causing a normal brief pause. Since the hosts are behind a firewall, check outbound connectivity and firewall logs around the migration timestamps, especially anything affecting Azure platform communication or agent status reporting. It would also be worth collecting Scheduled Events, VM agent, and WaAppAgent logs before rebooting when possible.
This does not look like normal live migration behavior. A short memory-preserving pause is expected, but a VM agent reporting `Not Ready` while the VM remains running and stuck in `updating` indicates that the guest agent or provisioning state got stuck. If Run Command, console access, and RDP all fail, rebooting is probably the practical recovery action. Preserve the timestamps and diagnostic logs, then open an Azure support case so Microsoft can correlate the event with the underlying platform maintenance operation.
The pause was only about 1.4 seconds, but the hosts stopped functioning immediately afterward. I’ll capture the scheduled-event and agent logs and raise a support case if it happens again.
Agent updates can also leave multisession hosts in a bad state, particularly when the agent or related services are being updated during startup or maintenance. Scheduling updates after users are logged off and using a gradual rollout is a sensible precaution. Since these machines are reimaged daily, the image and current agent versions should still be reviewed, especially if the problem began after a newer agent release. Keep a known-good image or rollback option available.
The hosts are reimaged every day, so they usually have the latest agent, although the newer versions have seemed less reliable. I’ll compare the image and agent versions against the hosts that were unaffected.
Rebooting did restore the hosts. They are behind a firewall, so I’ll compare the firewall logs with the migration times and check whether any required agent traffic was blocked.