If you have been using Azure Pack and the VM Cloud Provider, you have most likely been tempted to use the concept of VM Roles too.
VM Roles is a powerful technology that makes it possible for you to provide a lot more than just a sysprep’d operating system to your tenants. Through a resource extension, a VM Role can be deployed with any application you’d like, ready to go for the tenants.
However, there has been some challenges since the release of Azure Pack and VM Roles.
Some of the challenges has been related to Azure Pack directly, and some of the challenges has been related to Virtual Machine Manager.
I won’t cover everything here, but the following picture should summarize some of the challenges of a VM Role and a stand-alone VM, where some parts such as “static disk” wasn’t enabled for VM Roles before UR5. With UR6, we also got support for Gen2 VMs as part of the VM Roles.
Also note that “backup” and “DR” on VM Role is categorized as a “no go”.
Luckily and as usual, David and his great team at Microsoft has listened to our feedback – and with Update Rollup 7 for Virtual Machine Manager 2012 R2, we are now able to re-associate a VM Role!
A couple of months ago, I reached out to the VMM team through David Armour and explained a rather bad situation for him that one of my customer suddenly was in the middle of.
It turned out that several of my MVP friends also had experienced similar issues and this was becoming a critical issue for those customers. Here’s some details around the problem we saw:
In the case of some underlying storage issues in the cloud environment, many of the virtual machines that was running in VMM, SPF and Azure Pack ended up in a pretty bad state, and the only way to solve it was to generate new IDs for those VMs.
Now, this sounds very tempting and applicable in certain scenarios. But given the fact that the VMs actually were part of a VM Role in Azure Pack, turned out to be a bad experience.
Once a VM is no longer associated with the VM Role in WAP, it will appear as a stand-alone VM with no way for you to perform advanced operations through the tenant portal. The VM Role itself will appear as an orphaned object.
Our biggest challenge in this satiation was:
1) There was no way to re-associate a VM instance with a VM role once this relationship was broken (so Remove-SCVirtualMachine with –Force parameter was not an option)
2) If we could re-associate with a VM role (once the VM appeared in VMM again with new ID), the usage would be broken for that VM. Yes the customer was actually using the usage API in WAP to charge their tenants.
For this customer the issue was most likely caused by some underlying storage problems. However, you could easily end up in a similar situation by using native Microsoft technologies such as backup/restore and DR through Hyper-V Replica/ASR. Or simplier, by removing and adding a host/cluster to a VMM Cloud
With Update Rollup 7, we have finally support for re-associate both an orpahned VM from a VM Role and a Service Template deployment.
Example of a PowerShell cmdlet that will join an orphaned virtual machine to a VM Role:
$myvm = Get-SCVirtualMachine –Name “KN01”
$myVMRole = Get-CloudResource –Name “mywebservice”
Join-SCVirtualMachine –VM $myvm –VMRole $myVMRole
For more information, please read the following KB: