Virtual Machine Provisioning Objects
When we write our own automation scripts to interact with the virtual machine provisioning workflow, we need to know how to locate the useful service model objects that are involved in the process. We might for example wish to determine the virtual machine operating system being provisioned, so that we could decide whether or not to register the new VM with a Red Hat Satellite Server. Our experience up to now tells us that this is likely to be a service model attribute, but which one?
This chapter will examine the main service model objects that are involved in the virtual machine provisioning workflow, and how and why we access them.
Object Overview
There are several service model objects involved in the virtual machine or instance provisioning process, but we generally only work with four of them when we write our own Automate methods to interact with the provisioning workflow (see VM Provisioning Objects).
Figure 1. VM Provisioning Objects
The Provision Request Object
We’ve discussed the provision request object in detail already. It is the object that contains all of the information relating to the virtual machine provisioning request.
Request Context
When working at the request stage of the provisioning process (i.e., prior to approval), we can access the provision request object directly from our workspace:
$evm.root['miq_provision_request']There are a number of useful attributes that we can read from the provision request object, including the requester (person) details, and we can set key/value pairs in the options hash to control the virtual machine provisioning process itself.
The provision request object has a number of useful methods that we can use, such as:
miq_provision_request.add_tag
miq_provision_request.approve
miq_provision_request.authorized?
miq_provision_request.check_quota
miq_provision_request.ci_type
miq_provision_request.clear_tag
miq_provision_request.deny
miq_provision_request.description=
miq_provision_request.eligible_resources
miq_provision_request.get_classification
miq_provision_request.get_classifications
miq_provision_request.get_folder_paths
miq_provision_request.get_option
miq_provision_request.get_option_last
miq_provision_request.get_retirement_days
miq_provision_request.get_tag
miq_provision_request.get_tags
miq_provision_request.pending
miq_provision_request.register_automate_callback
miq_provision_request.set_cluster
miq_provision_request.set_customization_template
miq_provision_request.set_dvs
miq_provision_request.set_folder
miq_provision_request.set_host
miq_provision_request.set_iso_image
miq_provision_request.set_message
miq_provision_request.set_network_adapter
miq_provision_request.set_network_address_mode
miq_provision_request.set_nic_settings
miq_provision_request.set_option
miq_provision_request.set_pxe_image
miq_provision_request.set_pxe_server
miq_provision_request.set_resource
miq_provision_request.set_resource_pool
miq_provision_request.set_storage
miq_provision_request.set_vlan
miq_provision_request.set_vm_notes
miq_provision_request.set_windows_image
miq_provision_request.src_vm_id
miq_provision_request.target_typeIn particular, notice the various set methods that are available to define values for some options hash keys (see The Options Hash for more details on these methods).
Task Context
When working at the provision task stage we have a different workspace ($evm), and here $evm.root does not link directly to miq_provision_request. We can however still get to the provision request object via an association from the miq_provision task object:
$evm.root['miq_provision'].miq_provision_request|
Note
|
By the time we’re in the provision task, setting options in the provision request object will have no effect. It’s still useful however to be able to read values from the provision request object when at the provision task stage of the virtual machine provisioning process. |
The Provision Task Object
The provision task object is created once the virtual machine provisioning request has been approved. Most of the information in the provision request object - most important, the options hash - is propagated into the provision task object.
The provision task object has a similar set of methods to the request object:
miq_provision.add_tag
miq_provision.check_quota
miq_provision.clear_tag
miq_provision.eligible_resources
miq_provision.execute
miq_provision.finished
miq_provision.get_classification
miq_provision.get_classifications
miq_provision.get_domain_details
miq_provision.get_domain_name
miq_provision.get_folder_paths
miq_provision.get_network_details
miq_provision.get_network_scope
miq_provision.get_option
miq_provision.get_option_last
miq_provision.get_tag
miq_provision.get_tags
miq_provision.message=
miq_provision.register_automate_callback
miq_provision.set_cluster
miq_provision.set_customization_spec
miq_provision.set_customization_template
miq_provision.set_dvs
miq_provision.set_folder
miq_provision.set_host
miq_provision.set_iso_image
miq_provision.set_network_adapter
miq_provision.set_network_address_mode
miq_provision.set_nic_settings
miq_provision.set_option
miq_provision.set_pxe_image
miq_provision.set_pxe_server
miq_provision.set_resource
miq_provision.set_resource_pool
miq_provision.set_storage
miq_provision.set_vlan
miq_provision.set_vm_notes
miq_provision.set_windows_image
miq_provision.statemachine_task_status
miq_provision.target_type
miq_provision.user_message=The most important of these is execute which launches the internal virtual machine provisioning state machine. [1]
The Source Object
When provisioning a virtual machine from template, we need an object to represent the source template itself; this is the source object.
The source object is accessible via either of two associations from a request or task object:
$evm.root['miq_provision_request'].source
$evm.root['miq_provision_request'].vm_templateor
$evm.root['miq_provision'].source
$evm.root['miq_provision'].vm_templateWe can therefore access the source object when working in either request or task context.
The source object contains a very useful attribute:
source.vendor
This has the value of either "RedHat", "VMware" or "Microsoft" if we’re provisioning to an infrastructure provider. We can use this to determine the provider type for this provisioning operation, and make workflow decisions accordingly. This attribute is used in several places in the out-of-the-box VMProvision_VM state machine to select the appropriate Instance to handle vendor-specific tasks such as virtual machine placement, i.e.
/Infra.../VM/Provisioning/Placement/default#${/#miq_provision.source.vendor}
There is also an equally useful virtual column:
source.platform
This has the value of either "linux" or "windows", and we can similarly use it to make provisioning workflow decisions. We would typically use it to decide whether or not to register a new virtual machine in Foreman/Satellite 6 as part of the provisioning process, for example.
All of the source object classes extend from MiqAeServiceVmOrTemplate, and so have the same methods as a generic virtual machine. In practice we rarely need to run a source method.
The Destination Object
Once the virtual machine has been created (i.e. after the Provision State of the VMProvision_VM state machine), we have an object that represents the newly created VM. This is the destination object.
The destination object is accessible as an association from the task object:
$evm.root['miq_provision'].destinationIf we wish to make any customisations to the virtual machine as part of the provisioning workflow - such as add a disk or NIC, change VLAN, and so on - we make the changes to the destination object.
The destination object is a subclass of MiqAeServiceVmOrTemplate so has the standard set of VM-related methods:
destination.add_to_service
destination.changed_vm_value?
destination.collect_running_processes
destination.create_snapshot
destination.custom_get
destination.custom_keys
destination.custom_set
destination.ems_custom_get
destination.ems_custom_keys
destination.ems_custom_set
destination.ems_ref_string
destination.error_retiring?
destination.event_log_threshold?
destination.event_threshold?
destination.finish_retirement
destination.group=
destination.migrate
destination.owner=
destination.performances_maintains_value_for_duration?
destination.reboot_guest
destination.reconfigured_hardware_value?
destination.refresh
destination.registered?
destination.remove_all_snapshots
destination.remove_from_disk
destination.remove_from_service
destination.remove_from_vmdb
destination.remove_snapshot
destination.retire_now
destination.retired?
destination.retirement_state=
destination.retirement_warn=
destination.retires_on=
destination.retiring?
destination.revert_to_snapshot
destination.scan
destination.shutdown_guest
destination.snapshot_operation
destination.standby_guest
destination.start
destination.start_retirement
destination.stop
destination.suspend
destination.sync_or_async_ems_operation
destination.unlink_storage
destination.unregisterIn the case of provisioning a virtual machine, the same destination object is also available via the vm association, i.e.
$evm.root['miq_provision'].vmWe often find that objects are accessible via multiple association names.
Summary
This chapter has discussed the four main service model objects that we work with when we interact with the virtual machine or instance provisioning workflow, and we’ve seen the methods that are available to call on each object.
The virtual machine provisioning workflow is the same for all VMs that we provision into the same provider category; Infrastructure or Cloud. Our provisioning state machine is used to provision virtual machines into all providers within that category (both VMware and RHEV for example), all provisioning methods (such as PXE boot or clone from 'fat' template), and regardless of operating system being provisioned. We must frequently make choices within our workflow based on some of these criteria, particularly the destination provider vendor and the operating system being provisioned. Using the various properties of the source and request objects, we can ascertain exactly the flavour of virtual machine being provisioned, the provisioning type being used, and the provider being targeted.
We also have several options to fine-tune the characteristics of the final virtual machine by calling methods on the destination object. We might want to explictly set the owning group, and perhaps set a custom attribute. We could call destination.group= and destination.custom_set toward the end of the provisioning workflow to achieve this.
1. This internal state machine performs the granular provider-specific steps to create the new virtual machine. It is implemented in the Rails
MiqProvision::StateMachine module and is not customisable from Automate.