Introduction
Azure supports Windows-style hibernation on some VMs. When you hibernate a VM, Azure signals the guest operating system to perform suspend-to-disk. During hibernation, Azure copies the memory (RAM) contents of the VM to the OS disk (C drive) and deallocates the VM. Later, when we start the VM, the RAM contents are restored back from the OS disk and applications and processes that were previously running in the VM quickly resume to their last state.
Once a VM is in a hibernated state, you are not billed for the VM usage. You only pay for the storage (OS disk, data disks) and networking resources (IPs, etc.) attached to the VM.
The following happens when hibernating a VM:
When hibernation is triggered on a VM, Azure signals the guest operating system to perform suspend-to-disk.
During hibernation, the contents of the RAM are saved on the OS disk and the VM is deallocated (that is, the VM releases the lease on the underlying hardware and is powered off).
During hibernation, data in the temporary disk is not persisted.
Once a VM is hibernated, the OS disk, data disks, and NICs remain attached to your VM. Any static IPs remain unchanged.
We are not billed for the VM usage for a hibernated VM.
You continue to be billed for the storage and networking resources associated with the hibernated VM.
Prerequisites:
Your Azure Subscription, Region, and VM type, and VM size should support hibernation.
See Microsoft’s Hibernation for Azure virtual machines.
Workspot does not support every VM that Azure supports. Contact Workspot if you are in any doubt.
This is a selective feature. Contact Workspot to enable it.
Power Managed Template
A template that has the “power-management” enabled will support hibernation-enabled pools and desktops. The process to create a new template is the same as regular template, for “Build Template” method, but with the “Power-Management” check box checked.
Register Template/ Custom Template
In addition to the regular steps to upload and create a new Workspot Windows Template, we need to follow few additional steps mentioned below:
Make sure you choose a supported VM/SKU type.
After login, verify that the page file is set and enabled only on the C:\ drive.
Manually Configure the Page File
Login to the Draft-mode template or desktops VM.
Type “Advanced System Settings” in the search bar and hit enter.
System properties window will appear. Under “Advanced Tab > Performance > Settings..”
A new “Performance Options” window will appear. Click “Advanced > Virtual Memory > Change..”
A new “Virtual Memory” window will appear.
Configuration is correct if:
“Automatically manage paging file size for all sizes” is NOT set, and
“Paging File Size” is nonzero for C: and “None” for all other drives, and
The maximum size of the paging file is larger then the amount of RAM in the VM.
If “Automatically manage paging file size for all drives” is selected, uncheck it and it will enable all the fields below.
Click on C:\ drive and select the radio button “System Managed size.” Click on “Set”. A new window with a warning message will appear like in the screenshot below. Please read the message and accept by hitting the “Yes” button.
Click on D:\ drive (if any) and select the radio button “No Paging File”> Click on “Set” button.
Once these changes are made. Click on the OK button.
This action will require the machine to reboot to take effect. So, if you are ready, then you should restart the VM.
Register Template
These steps are not needed for Azure Marketplace templates or clones of existing Workspot templates.
After all the regular steps, like Enable RDP, disable NLA, installing Template Agent and configuring it, Power it off and Click on “Register Template” in Control.
Make sure to check the “This Template has Power Management enabled” checkbox on the Add Template window.
Using an existing template to create a Power-managed Template
If you already have a good template with all the customer specific applications and configurations in it and do not want to spend time in creating a new one from scratch, must follow these steps:
Clone the existing template.
Once it comes up in Draft state, sign into the Draft-mode template.
Once the machine is restarted, resize the VM on Azure to a supported SKU if it isn’t on one already.
Shut down the template and publish it on Control.
Raise support ticket with Workspot to enable the Power-Management flag on this newly cloned template.
Once the Change is made you will see the Power Management flag enabled on the template details.
Create a new Pool that supports Hibernation:
The process for the Pool creation is the same as regular pools but make sure you choose the Power-managed template which supports Hibernation.
While selecting the template you can check the box “power-managed templates only” to only see the relevant ones.
Using Upgrade Desktop API to move VMs to Hibernate pool:
Customers/admins can use the Upgrade Desktop API to migrate VMs from an old pool to a new pool that supports Hibernation.
Limitations of API method:
This method will fail or get stuck in one of the below scenarios:
If the Workspot Agent version on the source VM is older than 3.1.0
If the Disk size on the source VM is greater than the Target pool configuration.
If the source VM does not have a valid user assignment
If the source VM is in Error/Failed/Paused state. It should be in either Ready or Disconnected state.
Please note: A GUI feature for this API is going to be made available in future releases.
Manual Steps to migrate VMs to the new pool for Hibernation:
Below are the steps to do it manually if you want to do so instead of the API method or if the VM has the above limitations.
Snapshot the disk:
Make sure the VM is completely booted from the previous step.
Shutdown (Deallocate) the VM from Azure Console
Click on the Disks section under Settings of the VM. Click on the Disk name.
In the Disk Overview page, click on the Create Snapshot link to open the Snapshot creation form.
Provide the appropriate name for the snapshot and click on review + create
In the next page, click on Create.
Delete VM:
To save customer licenses, you can choose to delete the existing VM.
Create a New Disk from the Snapshot:
Once the Snapshot is created, go to the Snapshot Overview Page by either clicking on the Go to the resource Link or Search for the Snapshot name on Global Search bar and select it.
On the overview page, click on the Create Disk Link to open the Disk creation form.
Provide the appropriate name for the disk.
At the bottom of the page make sure the disk type is appropriate for the use case. Premium SSD / Standard SSD.
If it is not, then click on Change Size link.
Select the right Disk Type and Size that you want and click on OK at the bottom of the page.
On the main page, Click on Review + Create > in the next page click on Create after reviewing all details.
Enable Hibernate Patch on the Disk:
To only way to enable Hibernate patch on the disk is my invoking Azure API. We integrated it on a PowerShell Script to ease the process.
Script - EnableHibernation_ManagedDisk (1).ps1
Input file - Disks (1).csv
Download the files from the SharePoint location.
Update the input file with the required details – Disk Name, Subscription ID, Resource Group Name, Tenant ID and save it.
Open PowerShell terminal in Admin mode and execute the script.
After CSP authentication, you would be asked to choose the input file. Please select the input file from location.
Once the Script is executed, the output file is saved on the following location on the local machine - C:\Users\<username>\Logs\Hibernation.
Disk Swap on Target VM:
Go to the Target VM > Shut it down.
Once the State shows Shutdown (deallocated)., go to the Disks Section on the VM page.
Click on Swap OS Disk link visible on top of the Disk name.
A new Swap OS Disk page will appear. Choose the Target Disk from the drop-down list, which you created earlier and want to swap.
Type the name of the current VM in the confirmation field and click on OK.
After a few moments, the Disk swap will be completed.
Power on the VM
Re-registering VM
Once the disk swap is completed, power-on the VM.
Run the following command by invoking “reregister_poolvm.bat” batch file, from the location "C:\Program Files\WorkspotAgent on the VM:
cmd> cd "C:\Program Files\WorkspotAgent"
C:\Program Files\WorkspotAgent> reregister_poolvm.bat <agent_token> <company_identifier>
You can capture the agent token by clicking on the “Agent Token” button on the target pool details page on control.
A new window will populate with the agent token in it. Agent token has limited validity, so If it is expired, click on re-generate token to obtain a new token.
Validation Steps:
Confirming that the Hibernate Extension on the VM is provisioned Successfully:
After the pool is deployed and the machine comes in Ready state, login to the Azure portal and go to the Extensions + applications section of the VM.
Make sure that you see AzureHibernateExtension under Extensions tab and the status of which is showing as “Provisioning Succeeded”.
Please note that this will only be visible when the machine is fully powered on and Azure Agent is in Ready state.
Confirming Hibernate is working on this VM:
You can directly pause the VM from Control or Run the following Az command from on Cloud Shell to initiate Hibernate on the VM
Command: az vm deallocate --resource-group <resource_group_name> --name <vm_name> --hibernate true
check the VM status on Azure after a couple of minutes. The status should be shown as Hibernate (Deallocated).
Limitations with Azure Hibernate
You cannot enable hibernation on existing VMs. Hibernation can only be enabled at the time of VM provisioning.
You cannot resize a VM if it has hibernation enabled.
When a VM is hibernated, you cannot attach/detach any disks or NICs to the VM. To do so, you must move the VM to a Stop-Deallocated state by stopping the VM and then attach/detach disks and NICs.
When a VM is hibernated, you cannot modify the disks and NICs associated with the VM. To do so, you must move the VM to a Stop-Deallocated state by stopping the VM and then modify the disks and NICs.
If a VM has a Capacity Reservation associated with it and is hibernated, it does not ensure that the VM will resume.
You can only hibernate a VM using the Azure Portal, CLI, PowerShell, SDKs and API. Hibernating the VM using guest OS operations will not result in the VM moving to a hibernated state and the VM will continue to be billed.
You cannot disable hibernation on a VM once it's enabled.
Windows Limitations
The page file cannot be on the temp disk.
Applications such as Device Guard and Credential Guard that require virtualization-based security (VBS) are only supported with hibernation when Trusted Launch is enabled on the VM and Nested Virtualization is enabled in the guest OS.
Hibernation is supported with Nested Virtualization only when Trusted Launch is enabled on the VM
Linux Limitations
Hibernation is not supported with Trusted Launch for Linux VMs
Additional Resources: