The checkpoint and restore features on the xen provisioning adapter only suspend and resume the specified VM. Xen does not support taking normal snapshots as other hypervisors do.

The Cloud Manager Orchestration Server configures the “netfront” paravirtualized driver in paravirtualized and fully virtualized guest VMs.

Previous releases of the Orchestration Server allows for 16 disks on both paravirtualized and fully virtualized VMs. However, if the paravirtualized drivers have not been installed within a fully virtualized VM, you can configure only 4 disks. In this scenario, if the number of disks exceeds 4, Xen fails to start 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 Orchestration Console to move any VMs you happen to create manually. The client takes care of properly deleting and re-creating the configuration for the VM.

When the xendConfig job is used during the discovery of a very large number of Xen VM hosts (that is, Xen resources where you have installed the Orchestration Agent), the completion of the xendConfig job can take an unnecessary amount of time to complete. This happens because, by default, an instance of the xendConfig job is started for every VM host discovered, possibly resulting in a very large number of queued xendConfig jobs.

By default, the xendConfig job is constrained to allow only one instance of the job to run at a time, causing all the other xendConfig job instances to queue.

The following constraint from the xendConfg.policy file causes all the xendConfig job instances to run one at a time, rather than concurrently.

 <constraint type="start" >
    <lt fact="job.instances.active"
            value="1"
            reason="Only 1 instance of this job can run at a time" />
  </constraint>

If you need to work around this issue to accommodate a large Xen environment, you can temporarily remove or comment out this constraint from the xendConfig policy, but you must ensure that no other the Orchestration Server administrator runs this job at the same time. Doing so might result in corruption of the /etc/xen/xend-config.sxp file because two xendConfig job instances could attempt to concurrently modify this config file.