4.4 Configuring the hyperv Provisioning Adapter and Hyper-V VMs

This section includes the following information:

4.4.1 Configuring Policies for the hyperv Provisioning Adapter

Before provisioning and managing the hyperv provisioning adapter, you must configure certain policies in the Development Client. The following table provides detailed information about the policies associated with the hyperv provisioning adapter that are used to manage the hyperv server hosts and VMs in the grid. The policy settings are applied to all the VMs in the grid.

Table 4-5 Virtual Machine Management Policies for the Hyper-V Server

Policy Name

Explanation

Additional Details

hyperv

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

Do not edit the policy.

4.4.2 Known Configuration Limitations for Hyper-V VMs

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

  • If you are managing Windows VMs in a Hyper-V environment (clustered or non-clustered), the PlateSpin Orchestrate hyperv provisioning adapter fails to discover iSCSI target repositories in that environment if the VM is in a location other than C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks.

    To work around this issue:

    1. From the Explorer tree in the Development Client, select the Repositories group to expand the list of Repository Objects, select hyperv, then select the storage object associated to the Hyper-V cluster to open the admin view.

    2. In the Info/Groups page of the admin view, find the Preferred Storage Path field (the repository.preferredpath fact).

    3. In the Preferred Storage Path field, change the value to the path where the VM resides.

      Remember that this field considers the information in the Root Location field (that is repository.location).

      This is the location where PlateSpin Orchestrate searches for VM files for use in cloning and moving.Generally, it is a path like this: 

      C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks

    4. Click the Save icon to save the new configuration

    NOTE:If your Hyper-V environment is a Cluster Storage Volumes (CSV) environment, the VMs on the CSVs are automatically discovered by the hperv provisioning adapter as separate repositories. Executing the Discover VM Images action on these repositories discovers the VMs residing there.

  • If you create a VM in your Hyper-V environment, but the path to that VM was not configured as the default path in the Hyper-V Manager, the PlateSpin Orchestrate Server does not discover the VM.

    To work around this issue, you can edit the preferred path for the discovered repository where the VM resides, or you can create a new repository in the Development Client with the preferred path to the Hyper-V VM.

  • As with other VMs managed by Xen and VMware, the OS info for Hyper-V VMs is not always auto-discovered by PlateSpin Orchestrate.

    The OS info for Hyper-V VMs is discovered only in the following circumstances:

    • The Discover VM Images event triggers a Resync event for offline VMs to get OS info. However, OS info is not retrieved for the discovered templates.

    • The Resync event on the VM retrieves the OS family and type if it is offline.

    • The Resync event on the template sets the OS family to “Windows” because only Windows templates are supported in the hyperv provisioning adapter.

    • The Create Template event tries to retrieve OS info before creating the template. Create Template succeeds only if the VM’s OS family is Windows.

    To work around this issue, you can either enter this information manually, install the PlateSpin Orchestrate Client on the VM to enable discovery, or use the Key/Value Pair Exchange mechanism to support integration services installation.

  • After adding a vDisk to a Hyper-V Linux VM, that vDisk is not visible inside the VM. To work around this issue, you need to install Microsoft Linux Integration Components for Linux. See the Microsoft downloads site for more information.

  • As with other VMs provisioned by PlateSpin Orchestrate, sysprep does not work on Hyper-V Windows VMs until you set a value for the Admin Password fact (resource.provisioner.autoprep.sysprep.GuiUnattended.AdminPassword.value). For information about this fact, see Admin Password.

  • If you invoke the VNC console for a Hyper-V VM (referred to as a “workload”) from Novell Cloud Manager, the VNC console does not launch.

    Installing the PlateSpin Orchestrate Agent on the VM and executing the Apply Config action lets you launch a VNC session from Cloud Manager to the Hyper-V “workload” desktop.

    To install the client to the VM:

    1. From Explorer tree in the Development Client, select the VM that you want to observe in a remote session, then right-click and select Shutdown.

    2. Right-click the now idle VM, then select Install Agent.

    3. Right-click the VM, then select Start.

    4. When the VM appears online again in the list of resources, right-click the VM again and select Apply Config.

  • Discovery of highly available Hyper-V VMs in the Orchestrate Development Client is not supported if the Auto Start property for those VMs is disabled in the Hyper-V Failover Cluster Manager. Provisioning actions such as Shutdown and Move Disk Images might also fail for a highly-available Hyper-V VM if the Auto Start property is disabled on it.

    To work around this issue, enable the Auto Start property for these VMs in the Hyper-V Failover Cluster Manager.