Running virtual machines on Windows Azure combines the benefits of virtualization and cloud computing.
Constant change is a pillar of the IT industry. New technologies, hardware, software and communication protocols are introduced every day. This flood of new technology creates an evolving landscape that improves how we conduct business, how we communicate and how we share knowledge. In the midst of this whirlwind of change, the two most substantial transformations we’ve seen in the IT world in recent years are virtualization and cloud computing.
Virtualization helps enterprises make more efficient use of hardware resources. It facilitates a greater degree of abstraction of the software environment from its hardware. Servers now exist as a single file. You can easily move them from one piece of hardware to another, duplicate them at will, and create a more scalable and flexible infrastructure.
Cloud computing has taken that degree of efficiency and agility realized from virtualization and magnified it further. Through pooled resources, geographic diversity and universal connectivity, cloud computing has facilitated delivering hosted software, platforms and infrastructure as a service. It is at once a new technology platform and a new business model.
With the introduction of the virtual machine (VM) role on the Windows Azure platform, these powerful concepts come together to host virtual infrastructure in the cloud. You’ll soon be able to build VMs for Windows Azure and deploy them to the cloud where you can leverage the flexible, scalable infrastructure and cost savings for which cloud computing is noted.
Currently, the Windows Azure VM role is still in beta. You can learn more about the beta program by visiting the Windows Azure Compute site. You can apply for the beta by visiting the Beta Programs section of the Windows Azure Management Portal. Due to its beta status, information contained here concerning the VM role is subject to change.
The VM role for Windows Azure is similar to other server roles. VMs on Windows Azure run a version of the Windows Server OS. The difference with the VM role is that you can create, customize and manage the server image to meet your needs and specifications.
There are a few operational differences of which you should be aware when running your VM on Windows Azure, instead of on-premises hardware. First, some network-related functionality is restricted. For example, in order to use the User Datagram Protocol (UDP), you must also use Windows Azure Connect. Also, a VM role instance running in Windows Azure does not have a persist state.
You’re advised to use the Windows Azure storage services to persist state, either by writing it to a blob or to a Windows Azure drive. For more details on how to do this, see “ How to Develop an Adapter for a VM Role in Windows Azure.”
Data written to the local storage resource directory is persisted when a server instance is reimaged. You may lose this data, however, in the event of a transient failure in Windows Azure that requires you to move your VM role instance to different hardware.
Keeping those conditions in mind, the process of building a VM for Windows Azure is similar to building any other VM. Begin by building a base virtual hard drive (VHD), either by creating a blank VHD with Hyper-V Manager, modifying an existing VHD or converting a physical server installation to a VHD. (For more information, see “ Sources of New Virtual Machines.”)
The base image contains the OS (which must be Windows Server 2008 R2), any customizations to the OS and any applications you need. You’ll want to enable the Hyper-V role from within Server Manager, as well as install the Windows Azure SDK (which includes the Windows Azure Integration Components). It’s also a good idea to include the Windows Server 2008 R2 installation media (typically an ISO file) within the base image, in case you ever need it for tasks like installing additional components.
Next, install the Windows Azure Integration Components. These are required on every server image before you can upload it to Windows Azure. These components start every time the OS starts, and they integrate the VM role OS with Windows Azure.
The components work with the load balancer to communicate the state of the instances. The components also initialize the VM by installing certificates and creating local resource directories based on the service definition settings. You can find detailed steps for installing components at “ How to Install the Windows Azure Installation Components.”
Developing an “adapter” is an optional next step in the image-build process. When you develop and upload a custom server image, you’re installing and configuring software to run in the dynamic environment of Windows Azure. You may need to provide configuration information for your application that may not be available at development time. You’ll have to gather it at runtime. You’re advised to configure your applications for the dynamic environment by writing an adapter that interacts with Windows Azure and prepares and runs your application.
You have two options for writing an adapter:
One final step to prepare your system image to be uploaded to Windows Azure is to evaluate your Windows Firewall configuration. You’ll want to open any ports your application needs after it’s running on the VM role instance in Windows Azure. Your hosted service should use fixed local ports. You can specify port numbers for endpoints you define for any Windows Azure role—whether it’s Web, worker or VM.
Once you’ve completed the installation and configuration process, the final step in building your image is to prepare it for upload to Windows Azure. You’ll use the sysprep tool for this. The sysprep tool “generalizes” the image, removing any unique security identifiers (SIDs) so Windows Azure can re-establish them on a per-instance basis when the machine is deployed. To complete final image preparation:
When the sysprep operation is complete, the VM will shut down. Now you’re ready to deploy.
Deploying a VM to Windows Azure
The first step in deploying your system image is to configure management and service certificates. When you upload a .vhd file to Windows Azure, it uses an x.509 certificate, saved as a .cer file, for authentication (referred to as a management certificate in the Windows Azure Management Portal). You also need a Personal Information Exchange certificate, saved as a .pfx file (referred to as a service certificate in the Windows Azure Management Portal), if you plan to remotely access the VM role instance.
You can self-sign these certificates. In other words, there’s no need to purchase them from a third-party provider. You can create them yourself with the makecert.exe tool. There are detailed instructions for creating your certificates in “ How to Create a Certificate for a Role.”
Once you create your certificate, you can add it to the Windows Azure Management Portal. Select Hosted Services, Storage Accounts & CDN, then click Management Certificates or Hosted Services (for service certificates).
You need the subscription identifier to upload the VHD. You can copy and paste the information from the Management Portal to the command line. To find the subscription ID and the certificate thumbprint:
Once you find the certificate thumbprint and subscription identifier, you can upload the VHD.
To upload the image:
csupload Set-Connection "SubscriptionId=SubscriptionId; CertificateThumbprint=CertThumbprint"
csupload Add-VMImage –LiteralPath VHDName.vhd –Location LocationValue –Name DisplayedNameInPortal
This will display a dialog box for the Windows Azure VHD Verification Tool. This tool verifies that the OS is in the proper state and ready for uploading to Windows Azure. Click OK to continue the uploading process.
Note that the –LiteralPath and the –Location (or the –AffinityGroup) parameters are required. The –Name parameter is optional. The location or affinity group must match the location or affinity group defined for the corresponding hosted service.
Creating a service model is the final step for deployment. For a VM Role instance to run in Windows Azure, you must define the service model by creating the service definition and service configuration files. For detailed instructions, see the MSDN Library article, “ How to Create and Deploy the VM Role Service Model.”
Now that your VM is up and running in Windows Azure, you should keep a local copy of the original VHD as a secure backup. If you want to make changes to the VHD in the future—to apply updates or upgrade applications, for example—you can do so using differencing disks. You’ll find detailed instructions for using differencing disks to service your VM here: “ Getting Started with Changing a Server Image for a VM Role in Windows Azure.”
Joshua Hoffman is the former editor in chief of TechNet Magazine. He’s now an independent author and consultant, advising clients on technology and audience-oriented marketing. Hoffman also serves as editor in chief of ResearchAccess.com, a site devoted to growing and enriching the market research community. He lives in New York City.