We’ve seen the basic concept of Azure IaaS in my last article. This article will take a deeper look at how Images and Disks are being used in Windows Azure Virtual Machine. Later in the article I’ll bring you another tutorial to let you have better understanding and hands-on experience.
There are two basic yet important concepts in Windows Azure Virtual Machine: Images and Disks. Although both of them are eventually in VHD format, there are significant differences between them.
Images are virtual hard drives (VHDs) that have already been generalized (technically, been sys-prepped /generalize). They are basically templates that will be used to clone the Virtual Machine. They come without any specific settings such as computer name, user account, and network settings.
Predefined / Platform Images
Windows Azure provides numbers of predefined images including Windows and Linux. The following figure shows the predefined images on Windows Azure as of today.
Creating or Bringing Our Own Images
Apart from predefined image, we can actually provide our own images as well. This will be certainly useful when we want to reuse the configured VM in the future. It could be done either by capturing a running VM on Windows Azure or uploading the VHD On-Premise with CSUPLOAD.
Both techniques require us to sysprep the VHD properly. Eventually, the image should be created in the portal.
Disks are the actual VHDs that are ready to be mounted by the Virtual Machine. There are two kinds of Disk: OS Disk and Data Disk.
OS Disk is a VHD that is being instantiated by an image and obviously contains operating system files. At the time a VM is being provisioned, the OS Disk will be automatically created and mounted as C:\ drive.
The default caching policy for OS Disk is enabled for ReadWrite. Meaning that, although the OS Disk is stored at Windows Azure Storage as Page Blob, there will be a caching disk sitting on the host OS. At any time reading / writing happens on the OS Disk, it will always reach the caching disk first and gradually flush them to Blob Storage. The reason why ReadWrite cache being enabled for OS Disk is because the usage pattern that Azure team expects. As the working sets of data being read and written are relatively small, it fits perfectly to have a local cache so that it can perform efficiently.
The maximum size of OS Disk is 127 GB as of today. The recommended approach is to let customers store larger data in the Data Disk.
Data Disk is VHD that allows us to store any data. The Data Disk can then be mounted on the VM. T As the data disks are stored in Windows Azure Blob Storage as page blobs, it inherits from the maximum size of 1 TB. However, there are limits on how many disk can be mounted. This depends on the size of Virtual Machine as presented below.
The default caching policy for Data Disk is “None” or No Cache. This means that when any reading or writing happens, it always goes directly to Blob Storage.
Apart from OS Disk and Data Disk, there is also a temporary disk stored in the VM itself. This is used for the OS Paging file. Importantly, the disk is considered not persistent.
The following diagram illustrates how the disks are being stored in Windows Azure Storage.
A hands-on tutorial
We have talked about the concepts above. Now let’s jump into the demo to see them in action. I assume you have gone through the tutorial in my previous article, please do so if you have not.
Attaching Disks to Virtual Machines
1. Log in to New Management Portal with your Live Id. After successfully logging in, navigate to the Virtual Machine section and you will see the Dashboard tab appear. At the bottom part of Dashboard, you will notice the “disk” section. By default, there is only one disk attached, which type is OS Disk. If you notice carefully, the OS Disk VHD refers to Windows Azure Storage URL.
2. Now, click on the “Attach” button and select the “Attach Empty Disk”.
As the dialog box show up, define the File Name as “DataDisk1” and Size as “1023”.
It may take a while (2 to 3 minutes) to get the Data Disk ready.
3. Repeat Step 2 one more time. Define File Name as “DataDisk2” and let the Size remain the same as “1023”.
4. After a while, you can see that there are two additional data disks being attached besides the original OS Disk.
5. Click “Connect” to remote desktop inside the VM. When the RPD file is prompted, simply open it.
6. Once you have successfully remote desktopped inside the VM, open up Server Manager and expand the Storage – Disk Management Menu.
7. You might be prompted with the Initialize Disk dialog. This dialog appears since we have just attached two disks on the VM but haven’t initialized them yet. We are required to select the partition type either: MBR and GPT. In this demo, we select “MBR” and click “OK”.
Striping Volume to Data Disks in VM
The earlier section of this article mentions that the maximum size of each blob is 1 TB. People often make the mistake of thinking that the maximum size of data you can store in Azure Disk is 1 TB. This is not really true, as we can actually store up to 16 TB data (for Extra Large VM). The idea is to use Striped Volume in Windows.
8. Right click on “Disk 2? which we have just initialized and click “New Striped Volume”.
9. As the dialog comes up, add the “Disk 3” on the Available list and click “Add”. Click “Next” to proceed.
10. Choose your preferred Drive Letter. In this example, I selected E. Click “Next”.
11. The next step is about formatting the volume. Simply give the volume a label. In this case, I call it DATA. Click “Next” to finalize the wizard
12. Open up Windows Explorer, notice that the DATA Volume can take up to 2 TB size as they are basically stored in two different Data Disks.
Conclusion and coming up next
We’ve seen how the image and disk being design and used in Windows Azure Virtual Machine.
In the subsequent article, we will discuss other aspects of Windows Azure IaaS in more detail such virtual network capabilities and also how PaaS and IaaS work together to bring more possibilities.
Technical Reviewer: Corey Sanders, Principal Program Manager Lead, Microsoft Corporation.