VirtualMachineService

The VirtualMachineService class is likely to be used extensively, and it contains additional methods not inherited from ResourceBaseServiceClass, so we cover it in some detail here.

Getting Started

# Get your VirtualMachineService instance
vms = Azure::Armrest::VirtualMachineService.new(conf)

Common Methods

The VirtualMachineService class supports the common methods available to all ResourceBaseGroupService subclasses.

rg = 'some_resource_group'

vm = vms.get('some_vm', rg)
vms.list(rg).each{ |vm| p vm.name }
vms.list_all.each{ |vm| p vm.name }
vms.delete('some_vm', rg)

Instance View vs Model View

Unlike other resource types, there are two possible "views" for a virtual machine - instance view and model view. The difference is in the type of object and information they return. By default, the get method retrieves the model view since it includes information about the model that was submitted to Azure, and is similar to the output used for the create method. The instance view largely returns status information for the VM.

You have the option to pass a 3rd parameter to the get method, or to use an explicit method.

# Examples:

vms.get('some_vm', rg)            # => Gets model view
vms.get_model_view('some_vm', rg) # => Same as above

vms.get('some_vm', rg, false)        # => Gets instance view
vms.get_instance_view('some_vm', rg) # => Same as above

Series

The series method returns a list of VirtualMachineSize objects that contain information about available VM sizes that can be provisioned.

series = vms.series.first

p series.name
p series.number_of_cores
p series.os_disk_size_in_mb

Generalize

The generalize method is used when preparing to save a VM as an image.

Note that you must still run the sysprep command on the VM in question. In practice, you are more likely to pass the -generalize switch to the sysprep command than use this method, but it's here if you need it.

Capture

The capture method saves an already generalized and sysprep'ed image to the storage account associated with the VM. You can pass :vhdPrefix, :destinationContainerName and :overwriteVhds as options.

Note that the :destinationContainerName will actually be nested under "system/Microsoft.Compute/Images".

Deallocate

The deallocate methods stops and deallocates, but does not destroy, a virtual machine.

Power Operations

The start, stop and restart methods are all available as power operations for an Azure VM.

# Example:

vms.stop('some_vm', 'some_group')
vms.start('some_vm', 'some_group')
vms.restart('some_vm', 'some_group')

Note that all power operations are asynchronous. It is up to you to poll them if you need to check their status.

Deleting associated resources

When you delete a VM in Azure it does NOT delete the associated resources. Any NIC's, storage accounts, virtual files, etc, remain afterwards. Unfortunately, neither the portal nor the CLI provide a way to automatically delete associated resources. This is a conservative approach by Microsoft, in that they do not want to make any assumptions about how you use your resources, since you may want to re-use those resources for other virtual machines.

While this approach is safe, it is often not pragmatic. Manually implementing a custom method yourself to do this can be error prone because resources must be deleted in a specific order, and because delete operations are asynchronous, meaning it's easy to get yourself bogged down in race conditions.

Fortunately, the azure-armrest gem provides a method for your convenience that will automatically delete the associated resources of your choice. It automatically handles handles asynchronous deletions, and deletes resources in a particular order.

Below is some sample code showing you the types of resources that you can select, and their defaults.

vms.delete_associated_resources(
   :network_interfaces      => true,  # NIC
   :ip_addresses            => true,  # PublicIP
   :os_disk                 => true,  # The underlying .vhd file
   :network_security_groups => false, # The associated network security group(s)
   :storage_account         => false  # The entire storage account
)

Note that some resources may be attached to multiple resources. As a rule, an attempt to delete a resource that is still associated with another resource, will cause a failure from Azure. So, you needn't worry about accidentally deleting a storage account, for example, that was serving as the storage for other virtual machines. It will simply fail, and a warning will be sent to your log (or stdout).

Additional Information

• Provisioning a VM from a Snapshot for creating a VM from a snapshot.

• Provisioning a VM from Scratch for creating a VM from the Marketplace.