Note: If you skip all the way to the bottom of this post, you will see that Azure Caching is not supported on Extra Small role instances. This was discovered as I worked thru this problem. I left the blog post as is, because I feel it is a valuable learning exercise.

After upgrading our Azure Caching to the new model introduced in 1.7 and released in 1.8 of the Azure SDK, our continuous integration and deployment process failed with the following error:

Total requested resources are too large for the specified VM size

This occurred during the call to PowerShell cmdlet Set-AzureDeployment of our build/deployment script.

The root cause for this error was the introduction of the LocalResources/LocalStorage element in the ServiceDefinition.csdef file when the Azure Caching NuGet package was added to the solution with a value of 20000MB.

This page describes the various VM (role instance) sizes from Extra Small to Extra Large. We can see that the local storage for an Extra Small (what we are deploying to) is limited to 20GB. The default setting of 20000MB for LocalStorage exceeded the amount of local disk space available.

My first attempt to fix this problem was to change the value from 20000MB to 1024MB. However, I received a similar but slightly different error:

The size of local resources cannot be reduced. Affected local resource is DiagnosticStore in role BlueSky.Web. Current size is 4096. Requested size is 1024.

I made an assumption that the Local Storage size of 4096 is set by the regular Azure Diagnostics. So I adjusted the value to 4096 and redeployed.

<localresources>
    <!--If the diagnostic level is set to 2 or higher, this value must be increased to accommodate crash dumps which are several GBs in size-->
    <localstorage name="DiagnosticStore" sizeinmb="4096" cleanonrolerecycle="false" />
  </localresources>

What is Local Storage

The purpose of the Local Storage in this specific case is to act as a collection point for diagnostic data for the Azure Cache. It is unclear as to why the Azure Cache requires local storage to be explicitly defined where as the regular Azure diagnostics does not. According to this Stack Overflow post, the default of 20000MB size was chosen because this value would be large enough to hold the crash dump of a XL sized role instance as well as verbose logging information.

Under the CrashDump section for the configuration documentation for caching, it states that the purpose of the crash dump was designed primary for diagnosing problems with cache cluster machines. Since we are using the shared model and not dedicated role instances (cache cluster), there is no need for us to enable crash dumps, which reduces the amount of space we need for local storage.

You turn off crash dumps in the web or app.config for your application in the DataCache Section. See the configuration documentation for caching for more information. Another document that you may find useful is Troubleshooting and Diagnostics for Windows Azure Caching. It goes into what is logged for the various diagnostic levels.

Extra Small VM’s are NOT Supported

So while I had remembered reading back in the Azure 1.7 timeframe that Extra Small VMs were not supported, I had decided to give it a go in 1.8. Visual Studio gives you a warning, but that’s all. Also if you run your solution locally, it will work!

However, if you try to deploy, you will get an error in your management portal stating that the system startup task failed to execute for the given role instances. This forum post explains that Azure Caching requires dedicated CPU and Memory, which Extra Small instances do not have (but that your local dev machine does ).

Because of this, I decided to change the size of my web roles to Small and go back to the default 20GB local storage size to get rid of the other pesky warning. Long term, we’re going to have to look into creating some dedicated caching roles for our deployed test and stage environments to share so we can use extra small instances for the actual web role instances. 

One other little bit of advice, don’t ignore the little yellow warning notifications. In the screen shot above, you’ll see I’m trying to only use 2% for caching. That setting was not because we were running on Extra Small, but that we have a fairly low cache usage right now. The smallest I got down to was 15% without the yellow warning. I bring this up because if you set that value too low, your deployment might fail.