Azure IaaS Disk Add Error

Today I saw that one of our Azure IaaS VM’s was getting low in disk space. The VM was configured with a number of data disks in a storage pool so adding a disk to expand space would not be a problem. In fact we have done this quite a few times for this specific VM, so the process is all too familiar. However this time I ran into a problem. I stepped through the process to add a new disk using the Azure Portal and received the following error:

Azure Disk Add Error
Failed to attach new disk ‘disk13’ to the virtual machine ‘server01’. Error: CannotAddOrRemoveNetworkInterfacesFromARunningVirtualMachine: Secondary network interfaces cannot be added or removed from a running virtual machine.

Wait….what? I can’t add a disk because I can’t add a NIC when the machine is running? But I’m trying to add a disk not a network adapter! I attempted to stop the VM to see if I could add this disk while the VM was offline. “No soup for you!

Failed to stop the virtual machine ‘server01’. Error: Secondary network interfaces cannot be added or removed from a running virtual machine.

What? Now what do I do? I restarted the guest OS and attempted a redeploy of the VM, but nothing worked. I opened a ticket with Azure support. After walking the support technician through my issue he was also stumped. However after a few hours of research he came back with the solution which was to force the first (and only) network adapter to be primary through PowerShell.

After executing these commands the VM shutdown without warning or intervention after which I was able to add my additional data disk, power on the VM, and get back to work.

I’m glad to find a solution, but this is definitely a pain point. I don’t have access to the hypervisor to force stop or reset a VM to fix the configuration through Hyper-V Manager, Failover cluster manager, or System Center Virtual Machine Manager. I know that’s not going to happen ever with Azure, nor should it. This is just one of those edge cases where you have to reach out to support for help.

Nugget of Wisdom

Purchase your Azure support before you need it. When you’re in the thick of it you don’t want to be establishing a support contract which can take time before you can even open a ticket.

Azure Cage Match: ASM vs. ARM

Ken vs Ryu

This year I embarked upon a journey into the world of the cloud, specifically Microsoft’s IaaS offering in their Azure public cloud. I’ve learned a lot, and I have oh so much more to learn. Over the next few posts I wanted to share the highlights and pain points that may help the next person.

Last time we met Azure IaaS, but it was a rather superficial introduction. We didn’t dive right into IaaS, because we discovered we had to answer a few key questions before deploying an infrastructure in Azure. When I began to stand up the new environment using Azure IaaS I was hit with an unexpected question. Which deployment model should I use?

Biggest question: Classic or Resource Manager

This question was unexpected because I didn’t even know there was more than one option, nor which one was the “right” choice for me. What I realized was that there are two different Azures, two different portals, two different architectures, resulting in twice the confusion, and twice the learning curve. I was at a crossroad. Do I stand up our environment in the classic environment or the new resource manager environment? I needed to research and compare each offering to determine which one was the best fit for us.

Azure Service Manager (known as ASM) is Microsoft’s first generation of cloud architecture. In the service manager model everything revolves around the cloud service. This is suitable for running your apps on IaaS VM’s, but not conducive to running real infrastructure roles. The networking in the ASM model provides only basic features, and the administrative model is a flat all our nothing approach. You’re an administrator or nothing, with no delegation of administration possible.

Microsoft’s second generation cloud architecture is known as Azure Resource Manager or ARM. Built from the ground up with role-based access control (RBAC) and a common deployment model, all your cloud assets are collected into resource groups. Azure Resource Manager has completely revamped networking which allows flexible virtual networks to be created. All current development efforts of Microsoft are being poured into the ARM architecture thus leaving ASM a legacy platform.

We deployed our first pilot in Azure Service Manager (“classic”) because at the time we found more documentation, blogs, and training online for ASM. However we quickly found some limitations that would eventually back us into a corner. When we began deploying a pilot in the Azure Resource Manager we discovered a lack of feature and functionality parity between the two portals. There were actions that existed in classic portal which didn’t yet exist in the new portal. Many of the actions and management changes required us to break out PowerShell. While I’m no stranger to PowerShell managing Azure through PowerShell was yet another learning curve. On top of that there are separate Azure PowerShell modules for each portal.

Despite the initial barriers to getting started with the new Azure Portal (ARM), the advice given to me from our consultant (and the general consensus of the Azure blogs and Twitter) was to push forward with the Azure Resource Manager architecture. We took this advice and began our deployment in Azure Resource Manager.

The Nugget of Wisdom

The rapid pace of development of Azure necessitates an always learning attitude from the whole team including development and operations. The evergreen model of change also means that not all features are fully baked when they are made available. Finally a strong knowledge of PowerShell is absolutely necessary when working with Azure as many features and settings are not available through the portal and can only be done through PowerShell.

Next time we’ll look at building out a virtual network.

It’s Patch Tuesday: Do you know where your patches are?

Now with with 10% real code.
Patch Rollups: Now with with 10% real code.

Starting tomorrow, October 11, Microsoft will change the way they deploy updates (and consequently so will you). Each month they will provide a single update containing all the security patches for that month and will be distributed via SCCM and WSUS only. In addition, they will publish a security plus fixes “quality” rollup update containing all of the current and previous months’ security updates as well as all previous non-security fixes. Both of them will be classified as security updates. Microsoft doesn’t really want us to approve both, but if you do it will (probably) work. IT professionals need to make a decision as to approve the security-only update or rollup or both. I typically deploy both security and critical updates where “critical” is the classification of update not the severity.

Critical Updates Classification from WSUS
Critical Updates Classification from WSUS

The critical update classification typically means a non-security fix. I’m trying to find out if the security plus fixes rollup means these critical updates that I normally approve. If that is the case then I will probably just go with the rollup update, especially since this is what Microsoft is recommending. Note that we will continue to have separate Internet Explorer and .NET framework rollups, as well as Office updates. Also bear in mind that this new process may provide “different” results for compliance tools (i.e. Nessus) since these two updates contain the same security updates and may report differently depending on the order in which they were installed if both were approved.

Thanks Mary Jo Foley for bringing this back to my attention.

Read More: