Best Practices

To Avoid Trusted-Storage Breakage

If the publisher chooses to bind trusted storage to the VMID, this binding breaks should the UUID (from which the VMID is derived) ever change or is no longer available. The break prevents license leakage when virtual machine images are cloned. However, if you manage a virtualized environment where virtual machines are moved between different native (physical) systems, you do not want trusted storage to break each time you move a machine instance.

To prevent breakage, use these best practices:

•

Do not change the MAC address of the virtual machine.

•

Do not change the UUID of the virtual machine when it is moved. (Normally, UUIDs change only if the virtual machine is cloned.)

•

Save the configuration file (or at least the UUID) of each virtual machine on which trusted-storage license activation is performed. This file ensures that the UUID value used at the time of activation is available should you need to revert to this value.

•

Should trusted storage break, use the activation utility to issue a repair request; or reset the virtual machine’s UUID to the value it had at activation time (powering the machine off and then on after the reset).

To Avoid Issues with the Licensing Life-Cycle Operations

Although both composite and single-action transactions are supported for licensing life-cycle operations between the publisher’s activation server and the license server, best practice is always to use composite transactions. Issues can arise if you attempt to mix composite and single-action transactions, mainly because composite transactions support UMN3 and UMN5 while single-action transactions do not. For example, if a composite transaction is used initially to activate licenses on a virtual machine, the UMN3, if obtained, becomes the primary UMN for requester verification. If a single-action transaction is used later to return a license, the process fails because the return request contains no UMN3 to identify the requesting machine.