Plan the VM state transition before changing a hibernated machine's disks or NICs

Source facts

Azure hibernation writes VM memory to the OS disk before deallocation; temporary-disk contents do not persist. While hibernated, the VM cannot be resized or have disks or NICs attached, detached, or modified. Disk and NIC changes require moving it to Stop-Deallocated. Ordinary stop-deallocation does not preserve memory. Restarting a hibernated VM also has no capacity guarantee, including through capacity reservations. Microsoft Learn.

Applicability

Apply this review to an already eligible hibernation configuration. Check the current size, OS, disk, and feature restrictions separately before proposing hibernation for another workload. Identify any application work that depends on resuming the saved session.

DSE recommendation

Separate preservation of the hibernated session from the resource changes planned for the VM. Have the workload owner decide whether to resume and close that session before changing resources, or use an approved fresh-start recovery path. Record the intended state transition and its acceptance criteria. Do not schedule a disk or NIC change on the assumption that hibernation is merely an ordinary stopped state with extra convenience.

Verification

On a representative test VM, confirm the observed power state and inspect the planned resource configuration after the authorized transition. Test the application’s expected restart or resume behavior and verify its required data. Keep capacity-related startup failures separate from guest recovery errors. If the saved-session requirement and resource-change plan conflict, resolve that decision before touching the production VM.

Official references

Microsoft Learn: Hibernation for Azure virtual machines. Source reviewed September 9, 2026.