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!
Background:
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:
