9.5 Provisioning Virtual Machines

VM provisioning adapters run just like regular jobs on the Orchestrator. The system can detect a local store on each VM host and if a local disk might contain VM images. The provisioner puts in a request for a VM host. However, before a VM is brought to life, the system pre-reserves that VM for exclusive use.

That reservation prevents a VM from being stolen by any other job that’s waiting for a resource that might match this particular VM. The constraints specified to find a suitable host evaluates machine architectures, CPA, bit width, available virtual memory, or other administrator configured constraints, such as the number of virtual machine slots.

This process provides heterogeneous virtual machine management using the following virtual machine adapters:

For more information, see Virtual Machine Technologies and Actions in the Novell ZENworks Orchestrator 1.3 Virtual Machine Management Guide.

There are two types of VMs that can be provisioned:

The following graphic is a representation of the provisioning adapters and the way they function to communicate joblets to VMs of VMware Server, VMware Virtual Center, and Xen 3.0:

Figure 9-3 VM Management Provisioning Communications

VM Management Provisioning Communications Illustration

NOTE:The Xen VM Monitor can support more than just SUSE Linux Enterprise (SLE) 10 (which uses Xen 3.0.4) and Red Hat Enterprise Linux (RHEL) 5 (which uses Xen 3.0.3) VMs. For a complete list of supported guest operating systems, see the Xen Web site.

The following sections provide more information on provision of VMs:

9.5.1 Provisioning VMs Using Jobs

The following actions can be performed by jobs:

  • Provision (schedule or manually provision a set of VMs at a certain time of day).

  • Move

  • Clone (clone a VM, an online VM, or a template)

  • Migrate

  • Destroy

  • Restart

  • Check status

  • Create a template to instance

  • Create an instance to template

  • Affiliate with a host

  • Make it a stand-alone VM

  • Create checkpoints

  • Restore

  • Delete

  • Cancel Action.

You might want to provision a set of VMs at a certain time of day before the need arises. You also might create a job to shut down all VMs or a constrained group of VMs. You can perform these tasks programatically (using a job), manually (through the management console), or automatically on demand.

When performing tasks automatically, a job might make a request for an unavailable resource, which triggers a job to look for a suitable VM image and host. If located, the image is provisioned and the instance is initially reserved for calling a job to invoke the required logic to select, place, and use the newly provisioned resource.

For an example of this job, see sweeper.job.

VM operations are available on the ResourceInfo grid object, and VmHost operations are available on the VMHostInfo grid object. In addition, as shown in Section 9.5.3, Provisioning Example, three provisioner events are fired when a provision action has completed, failed, or cancelled.

The API is equivalent to the actions available within the Orchestrator management console. The selection and placement of the VM host is governed by policies, priorities, queues, and ranking, similar to the processes used selecting resources.

Provisioning adapters on the Orchestrator Server abstract the VM. These adapters are special provisioning jobs that perform operations for each integration with different VM technologies. The following figure shows the VM host management interface that is using the Orchestrator console.

Figure 9-4 VM Host Management

9.5.2 VM Placement Policy

To provision virtual machines, a suitable host must be found. The following shows an example of a VM placement policy:

<policy>
  <constraint type="vmhost">
    <and>
      <eq fact="vmhost.enabled" value="true"
          reason="VmHost is not enabled" />
      <eq fact="vmhost.online" value="true"
          reason="VmHost is not online" />
      <eq fact="vmhost.shuttingdown" value="false"
          reason="VmHost is shutting down" />
      <lt fact="vmhost.vm.count" factvalue="vmhost.maxvmslots"
          reason="VmHost has reached maximum vmslots" />
     <ge fact="vmhost.virtualmemory.available"
         factvalue="resource.vmimage.virtualmemory"
         reason="VmHost has insufficient virtual memory for guest VM" />
      <contains fact="vmhost.vm.availableids"
                factvalue="resource.id"
                reason="VmImage is not available on this VmHost" />
    </and>
  </constraint>
</policy>

9.5.3 Provisioning Example

This job example provisions a virtual machine and monitors whether provisioning completed successfully. The VM name is “webserver” and the job requires a VM to be discovered before it is run. After the provision has started, one of the three provisioner events is called.

1  class provision(Job):
2
3      def job_started_event(self):
4          vm = getMatrix().getGridObject(TYPE_RESOURCE,"webserver")
5          vm.provision()
6          self.setFact("job.autoterminate",False)
7
8      def provisioner_completed_event(self,params):
9          print "provision completed successfully"
10         self.setFact("job.autoterminate",True)
11
12     def provisioner_failed_event(self,params):
13         print "provision failed"
14         self.setFact("job.autoterminate",True)
15
16     def provisioner_cancelled_event(self,params):
17         print "provision cancelled"
18         self.setFact("job.autoterminate",True)

See additional provisioning examples in Section 9.4, Manual Management of a VM Server’s Lifecycle and Section 9.6, Automatically Provisioning a VM Server.