4.2 Configuring the Xen Provisioning Adapter and Xen VMs

This section includes the following information:

4.2.1 Configuring Policies for Xen

The following table provides detailed information about the policies associated with the xen provisioning adapter that are used to manage the Xen hosts and VMs in the grid. The policy settings are applied to all the VMs in the grid.

Table 4-4 Virtual Machine Management Policies for Xen 3.0 Server

Policy Name

Explanation

Additional Details

xen

Contains the policy settings for the xen provisioning adapter.

By default, the optimal values are configured for the job and joblets in the policy.

xenDiscovery

Contains the settings required to discover the Xen host machines. It also contains the default installation path of the Xen server.

If the Xen server is not installed in the default path, edit this policy to provide the correct information.

xenPA

Contains the constraints used to check whether the Xen host is registered to the Orchestrate Server, and the host is up and running.

Do not edit the policy.

4.2.2 Known Configuration Limitations for Xen VMs

The following list describes the known limitations you can encounter when configuring Xen VMs in PlateSpin Orchestrate:

  • PlateSpin Orchestrate modifies a paravirtualized or hardware virtualized Xen VM with the appropriate driver to match its network adapters. The “ioemu” driver is meant only for a fully virtualized guest, while the “netfront” driver is a paravirtualized driver that can be used either with a paravirtualized guest or with a hardware virtualized guest that has the proper paravirtualized drivers installed.

    If you find that the VM is not obtaining proper connectivity or if you encounter some other networking error, check the vnic.type custom fact for the vNIC that is associated with the VM. Make sure the value for this fact matches the type of network adapter required by the VM.

  • If you use virt-manager to create a VM in the default repository and then copy its config file from /etc/xen/vm/<VM_name> to a new location on a different repository, both of these config files point to the same physical disk image. If you do not remember to use the xm delete command on the original VM, the Discovery action on both the original repository and the new repository results in the same VM being discovered in both repositories. This can cause the provisioning adapter to become confused as to which repository holds the VM image you want to use. To avoid this issue, we recommend that you use the Orchestrate Development Client to move any VMs you happen to create manually. The client takes care of properly deleting and re-creating the configuration for the VM.