Larry Franks and Brian Swan on Open Source and Device Development in the Cloud
We've talked previously about the Windows Azure command-line tools, and have used them in a few posts such as Brian's Migrating Drupal to a Windows Azure VM. While the tools are generally useful for tons of stuff, one of the things that's been painful to do with the command-line is export the settings for a VM, and then recreate the VM from those settings.
You might be wondering why you'd want to export a VM and then recreate it. For me, cost is the first thing that comes to mind. It costs more to keep a VM running than it does to just keep the disk in storage. So if I had something in a VM that I'm only using a few hours a day, I'd delete the VM when I'm not using it and recreate it when I need it again. Another potential reason is that you want to create a copy of the disk so that you can create a duplicate virtual machine.
The export process used to be pretty arcane stuff; using the azure vm show command with a --json parameter and piping the output to file. Then hacking the .json file to fix it up so it could be used with the azure vm create-from command. It was bad. It was so bad, the developers added a new export command to create the .json file for you.
azure vm show
azure vm create-from
Here's the basic process:
VM creation has been covered multiple ways already; you're either going to use the portal or command line tools, and you're either going to select an image from the library or upload a VHD. In my case, I used the following command:
azure vm create larryubuntu CANONICAL__Canonical-Ubuntu-12-04-amd64-server-20120528.1.3-en-us-30GB.vhd larry NotaRealPassword --ssh 22 --location "East US"
This command creates a new VM in the East US data center, enables SSH on port 22 and then stores a disk image for this VM in a blob. You can see the new disk image in blob storage by running:
azure vm disk list
The results should return somthing like:
info: Executing command vm disk list
+ Fetching disk images
data: Name OS
data: ---------------------------------------- -------
data: larryubuntu-larryubuntu-0-20121019170709 Linux
info: vm disk list command OK
That's the actual disk image that is mounted by the VM.
Alright, I've done my work and it's the weekend. I need to export the VM settings so I can recreate it on Monday, then delete the VM so I won't get charged for the next 48 hours of not working. To export the settings for the VM, I use the following command:
azure vm export larryubuntu c:\stuff\vminfo.json
This tells Windows Azure to find the VM named larryubuntu and export its settings to c:\stuff\vminfo.json. The .json file will contain something like this:
If you're like me, you'll immediately start thinking "Hrmmm, I wonder if I can mess around with things like RoleSize." And yes, you can. If you wanted to bump this up to medium, you'd just change that parameter to medium. If you want to play around more with the various settings, it looks like the schema is maintained at https://github.com/WindowsAzure/azure-sdk-for-node/blob/master/lib/services/serviceManagement/models/roleschema.json.
Once I've got the file, I can safely delete the VM by using the following command.
azure vm delete larryubuntu
It spins a bit and then no more VM.
Ugh, Monday. Time to go back to work, and I need my VM back up and running. So I run the following command:
azure vm create-from larryubuntu c:\stuff\vminfo.json --location "East US"
It takes only a minute or two to spin up the VM and it's ready for work.
That's it - fast, simple, and far easier than the old process of generating the .json settings file. Note that I haven't played around much with the various settings described in the schema for the json file that I linked above. If you find anything useful or interesting that can be accomplished by hacking around with the .json, leave a comment about it.
But, where in the JSON file is the Linux image you're using?
Hi JJ, the JSON file doesn't rebuild the VM from scratch, so it doesn't need to know about the source image. It just needs to know the VHD, memory, processor, etc. to rebuild the virtual hardware from. It recreates the hardware settings, then boots up the existing VHD using whatever OS is on that VHD.