Creating the VM Role in an Azure Service

A VM Role is configured as a Role within a larger Hosted Service.  This is no different from a Web or Worker role except for the additional steps of creating and uploading the base VHD that the Role instances will be provisioned from.

The following example uses Visual Studio 2010 with the Azure SDK Installed to define and publish the service. It is important that the latest Azure SDK is installed, the VM Role capability is enabled, and Visual Studio is already configured to manage your subscription.

Create the VM Image

1. Begin by creating a VM using Hyper-V

   1. The VHD size cannot exceed 15 Gb for an Extra Small VM, 30 GB for a Small VM, or 64 GB for a Medium to Extra Large VM.

   2. http://msdn.microsoft.com/en-us/library/gg465391.aspx

2. Install Server 2008 R2

   1. Apply Windows Updates

   2. Add .Net Framework 3.5.1

3. Install and configure your application(s)

   1. Be aware that the image will be prepared with sysprep. When provisioned, the VM will be unique and will complete mini setup.  Therefore the application must be in a state that is compatible with sysprep.  Any additional configuration that must be performed after mini-setup is complete should be scripted using a custom service, or defining Syncronous Commands in the unattend.xml created by step 4.

4. Install the Azure VM Integration Components.

   1. http://msdn.microsoft.com/en-us/library/gg465409.aspx

   2. This generates an unattend.xml at the root of the system drive (with the Administrator password prompted for).  This unattend.xml is very specific to the VM successfully provisioning on Azure.  Sections can be added to the XML file, but not deleted.

5. Install Azure Connect endpoint agent if it will be used.

6. Apply any modifications to the unattend.xml to support installing or configuring your application.

   1. A combination of scripts or commands and the FirstLogonCommands and SynchronousCommand keys can be combined with the AutoLogon to orchestrate the actions.

7. Run sysprep to generalize the image

   1. http://msdn.microsoft.com/en-us/library/gg465407.aspx

   2. sysprep /generalize /oobe /shutdown /unattend:"C:\unattend.xml"

Upload the VM (vhd) image

1. Upload the VHD using the csupload tool that is included with the SDK.  This is accessed by launching the SDK Command prompt using "Run As Administrator".

   1. http://msdn.microsoft.com/en-us/library/gg465385.aspx

Author and Deploy an Azure Service

1. http://msdn.microsoft.com/en-us/library/gg465379.aspx

   1. External endpoints are ports that are available publically in front of the load balancers and mapped to a particular role.

   2. Internal endpoints are available behind the load balancers and can be used to define specific endpoints (open TCP ports) for machine to machine communication. 

   3. Be aware that you cannot use FQDNs or DNS or the like – the intercommunication involves enumeration of role instances using Azure Service Runtime components combined with proper configuration using IP addresses.

Unable to start additional virtual machines when Hyper-V has plenty of resources

Ben Armstrong from the Hyper-V team just published a really interesting blog article about CPU Reserves.

The thing that you really need to think about here is how tweaking these settings impacts your virtualization environment as a whole – and Ben spends some time trying to relate that concept.

http://blogs.msdn.com/b/virtual_pc_guy/archive/2011/02/14/hyper-v-cpu-scheduling-part-1.aspx

In the forums I frequently advise folks to leave the knobs and buttons alone unless you have a really good reason for modifying them.  Why?  Because the system is designed to self manage and it does a really good job of it.

The place where you get into problems is not from tweaking a single VM on a single hypervisor.  This usually works.  The problems come when that VM is moved to another hypervisor, for any number of reasons.

After moving to another hypervisor the environment changes, how that VM interacts changes, the settings on the other VMs are different, and so on.

The big take away from Ben’s article is – if you change the settings, understand what you are doing and how it impacts the entire environment, not just this VM.

The little take aways: don’t change the settings unless you really need to, if you do change the settings be sure to document what and most importantly WHY, and tweak as few as absolutely possible.

Think on that a bit, and if you like play around a bit – it will all come clear once you create a conflict caused by a setting that the environment should be able to support.

Tuning SCVMM for VDI deployments - Vishwa Kumbalimutt's blog

 

Tuning SCVMM for VDI deployments - Vishwa Kumbalimutt's blog - Site Home - TechNet Blogs

I have only re-blogged articles a very, very few times – but this is one that I feel is really important to any folks who are using SCVMM in a VDI scenario.

Many of these tweaks I have know about for a few years but have been asked to not share them.  Now that a MSFT person has spilled the beans you all can benefit.

I am not going to go into the details, but all of the tweaks are highly useful.  The one I have found most useful in my work (when moving into scales of over 400 VMs) is the tune for Windows Communication Framework.

Don’t get me wrong, all of these tweaks are golden to any deployment of XenDesktop that uses SCVMM.