4.0 Troubleshooting Provisioning Actions

The following sections provide solution to the problems you might encounter while performing provisioning actions:

The vCenter provisioning adapter for vCenter 1.x does not work properly if the vcenter_client1x policy is not configured with the Java (JRE) 1.4.2 path

Source: The PlateSpin Orchestrate Development Client.
Explanation: The vCenter provisioning adapter for vCenter 1.x does not work properly if the vcenter_client2x policy is not configured with the correct path of Java (JRE) 1.4.2. Even though the job log does not report any error, the following message is logged into the server.log file: 
<date and time>: Broker,STATUS: assertion: workflowDone() isProcessingComplete==true jobid=zosSystem.vcenter1x.8
Action: In the vcenter_client1x policy, which has been automatically associated with the vcenter host, set the JAVA (JRE) 1.4.2 path for the vCenter PA job in the java1.4.2 fact tag: 
          <fact name="java1.4.2"               

                type="String" 

                value="location_of_the_JRE_1.4.2"

                description="Location of Java VM 1.4.2"/>

If JRE 1.5 is installed with the Orchestrate Agent, the default location of the JRE on Windows is c:\program files\novell\zos\agent\jre.

After installing the Orchestrate Agent on VM, the VM is not displayed as a resource in the Orchestrate Development Client

Source: The PlateSpin Orchestrate Development Client.
Action: Do the following:

  • Ensure that the Orchestrate Agent is running on the VM.

  • Ensure that no errors have been logged into the agent.log file.

    The log file is located in the Orchestrate_Agent_installation_directory\novell\zos\agent\node.default directory on Windows and in the /opt/novell/zos/agent/node.default directory on Linux.

  • Ensure that the Orchestrate Server is registered to the DNS server.

Unable to launch a remote session on the ESX host through the VNC port configured in the Orchestrate Development Client

Source: The PlateSpin Orchestrate Development Client.
Possible Cause: The VMs are powered on when you run the discovery job.
Action: Shut down the VM and start the VM.
Action: In the Orchestrate Development Client, ensure that the esxVncServerConfig job has run.

This enables the VNC Server service on the ESX host machine

The VM is suspended when you try to revert the snapshot of a powered-on VM running on a Hyper-V host

Source: The PlateSpin Orchestrate Development Client.
Explanation: If you try to revert the snapshot of a powered-on VM running on a Hyper-V host, the VM is suspended. This is a known behavior of VMs runnings on a Hyper-V host.
Action: Provision the suspended VM:

  1. In the Orchestrate Development Client, right-click the suspended VM, then click Provision.

    The Provision VM dialog box is displayed.

  2. In the Plan (Host/Repository) drop-down list, select the appropriate Hyper-V host.

  3. Click OK.

Moving or migrating VMs between two ESX hosts that are registered to a vCenter server by using the Orchestrate Development Client fails

Source: The PlateSpin Orchestrate Development Client.
Action: Do the following:

  1. Disconnect and remove one of the ESX hosts from the vCenter server.

  2. Move or migrate the VMs by using the Orchestrate Development Client.

Moving a VM from one ESX host local storage to another ESX host local storage might fail

Source: The PlateSpin Orchestrate Development Client.
Explanation: When you try to use the VM Client to move a VM of considerable size from one ESX host local storage to another ESX local storage, the move job might fail with the following error message: 
Job timeout, because Max elapsed time expired.
Action: In the policy associated with the VM, appropriately increase the timeout value. For more information, see Section 1.1, Configuring Policies for VM Provisioning Adapters.

Unable to perform any provisioning adapter action after the Save Config action on the vCenter VM

Source: The PlateSpin Orchestrate Development Client.
Explanation: An explanation of the message.
Possible Cause: The VM UUID value of the vCenter VM is not a 128-bit hexadecimal value. Even though the Save Config action is successful and the VM is provisioned, the hypervisor automatically assigns a different UUID value. Subsequently, any provisioning adapter action performed on the VM fails.
Action: Specify a 128-bit hexadecimal value for the VM UUID.

  1. In the Orchestrate Development Client, click Resources > the vcenter VM.

    The Info/Groups tab is displayed by default.

  2. In the Virtual Machine Configuration panel, set the value of VM UUID to a 128-bit hexadecimal value.

  3. Right-click the vCenter VM, then click Save Config.

Provisioning of a Xen VM doesn’t work on the host server

Source: The PlateSpin Orchestrate Development Client.
Explanation: When you try to provision a Xen 3.0 VM, the job might fail with the following error message in the job log: 
[c121] RuntimeError: vmprep: Autoprep of /var/lib/xen/images/min-tmpl-1-2/disk0
failed with return code 1: vmprep: autoprep:
/var/adm/mount/vmprep.3f96f60206a2439386d1d80436262d5e: Failed to mount vm
image "/var/lib/xen/images/min-tmpl-1-2/disk0": vmmount: No root device found
Job 'zosSystem.vmprep.76' terminated because of failure. Reason: Job failed

A VM host cannot provision a VM that has a different file system than the VM host. The currently supported file systems are ext2, ext3, reiserfs, jfs, xfs, vfat, and ntfs.

Action: To work around the issue load the VM’s file system Linux module on the VM host, or add this support to the Linux kernel if a custom kernel is being used.

Typically, last Linux kernels autoload the appropriate module to do the work.

You must manually load the proper kernel module on the VM host to support the VM’s file system.

For example, if the VM host uses ext3 and the VM image uses reiserfs, load the proper kernel module onto the VM host to support the VM image’s reiserfs file system. Then, on the VM host, run:

modprobe reiserfs

Next, provision the VM.

Cloning with prep is limited to what the Virtual Center of VMware Server supports.

Multiple instances of the same Xen VM running when located on shared storage

Source: Shared storage for Xen VMs.
Explanation: The xendConfig job runs when a VM host is added to the PlateSpin Orchestrate Server. This job automates some of the configurations possible on a Xen VM host. When using the default Xen configuration, it is possible to incorrectly start an already-running a VM a second time from storage that is shared by and accessible to another Xen VM host.
Possible Cause: A running Xen VM can only be locked to a specific Xen VM host when the xend service is configured to share a VM domain lock file on a shared file system. By default, the xend service will place these VM domain lock files in the /var/lib/xend/domains directory, which is usually not located on shared storage.
Action: You can configure Xen VM locks in PlateSpin Orchestrate by uncommenting certain facts in the policy file (search for xend.xend-domain-lock).

Uncomment these facts in xendConfig.policy:

To uncomment a section of code, remove the “<!--” (comment open) tag and the “-->” (comment close) tag. Edit the xend-domain-lock-path fact to set an alternate location on shared storage that is available to all VM hosts.

When you make the changes and save the file, the facts become active and the VM locking parameters of each newly-joining VM host are adjusted accordingly.

You can also schedule an immediate run of the xendConfig job to adjust all configuration files of the Xen VM hosts that are already connected to the PlateSpin Orchestrate Server.

NOTE:Setting the lock path using PlateSpin Orchestrate only supports the scenario where all VM hosts have the domain lock path connected to the same shared repository. For more complex setups, you need to use alternative methods to adjust the VM host lock configurations.