Deploying VM Roles with Affinity Groups (and the pain of VMRole development)
Quick tip: When setting up your Windows Azure Hosted Services, if your planning on using VMRole instances, with a base image tied to an Affinity Group, make sure your Hosted Service belongs to that specific Affinity Group.
I found out the hard way, sometimes some obvious deployments aren’t so obvious. Let me explain:
I have a Affinity Group I named “Chicago”, which is specified to use only the “North Central US” Windows Azure datacenter(s).
I then uploaded a base image for my VM Role, anchored to that Affinity Group using csupload.exe (You can use the Add-VMImage cmdlet’s –AffinityGroup switch for that.)
I then created a Hosted Service, specifying “North Central US” as the location, rather than selecting the “Chicago” Affinity Group.
I figured, the same data center location, as the affinity groups datacenter location, would logically be the place here. Makes sense, right?
So, off to VS to deploy my services, and blam:
12:28:50 AM - Preparing...
12:28:50 AM - Connecting...
12:28:52 AM - Uploading...
12:29:35 AM - Creating...
12:29:53 AM - HTTP Status Code: 400/nError Message: One of the specified images cannot be used for creating the deployment . When you want to create a deployment that is based on a machine image, one of the following constraints must be met: (1) the hosted service and the image belong to the same affinity group, or (2) neither the hosted service nor the image belong to an affinity group, but their location constraints are the same, or (3) the hosted service belongs to an affinity group and the image has a location constraint equal to the location constraint of the affinity group. Here are the details about the current deployment:Image ericgolbase.vhd belongs to an affinity group named ff338672-edb1-42ac-b996-c76d9caae20e, which is in location constraint North Central US.Hosted service office365 is not in an affinity group. Its location constraint is North Central US. /nOperation Id: afa4e7ee-af01-43eb-aa0e-202c64c7882b
12:29:53 AM - Deleting O365
12:29:54 AM - There was no endpoint listening at https://management.core.windows.net/f26e43b8-7496-44c6-8611-45441ef15854/services/hostedservices/office365/deploymentslots/Production that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
12:29:54 AM - Deployment failed
Yeah, ok. ::Rolling Eyes:: So, I was a bit frustrated I would have to tear down, and recreate my service. Especially since I just got done uploading the service certificates I needed, and I didn’t want to have to wait to get any length of time to get my hosted services DNS name back on a re-create. Lucky for me, the process went smooth and I could continue to chow my salad while I waited a couple minutes, and re-start the deployment.
BTW, It also took me hours upon hours just to get my base image created this time around. Beware, this can be frustrating.
In my case, I usually dual boot from my laptop, either to Windows 7 Enterprise, or to Windows Server 2008 R2.
I use Windows Server 2008 R2 for Hyper-V, and have my laptop setup to use a VHD for that OS, since I also use Bitlocker Encryption all around.
(Bitlocker rocks BTW.. turning the laptop into a nice paperweight weighing a few kilos for anyone thinking of stealing a laptop, unless they invest in a hard drive and have the knowledge how to change the thing out. Major deterrent.)
My issue first was I couldn’t expand the VHD to boot into my OS, because I had run out of disk space (I have dual 120GB SSD drives too…).
After to cleanup with WinDirStat, and a portable USB (also bitlocker’ed.. ::evil chuckle:: ) I was back in business. [20 minutes spent.]
Then, a bunch of OS updates and reboots. Great, now I could get to image creation. [15 minutes spent.]
I used my MSDN account, and dl’ed the latest Windows Server 2008 R2 media, which took about 15 minutes on my Cable Modem. [We’re up to 50 minutes.]
Now I could get down to business:
1) Create the VHD – check.
2) Patch the VHD – check (with multiple reboots).
3) Install the Integration Components (Guest Agent) for Windows Azure – check.
4) Install my apps – check.
5) Sysprep the VM – check.
Finally ready to upload. [I’m at 90 minutes, yes, 40 minutes longer due to all the patching, even with the latest SP2 image from MSDN.]
Then, the upload.. 10.6GB, and, I had to –SkipVerify for some weird reason. [Add 3 hours, 46 minutes.]
Yes, over 5 hours to create a VMRole Image, and get it where it needs to be.
My hope is that over the course of the next year, some of the work our teams are doing will get this down to minutes, if not seconds, for our customers.