Did you know that by default your Azure subscription has a limit on the number of CPU cores you can consume for virtual machines? Until recently I didn’t. Maybe like you I’d only ever created one of two small virtual machines (VMs) within my MSDN subscription for testing and always ended up deleting them before coming close to the limit.
Per Azure subscription the default quota for virtual machine CPU cores is 20.
To clarify because the relationship between virtual and physical CPU cores can get a little confusing. This initial limit is directly related to what you see in the Azure portal when sizing your VM during creation.
For example, using the range of basic virtual machines to the right you would hit your default limit with;
- 10x A2 Basic’s
- 5x A3 Basic’s
- 2.5x A4 Basic’s (if it were possible to have 0.5 of a VM)
Fortunately this initial quota is only a soft limit and easily lifted for your production Azure subscriptions.
Before we look at how to solve this problem it’s worth learning how to recognise when you’ve hit the VM CPU core limit, as its not always obvious.
Limit Symptoms Lesson 1
When creating a new VM you might find the some of the larger size options are greyed out without any obvious reason why. This will be because consumed cores + new machine size cores will be greater than your current subscription limit. Therefore ‘Not Available’. Example below.
The other important quirk here is that the size blade will only dynamically alter its colourations and availability state if the CPU cores are currently being used in VMs that are running. If you have already reached your limit, but the VMs are stopped and appearing as de-allocated resources, you will still be able to proceed and deploy another VM exceeding your limit. This becomes clearer in lesson 2 below where the failure occurs.
Limit Symptoms Lesson 2
If you are unlucky enough to have exceeded your limit with de-allocated resource and you were able to get past the VM size selection without issue your new VM will now be deploying on your Azure dashboard if pinned. All good right?… Wrong! You’ll then hit this deployment failure alert from the lovely notifications bell. Example on the right.
Note; I took this screen shot from a different Azure subscription where I’d already increased my quota to 40x cores.
This could occur in the following scenario.
- You have 2x A4 Basic virtual machines already created. 1x is running and 1x is stopped.
- The stopped VM meant you were able to proceed in creating a third A4 Basic VM.
- During deployment the Azure portal has now done its sums of all resources covering both stopped and running VM’s.
- 8x cores on running VM + 8x cores on stopped VM + 8x cores on newly deployed VM. Total 24.
- This has exceeded your limit by 4x cores.
- Deployment failed.
In short; this is the difference in behaviour between validation of your VM at creation time vs validation of your VM at deployment time. AKA a feature!
Limit Symptoms Lesson 3
If deploying VMs using a JSON template you will probably be abstracted away from the size and cores consumed by the new VM because in default template this is just hardcodes into the relevant JSON attribute.
Upon clicking ‘Create’ on the portal blade you will be presented with an error similar to the example on the right. This is of course a little more obvious compared to lesson 1 and more helpful than lesson 2 in the sense that the deployment hasn’t been started yet. But still this doesn’t really give you much in terms of a solution, unless you are already aware of the default quota.
Apparently my storage account name wasn’t correct when I took this screen shot either. Maybe another blob post required here covered where the Azure portal is case sensitive and where it isn’t! Moving on.
As promised, the solution to all the frustration you’ve encountered above.
To increase the number of CPU cores available to your Azure subscription you will need to raise a support ticket with the Azure help desk… Don’t sigh!… I assure this is not as troublesome as you might think.
Within the Help and Support section of your Azure portal there are a series of predefined menus to do exactly this. Help and Support will be on your dashboard by default, or available via the far left hand root menu.
Within the Help and Support blade click to add a New Support Request. Then follow the prompts selecting the Issue Type as ‘Quota’, your affected Subscription and the Quota Type as ‘Cores per Subscription’.
Once submitted a friendly Microsft human will review and approve the request to make sure it’s reasonable…. Requesting 1000 extra CPU cores might get rejected! For me requesting an additional 30 cores took only hours to get approved and made available. Not 2 – 4 business days as the expectation managing auto reply would have you believe.
Of course I can’t promise this will always happen as quickly so my advise would be; know your current limits and allow for time to change them if you need to scale your production systems.
I hope this post saved you the time I lost when creating 17x VMs for a community training session.
Many thanks for reading.
So the second challenge I faced after unboxing and plugging in my new workstation at Purple Frog Systems was software. Having customers using all versions of SQL Server from 2005 onwards I didn’t want to tie myself to a particular version locally and I also didn’t want the hassle of running lots of different SQL Server services all on the same host operating system. Especially if I wanted to use Windows 10 as my host, which as we know would have compatibility issues with SQL Server 2005 and our old friend BIDS.
Enter Microsoft Hyper-V
In Windows 8 onwards Hyper-V is available out of the box as a feature which can simply be switched on from Control Panel > Programs and Features > Turn Windows Features On or Off. Apologies in advance if the home editions don’t support this.
Note: be sure to select the Hyper-V Module for Windows PowerShell.
Now with my Windows 10 host now running Hyper-V management services I set about creating a bunch of virtual machines to serve up every version of SQL Server required.
Whenever starting the Hyper-V manager always do so as an administrator. The user interface throws some odd errors without the elevated permissions which could lead you down a rabbit hole of Google searches. Trust me!
Creating a Virtual Switch
For those of you new to Hyper-V creating a virtual switch for your guess virtual machines is one of the most important things to get right and sort out first. It’s very simple to do, but without it your network admins and DHCP police might start questioning what on earth your physical network connection is doing. Again, trust me on this!
From your Hyper-V Manager toolbar go to Action > Virtual Switch Manager. In the dialogue window that appears in the right hand panel choose the switch type of External and click Create Virtual Switch. Give the switch a name and select the External Network: that the new switch will basically impersonate. This will be a sort list if you only have 1x physical network connection.
With an external virtual switch in place any guess machine setup to use it as a network resource will appear on your network in the same way your physical host does. It’s own MAC address, IP address, hostname etc. Also be mindful that Hyper-V will take over how your network connections appear in your host operating system and a CMD ipconfig /all will start to look a little more complex, but this is nothing to worry about and perfectly normal.
Creating the Guest Virtual Machines
To offer some repeatability when creating my guest virtual machines I broke out the PowerShell, hence including the module at install time. With a few parameterised cmdlets I was able to setup several empty virtual machines ready for my guest operating systems. Example below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
#Create hyperv machine New-VM ` -Name $VMName ` -Path $VMLocation ` -MemoryStartupBytes $RAM ` -NewVHDPath $VHDOSFile ` -NewVHDSizeBytes $VHDSizes ` -SwitchName $NetworkSwitch ` -Generation $Generation #Set Number of CPUs Set-VMProcessor ` -VMName $VMName ` -Count $CPUs #Create data disk New-VHD ` –Path $VHDDataFile -Dynamic ` –SizeBytes $VHDSizes `
Download the full script I used here.
Note: I’m not a PowerShell expert, just a big fan of it’s uses.
You’ll see in the full script that I give my virtual machines 2x hard drive files each on different controllers (IDE and SCSI), which are in turn are created on different host hard drives, mainly because my host has 3x physical disks. My original intention was to have all operating systems on mechanical disks and all data on solid state disks. So for guess SQL Server installs the virtual machine data disk would be used to house databases attached to the instance. In practice this didn’t really pay off but then this is just another advantage of using Hyper-V, that the underlying resources can be moved around as required.
If you have time I would recommend having you ISO’s on a separate physical disk to the guess hard drive files. This greatly speeds up installation. You could even run the guess OS hard drive files on your solid state drive just for installation, then move them to mechanical disks afterwards.
Assuming you now have a bunch of virtual machine shells in place I’d recommend the following operating systems vs versions of SQL Server. Mainly to avoid any compatibility issues.
- SQL Server 2005 – Windows Server 2003
- SQL Server 2008 – Windows Server 2008
- SQL Server 2012 – Windows Server 2012
- SQL Server 2014 – Windows Server 2012
- SQL Server 2016 – Windows Server 2016 (assuming the OS is released in time)
I’m not working to talk about installing Windows and SQL Server on each guest. I’m assuming your familiar with that Next, Next, Next process (if you want the defaults!). However I would say that for SQL Server 2012 onwards I did this twice for Analysis services to give me both Tabular and Multi Dimensional services in my guess virtual machine.
If you’ve worked through this post and setup your host in the same way I have you’ll now be able to enjoy the advantages and flexibility of running all versions of SQL Server at the same time with all SQL services in guess virtual machines on your developer worksation.
My virtual machines are also setup with dynamic RAM:
- Initial value: 2048 MB
- Min value: 512 MB
- Max value: 8192 MB
The Memory Weight slider is great if you want to keep all your guess virtual machines running at the same time like I do. If doing some development work on SQL Server 2005 I simply increase that guests RAM priority which dynamically adjusts the less used virtual machines so the host doesn’t get overwhelmed. Plus you’ll only be developing on one version of SQL Server at once right?!
The last thing you’ll probably want to do is install some SQL Server client tools on your Windows 10 host. I went for SQL Server 2012, plus Visual Studio 2012. Then SQL Server 2014, plus Visual Studio 2015. Installed in that order.
Please be aware that the above was only possible with a Microsoft MSDN subscription which provided licencing for the guest operating systems and older versions of SQL Server.
During this setup I also had the advantage of being a domain admin, which meant creating things like service accounts for all my virtual machines was easy, adding my virtual machines to the domain and accessing SQL Server services from my host using AD authentication made easy. If you not a DA SQL authentication and local workgroups is ok, but has its limits for SSAS.
You may want to try using Remote Desktop Connection Manager to access your guess operating systems. In the latest version a VM ID can be including giving console style access without needing to connect to each guess from the Hyper-V manager.
VM IDs can be found with the following bit of PowerShell.
Get-VMMemory -VMName "PF*" | Select VMName, ID | Sort-Object VMName
Very last thing, I mentioned my host machine had 3x physical hard drives. The third of which is a huge 4 TB block. To keep my guest operating systems fairly customer independent you’ll have seen I only gave the standard virtual hard drives in PowerShell 100GB of space each. What I then do is give a guest an additional virtual disk much larger in size which resides on the host big data volume. Work is done here. Then post project completion this customer specific virtual data disk can just be dropped/archives/moved away and the guest machine ready for the next work item. It’s of course a management overhead, but helps keep things clean.
Many thanks for reading.