Windows OS related Issue when you have VM Role and web/Worker Role in same Windows Azure Application

  • Article

I was recently working with a partner on their Windows Azure related Project in which there was a VM Role and ASP.NET Web Role within one application which was developed using Windows Azure SDK 1.3. VM role VHD was deployed successfully to the Azure Portal using CSUPLOAD and the Windows Azure application was deployed to cloud as well. After logging into ASP.NET based Windows Azure VM over RDP, what we found is that the OS on the VM is Windows Server 2008 SP2 however on Windows Azure Portal it shows Windows Server 2008 R2 Enterprise. Changing the OS setting on Azure Portal did not help at all and the ASP.NET based web role Windows Azure VM always had Windows Server 2008 SP2 OS on it.

 

After more investigation the following results were discovered and potential workaround concluded:

Issue:

Today, a service in Windows Azure can only support one Operating System selection for the entire service. When a partner selects his/her specific OS, it applies to all Web and Worker roles in the running service.

 

VM roles have slightly changed this model by allowing the partner to bring their own operating system and define this directly in the service model. Unfortunately, because of an issue in the way the OS is selected for Web and Worker roles, if a partner service has both a VM Role and a Web/Worker role, it is possible that the partner may NOT be able to change the operating system for the Web/Worker role and always be given the default OS for these specific role instances, which is the most recent version of the Windows Azure OS comparable to Server 2008 SP2. The partner will still be able to select the OS version and OS family through the portal; however, it will not be applied to the role instances. This does NOT impact the VM Role OS supplied by the partner.

 

This issue is due to the way the platform selects the OS using the service model passed by the partner. It will only occur when a VM Role is listed first in the internal service model manifestation. With this listing, the default OS version is applied to all web and worker roles, which becomes the latest version of the Windows Azure OS version comparable to Server 2008 SP2.

Workaround:

The workaround for this issue is fairly trivial. The internal service model manifestation orders the roles based upon their name, in alphabetical order. Therefore, if a partner has a VM Role AND a Web/Worker role in their service, to be able to apply a specific OS, the partner can rename their Web/Worker role with a name that is alphabetically higher than the VM Role. For example, the Web/Worker role could be named, “AWebRole” and the VM Role could be named “VMRole” and the OS selection system would work for this partner because AWebRole is alphabetically higher than VMRole.

What about the fix:

I would say that, this issue is known to Windows Azure team and as VM Role is in BETA so we all can hope for something different by the time VM Role hits RTM however there is nothing conclusive I have to add.