Important

   

This space contains documentation for TrueSight Server Automation 8.9.03 and the later service packs for 8.9. For earlier releases, see BMC Server Automation 8.9.

Working with VGP files that are based on a template or on an existing VM

Template-based VGP files are files that are based on either a template or on an existing virtual machine (VM).

Recommendations

  • Before creating a template-based Virtual Guest Package (VGP) file, carefully examine the specifications in the original template or existing VM.
  • Because of the complexity of working with template-based VGP files, it might be easier to use the BMC Server Automation Console to create new guests that are based on a template or existing VM. For more information on how to do this, see Deploying virtual systems using a Virtual Guest Package

A template or an existing VM has some fundamental defining characteristics that are impossible to modify when cloning a new VM. The BLCLI uses validations to ensure that your XML files do not attempt to modify these characteristics.

Working with template-based VGP files is different from working with bare metal VGP files because template-based VGP files work in conjunction with the specifications contained in the pre-existing template or VM.

  • GuestOSId and GuestOSVersionId — You cannot change these values in the VGP file. The OS and version of the new guest will be as specified in the template or existing VM. It is best to simply omit these elements from the template-based VGP file.
  • VMwareDiskSettings and VMwareNetworkSettings — The network and disk information you specify in the VGP file are added on top of whatever network and disk specifications already exist in the template or existing VM.

For example, suppose your template-based VGP file contains the following:

<VMwareDiskSettings>
  <DiskInfo>
     <DiskSize>1</DiskSize>
     <DiskSizeUnit>GB</DiskSizeUnit>
     <Datastore>storage2</Datastore>
   </DiskInfo>
</VMwareDiskSettings>
<VMwareNetworkSettings>
   <NetworkConnection>
      <Network>BMC VM Network</Network>
      <Adapter>VMXNET</Adapter>
   </NetworkConnection>
</VMwareNetworkSettings>

If this were a bare metal VGP file, the result would be a new guest with one disk and one network adapter. However, because this is a template-based VGP file, the disk and network adapter shown here would be added onto any other disks and network adapters that already exist in the template or VM.

For example, if the template already had two disks, this VGP file would result in a new guest that contains three disks.

If you want to create a new guest that has the same disk and/or network specifications as the existing template or VM, simply omit the VMwareDiskSettings and/or VmwareNetworkSettings sections from the VGP file.

Template-based VGP files - Rules summary (VMware)

A template-based VGP has certain attributes that you cannot modify when creating the package (via createVirtualGuestPackage) or modifying the package (via updateVirtualGuestPackage).

Observe the following rules when creating the <PlatformInfo> section for the VGP file you plan to use with either command:

  • You cannot modify GuestOsId and GuestOSVersion ID.
  • You cannot delete disks that came from the template (template disks).
  • You cannot modify the template disk size or sizeUnit.
  • You cannot delete template networks.
  • You cannot modify a template network's adapter.

Template-based VGP files - Datastore scenarios

Key concepts:

  • <VMXDatastore> (located OUTSIDE of <DiskInfo> sections) Specifies datastore that contains .vmx file (VMware configuration file).
  • <Datastore>  (located INSIDE <DiskInfo> section) Specifies datastore that contains .vmdk files (VMware VM disk files).

Task

Action

To clone all aspects of the template/VM. Same number of disks, same datastore.

<VMXDatastore> — Omit from the VGP file.
<DiskInfo> sections — Omit from the VGP file.

To clone the template or VM as far as the number of disks, but use a different datastore for both the .vmx file and the .vmdk files. You might need to do this if you are working with a target (Host/Cluster/ResourcePool) that is in a different location from where source template is located.

<VMXDatastore> — Specify new datastore. This applies to .vmx file and .vmdk files.
<DiskInfo> sections — Omit from the VGP file.

To add one more disk on top of the disk(s) in the template, but use the same datastore as the template.

<VMXDatastore> — Omit from the VGP file.
<DiskInfo> — Within this section, use <Datastore> to specify the same datastore that the template is using.

To add one more disk on top of the disk(s) in the template. For the additional disk, use different datastores than the template is using for its disk(s).

<VMXDatastore> — Set to the new datastore to be used for storing the .vmx file and .vmdk files cloned for the VM from the template.
<DiskInfo> — Within this section set <Datastore> to the new datastore for the .vmdk files that are associated with the new disk.
<VMXDatastore> and <Datastore> do not have to match; they can point to different datastores.

To update the VGP using the updateVirtualGuestPackage command. The target has changed and you need to specify a compatible datastore for the new location.

<VMXDatastore> — Specify a new datastore that will be used for the .vmx file and the .vmdk files that are associated with the disks that are specified in the template.
<DiskInfo> — If you specified any additional user-added disks in <DiskInfo> sections, you can change the <Datastore> elements to point to a new datastore as well. The <Datastore> elements do not have to match the <VMXDatastore> element or each other.

Was this page helpful? Yes No Submitting... Thank you

Comments