Manage the Lifecycle of VM Role Instances in Windows Azure

[The VM Role feature of Windows Azure is being retired on May 15th, 2013. After the retirement date, VM role deployments will be deleted. To move forward with your existing applications, you can use Windows Azure Virtual Machines. For more information about using Virtual Machines for your application, see Moving from VM Role to Windows Azure Virtual Machines.

The process of developing a VM Role begins with creating and customizing an image of Windows Server 2008 R2 and uploading it to the Windows Azure image repository. After you upload a server image, it remains in the repository until you delete it. When you deploy your cloud service in Windows Azure, the server image referenced in the service configuration file is applied to create the specified number of VM Role instances, each of which runs the customized version of Windows Server defined by your image.

The VM Role instance is a named instance of the image that runs in exactly one virtual machine at any given time. The virtual machine in which the VM Role instance runs may change over time. When you reimage an instance, or when Windows Azure reimages it due to a transient failure, the virtual machine is shut down, and all state information that has not been persisted is lost. When the VM Role instance is brought online again, a new virtual machine is created from the image. If your service requires that state be restored, you will need to implement the process of persisting and restoring state yourself. Options for persisting state include writing it to a Windows Azure blob or to a Windows Azure drive.

Note
A VM Role always performs an image-based deployment of the operating system. The virtual machine in which a VM Role instance runs is a transient environment; the virtual machine itself is never moved from one physical host machine to another.

When you deploy an image, it is read-only, and it remains read-only – Windows Azure never writes directly to your image. Because your image is read-only, and because the VM Role instance needs to write Windows Setup data as it comes online and other system data throughout its lifecycle, Windows Azure creates an additional, ephemeral VHD that it can write to. It is not possible to access the writable VHD directly, or to persist it directly when the instance is brought offline. When the VM Role instance is reimaged, a new ephemeral VHD is created in the process of bringing the instance back online in a new VM.

The following diagram shows how an image is deployed to Windows Azure and applied to create VM Role instances:

Each time a new image is deployed or a VM Role instance is reimaged, Windows Azure creates a virtual machine for the instance and starts the operating system for the first time. During this process, Windows Setup runs in an automated fashion, configuring itself from information provided in the answer file (c:\unattend.xml). The operating system then restarts automatically to complete the setup process. After the operating system restarts, auto-start services are started. After all auto-start services have started, Windows Azure brings the VM Role instance into load balancer rotation, and it begins receiving traffic.

An instance can be restarted any number of times. Windows persists all data across restarts. When you reimage a VM Role instance, it is re-created from the image, and any state that you have not explicitly persisted is lost. Data that is written to the local storage resource directory is persisted when a server instance is reimaged; however, this data may be lost in the event of a transient failure in Windows Azure that requires your VM Role instance to be moved to different hardware.

The following diagram shows the lifecycle of a VM Role instance from the time that the image is applied to the time that the instance is reimaged. It also shows the lifecycle of a Windows session within the image lifecycle, from the time that the operating system initially starts to the time that it is restarted.

After the application it has been deployed, it is assigned a single virtual IP address (VIP), managed by the load balancer. The load balancer handles the routing of traffic to the running instances. Each instance is assigned a dynamic IP address, which is accessible to other components of your cloud service but not to Internet traffic.

See Also