This section discusses some of VM job architecture best practices to help you understand and get started developing VM jobs:
An application is required for a service, and a VM is provisioned on its behalf. As part of the provisioning process, the VM’s OS typically must be prepared for specific work; for example, NAS mounts, configuration, and other tasks. The application might also need customizing, such as configuring file transfer profiles, client/server relationships, and other tasks.
Then, the application is started and its “identity” (IP address, instance name, and other identifying characteristics) might need to be transferred to other application instances in the service, or a load balancer).
If the Orchestrator Server loses the job/joblet communication state machine, such as when a server failover or job timeout occurs, all of the state information must be able to be recovered from “facts” that are associated with the server. This kind of job should also work in a disaster recovery mode, so it should be implemented in jobs regularly when relevant services from Data Center A must be started in Data Center B in a DR case. These jobs require special precautions.
A series of VMs must typically be provisioned in order to run systemwide maintenance tasks. Because there might not be enough resources to bring up every VM simultaneously, you might consider running discovery jobs to limit how many resources (RAM, cores, etc.) that can be used at any given time. Then, you should consider running a task that writes a consolidated audit trail.
Similar to how the job instagent searches for virtual machine grid objects using specified Constraints and runs a VM operation (installAgent) on the VMs that are returned, an Orchestrator image must be checked out of the warehouse and mounted, modified, and checked in again. Preferably, this should occur without having to provision the VM itself.
The management engine (“hypervisor”) underlying the the host server must be “managed” while a VM is running. For example, VM memory or CPU parameters must be adjusted on behalf of a monitoring job or a management console action.
In some instances, some managed resources might host VMs that do not contain an Orchestrator agent. Such VMs can only be controlled by administrators interacting directly with them.
Long-running VMs can be modified or migrated while the job managing the VM is not actively interacting with it. If you have one joblet running on the container and one inside the VM, that relationship might have to be re-established.