Deploying virtual systems based on existing virtual  systems

To deploy a virtual system that is based on the characteristics of an existing virtual system, you create a BLPackage that is based on an existing virtual system, edit the BLPackage to describe the new virtual system, then deploy the BLPackage to the host server.

Note

Note that the newly created VM does not have an operating system installed on it. However, a VM deployed on a Citrix XenServer may have the operating system cloned from the source VM, depending on how you configure the BLPackage.

This approach is useful when you have an existing VM that represents the standard configuration for a specific use, such as the typical system for a developer, and you want to clone that system for future use. This system may be a high-end system with four CPU and 8 GB RAM, for example. You would create a BLPackage based on this system, and could deploy it whenever a new developer was hired.

To deploy a virtual system based on an existing system

  1. In the Servers folder, navigate to a host server or agentless managed object (for IBM, Citrix XenServer, or vCenter server) and expand the Live node.
  2. Do one of the following, based on the virtual environment:
    • Expand the VMware vCenter Server server object type and then expand the Virtual Machines node.
    • Expand the IBM Configuration server object type and then expand the LPARs node.
    • Expand the Global Zone server object type and then expand the non-global zones node.
    • Expand the RHEV Manager server object type and then expand the Virtual Machines node.
    • Expand the Citrix XenServer server object type and then browse to the host node on which the virtual machine is located.

    • Expand the Microsoft VMM server object type and then browse to the host node on which the virtual machine is located.

       

  3. Browse to an individual instance of the virtual system, for example VirtualMachineX.

    Note

    In the case of Citrix XenServer, you can clone only those VMs which are in the "Halted" state.

  4. Right-click the instance and select Add To Depot As > BLPackage.
    The Create BLPackage wizard opens. In addition to whatever other BLPackage options you choose, make sure to include the following selections:

    Panel

    Selection

    Package Type

    Create Package From: Live server objects

    Select Server Objects

    Click the name of the virtual system on which you are basing the BLPackage.

    For more information about filling out the wizard panels, see Adding-a-BLPackage-to-the-Depot.

  5. Edit the BLPackage to describe the new virtual system you want to create:
    1. In the Depot folder, navigate to the depot folder holding the BLPackage you just created.
    2. On the Objects tab of the contents pane, right-click the BLPackage you want to edit and select Open. A new tab with the name of the selected BLPackage appears.
    3. Edit the BLPackage to describe the new virtual system. For example, for VMware, you can specify other machine characteristics, such as Virtual Ethernet Adapter Type.
      See Considerations for creating a BLPackage based on an existing virtual system. 
  6. Deploy the BLPackage:
    1. Open the Depot folder and navigate to the BLPackage you just edited. Right-click the package and select Deploy from the pop-up menu. The New Deploy Job wizard opens.

    2. Fill out the wizard panels as described in Creating-a-Deploy-Job.
      In addition to whatever other Deploy Job options you choose, make sure you select a host server (vCenter server, IBM frame, Solaris global zone, Citrix XenServer, Microsoft VMM host) as the target on the Targets panel.

      Note

      The IBM frame and the Citrix XenServer are represented by an agentless managed object. A VMware vCenter server might also be represented by an agentless managed object. Note that the Single-User Mode deploy options (Single-user mode without reboot/shutdown and Reboot/shutdown into single-user mode) of an BLPackage are not supported for agentless managed objects.

      Targets must match the environment where you first created the BLPackage that defines the new virtual system. For example, if you started by basing a BLPackage on a virtual machine that resided on a vCenter server, then your target must be a vCenter server.

  7. When the Deploy Job run completes, return to the Servers folder, navigate to the host server and expand the Live node.
  8. Expand the top-level server object type (for example, the VMware vCenter server object type) and then expand the appropriate child node for your virtual environment. You should see the new virtual system you just added.

Deploy support for virtual assets

Deploying virtual assets using a BLpackage is supported only for the virtual assets in the list below. If you attempt to deploy any other node or asset (where the root node is not one of the assets listed below), the job fails, and the following message is written to the job log: PreCondition check failed.

  • VMware vSphere: Virtual machine and all its child nodes, ESX host memory, networking, advanced settings, DNS and routing, SCSI controllers, and security profiles. 
    Note: If you are modifying the SCSI controller type using a BLPackage, and are creating the BLPackage via Live Browse, you must create the package on the SCSI controller node, not on the hard disk node.
  • IBM PowerVM:
    • LPAR and all its child nodes
    • VIO and all its child nodes, except the adapter mappings and physical IO child nodes
  • Solaris Zones: Non-global zone and all its child nodes
  • HyperV: Virtual Machine asset (for Power Status), Virtual Machine CPU, and Virtual Machine Memory, disk, and NIC
  • Red Hat Enterprise Virtualization: RHEL virtual machine and all its child nodes, except the display node
  • Citrix XenServer: Virtual machine and all its child nodes

This list is for assets that are deployable using a BLpackage. Deploy for some other virtual assets are supported using a Virtual Guest Package and a Virtual Guest Job.

Considerations for creating a BLPackage based on an existing virtual system

Review the following considerations prior to creating a BLPackage based on an existing virtual system:

VMware vSphere

In addition to whatever other BLPackage options you choose, make sure to include the following selections:

  • Options > General: Set the value of each of the following options according to a new, unique name for the new Virtual Machine: Name, Configuration file, Snapshot directory, Log Directory, and Suspended directory
  • Resources > ResourcePool: If you do not want to put this new machine into any resource pool, set the (case sensitive) value to: Root Pool. If you want to put this new machine into a resource pool, for example RP2, set the (case sensitive) value to: Root Pool/RP2

  • Server Properties: You must specify the location of the new virtual system in the virtual infrastructure hierarchy. To do this, provide values for the following properties: ParentCluster (if applicable), ParentDatacenter, ParentHost.

    Make sure these values are correct — you may want to look them up (for example, using LiveBrowse of the server) before setting them here.

IBM PowerVM

Note the following considerations when creating a BLPackage based on an existing virtual machine:

If there are two or more adapters (physical or virtual) in the profile, you can delete an adapter from the list using a BLPackage Deploy Job. However, if there is only one adapter shown in the list, you cannot delete it. Note that the Single-User Mode deploy options (Single-user mode without reboot/shutdown and Reboot/shutdown into single-user mode) of an BLPackage are not supported for agentless managed objects.

To avoid unpredictable results or the creation of multiple disks when you use a BLPackage to create an IBM LPAR with a virtual disk attached, do the following: 

  • Remove all the SCSI adapters listed in the Hardware and Profile nodes of the BLPackage, or configure unique IDs for them
  • Provide unique values for the following attributes:
    • LPAR name
    • Profile name
    • Virtual disk name

Solaris Zones

In addition to whatever other BLPackage options you choose, make sure to set the Zone Path value to a new, unique name for the new non-global zone.

Red Hat Enterprise Virtualization

You can perform the following operations on a virtual guest using a BLPackage:

  • Modify CPU
  • Modify RAM
  • Add disk (to modify a disk, you must first delete the disk and then add the modification as a new disk)

  • Add NIC (to modify a NIC, you must first delete the NIC and then add the modification as a new NIC)

    Note

    Rollback of a deleted disk is not supported in a RHEV environment.

Citrix XenServer

Note the following considerations when creating a BLPackage that is based on an existing virtual machine:

  • There must be a valid virtual machine named in the VM Name attribute of the General node under the virtual machine.
  • You cannot clone a virtual machine from a virtual machine that is currently running. The source virtual machine must be shut down prior to creating the new virtual machine. Citrix XenServer does not support cloning from a running virtual machine.
  • You cannot rename a virtual machine by deploying a BLPackage. You must use the Rename right-click ad-hoc action.

Microsoft Hyper-V

You can perform the following operations on a virtual machine using a BLPackage:

  • Modify CPU
  • Modify RAM
  • Modify the power state (power state modification is supported only for VMs in the Running and Stopped states)
  • Add or delete disk

  • Add or delete NIC

    Note

    Modifying an existing NIC through a BLPackage is not supported. Therefore, do not edit the MAC Address field in the BLPackage.

Rolling back a deployment

If necessary, you can roll back a BLPackage Deploy Job, using the Undo option from the Job Results view.

To roll back a deployment:

  1. From the Jobs folder, navigate to the Deploy Job you used to deploy the BLPackage.
  2. Right-click the job and select Show Results.
  3. Expand the job. All runs of the job and their outcome display beneath the job.
  4. Right-click the job run you want to rollback and select Undo. 
    The deployment is rolled back.

Note

  • You cannot rollback or undo a Citrix Xenserver virtual machine or disk that you deleted using BLDeploy. While the Undo action for a deleted disk using BLDeploy might create a new disk, it does not recover the data from the disk that was deleted.
  • The rollback feature is not supported if you have renamed a virtual machine using a BLPackage (this applies to all virtualization platforms).
  • The rollback feature is not supported for Virtual Guest Jobs (all platforms).

Where to go from here

Monitoring-compliance-in-the-virtual-environment

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*