In an Azure Linux VM, what persists? what disk is charged for?

Question

I created a Small Linux VM in Microsoft's Azure. I also created a 20GB BLOB and mounted it as a filesystem.

On my VM, I see the following:

• root filesystem: about 28GB
• boot filesystem: about 500MB
• my 20GB filesystem
• /mnt/resource - 69GB

So I have questions:

(1) If I power down the VM and then power it back on later, which of those filesystems/volumes will persist in the state they were in when the VM was powered down? This has been the case for each volume (I tested) but "it worked in a test" is not the same as a guarantee.

(2) If the VM needs to move because there is some kind of hardware fault or failure in the Azure environment ("self-healing migration"), which of those filesystems will persist? I suspect root will, but not /mnt/resource?

(3) In the azure management portal, I have a 30GB disk that was created when I created the VM. Is the cost of that disk part of the cents-per-hour VM charge, or is that a separate charge? I think it's separate.

(4) Supposedly a Small VM comes with 165GB for "Disk Space for Local Storage Resources in a VM Role": http://msdn.microsoft.com/en-us/library/windowsazure/ee814754.aspx I see 69GB - where'd the rest go?

You'd think I could ask Microsoft these questions, but when I did they said Linux VMs are in "preview" and their support refuses to answer any Linux VM questions, except to point to the rather ghost-towny Azure forums.

Answer 1

I've not worked with the IaaS instances using Linux yet, but I think I can answer some of these based on my understanding of how the infrastructure works in general.

When you create a VM you have the OS Disk (which maps to your root above, and I believe the boot as well though I think that is a Linux based artifact and isn't there when using Windows). This OS Disk is stored in Windows Azure BLOB storage as a VHD, Page BLOB. The same with the 20 GB Data Disk you created. These are the drives that will reliably persist and ONLY these drives.

1) In your test of powering down, did you actually delete the deployment or simply "turn it off"? Turning off the VM will leave it deployed (and thus on the same physical machine). Just being turned off doesn't keep you from being charged as it is actually still deployed. If you delete the deployment, and then create a new deployment later pointed to the same OS and data disk you created (you'll find them in your gallery) you'll get a better idea of what will happen if the VM got moved due to self healing as it will be brought up very likely on a different physical server. See below why I think the "resource" drive stuck around.

2) You are correct, I believe the resource drive is similar to what we see on the Windows side as the D:/ drive. This is temporary, scratch space. The drive itself is also a VHD and is located NOT in BLOB storage, but actually on the physical server the VM is running on. For Windows this is where the memory page file is kept in order to keep the latency for page file access as low as possible. They are very adamant about the fact that this is a NON persisted drive. In your case this may have stuck around if all you did was turn off the instance. When the instance powered back on it was still on the same physical server, therefore the same local resource was allocated to it, thus data you had put there would still be there. If the instance was redeployed the data would not be there anymore.

3) The Disks you see (the OS Disk as well as the Data Disk) are both stored in BLOB storage as Page BLOBS. The storage costs of these disks are separate from the per hour charge to actually be running the VM. You are also charged storage transactions to access the data on these disks as they are running. From the pricing page check this quote:

Compute hours are charged whenever the Virtual Machine is deployed, irrespective of whether it is running or not. Compute hours do not include any Windows Azure Storage costs associated with the image running in Windows Azure Virtual Machines. These costs are billed separately.

4) I believe the resource drive you are seeing is that D:/ drive equivalent and NOT the local resource space that you have pointed to. What you have pointed to is talking specifically about getting access to local space when running in a Cloud Service (or previously known as a Hosted service), so using a Web or Worker role. I'm not sure that applies in the same way when using Virtual Machines. In addition to the page file when using Windows I believe this resource space is also used a little when you setting up data caching for the data or OS disks, which would reduce the amount of space you'd have as well. This is speculation on my part though.

You may also want to understand the caching options and restrictions with OS and data drives. Michael Washam touches on it in a blog post.