vx rc banner

August 2012 Issue


TECH TIP

Managing PSQL v11 Server Licensing on Virtual Machines

One of the key reasons that VM adoption continues to grow is that it is very easy to configure and deploy new virtual machines and, with them, instances of applications. Companies can meet demand for new systems - either for internal use (testing, development, new hires) or for external use (new customers) - more quickly and cost efficiently than purchasing, configuring and delivering physical servers. And, it is easy to move VMs from one physical server to another to allow for hardware upgrades or to move VMs to a more powerful machine. The end result is that IT departments can create, move and distribute copies of software with very little effort, which can create a compliance risk for companies that do not have well defined processes and controls.

To help reduce that risk, licensing controls on PSQL v11 Server and Workgroup are stricter on VMs than for physical machines. With the exception of changing the amount of memory available to a VM, any changes to a VM configuration will put a PSQL v11 Server or Workgroup product key into a failed validation state. And, if the key is not repaired, failed validation can lead to the key being disabled.

How a Change to a VM Can Trigger a Failed Validation State

During the authorization process, Pervasive PSQL collects attributes about the VM. These attributes include machine name, host name, OS type, CPU name and type, MAC address and others. PSQL combines a specific set of these attributes and the details of each attribute to create a machine ID. That machine ID is stored locally on the VM and in the Pervasive licensing database (in the Cloud) along with the product key.

Each time Pervasive PSQL services are started, PSQL reviews the configuration, generates a machine ID and compares the just generated machine ID with what is stored locally. If nothing has changed, the machine ID's match and everything is fine. If there has been a change in the VM configuration, the machine ID's don't match and the key state changes from Active to Failed Validation.

What Happens When a Key Moves to Failed Validation State?

Pervasive PSQL will continue to operate if a key goes into a failed validation state. But...if the issue is not corrected, the key will eventually move to a disabled state and the database will stop working (will not accept any connections). When the key state changes, PSQL will begin to generate alert messages in the PSQL log, in the OS log, and in the Pervasive Notification Viewer on the desktop of the system where PSQL is installed. To learn more about the Notification Viewer, please visit the Pervasive website.

Some Tips to Help Keep PSQL v11 Licenses on VMs Valid 
  1. Always, always deauthorize the key before making any changes to a VM. Deauthorizing the key tells the Pervasive licensing server that the key is available for use on another machine. If there are changes to a VM from a move or from a reboot, the key can be reauthorized with no problems. Note: PSQL v11 Server and Workgroup keys have a limited number of authorizations - typically 10. To check the number of remaining authorizations, go to the PSQL license administrator, highlight the key and click the Remaining Authorizations button.
  2. Update to the most current service pack of PSQL v11. More current versions of PSQL v11 have features to tell customers what's happening with their license, provide alerts in the event of a license state change, and give plenty of time to repair the key before the license is disabled.
    • PSQL v11.0 - Key state moves from Active to Disabled without a Failed Validation state. PSQL v11.0 does not have license state warning notices (via Notification Viewer) and does not have a Failed Validation state.
    • PSQL v11 SP1 - Introduced Failed Validation state and intelligent 14-day period between Failed Validation and Disabled. "Intelligent" 14-day period means the product key takes at least 14 days to move from Failed Validation to Disabled and it won't be disabled on weekends or on holidays. PSQL v11 SP1 also introduced the Notification Viewer which delivers alerts and recommended action to handle key validation issues. Alerts are posted to the PSQL log, OS log and to the desktop of the system where PSQL is installed.
    • PSQL v11 SP2 - Introduced updated Monitor Utility to help customers estimate Pervasive PSQL Vx Server capacity requirements. PSQL Vx Server is a great fit for heavy users of virtual machines - we've adjusted the license enforcement mechanism to support operation on hypervisors (most notably moving live VMs from one physical machine to another without having any effect on PSQL licensing.)
  3. Configure the VM to reduce the likelihood of PSQL licenses becoming invalid. Check your VM vendor documentation for specifics:
    • Configure a static MAC address for VMs running PSQL. If the VM changes location, is cloned or copied, the MAC address typically will change - changing the machine ID and invalidating the product key.
    • Tie the VM to a specific CPU. This will make sure that when the VM is rebooted, migrated or moved it is not inadvertently tied to a different CPU (for example on a multi-processor server, where CPU properties are sometimes slightly different), causing the machine ID to change and invalidating the product key. Locking down a CPU in VM's depends on your VM vendor:
      • Microsoft's Hyper-V 3.0 will be the first version of Hyper-V to support locking the VM to a CPU.
      • Citrix XenServer (vcpu pinning) and VMware (CPU affinity) both support locking a VM to a specific processor.
    • Define which VMs can be moved automatically by the hypervisor. A machine ID change caused by a hypervisor initiated VM move is one of the most common reasons for PSQL v11 failed validation states. By requiring that VMs running PSQL be moved manually, it is less likely that an IT staff defined (and hypervisor implemented) load balancing rule will inadvertently move a PSQL instance and cause a failed validation state.
  4. Consider moving to Pervasive PSQL Vx Server. Pervasive PSQL Vx Server was designed with licensing features that simplify live migration of PSQL applications in a virtual environment. License validation for PSQL Vx Server product keys requires only VM hostname and all VM NIC MAC address remain the same in each VM. With Pervasive PSQL Vx Server, a PSQL application in a VM can move between physical servers automatically as part of a failover operation for example, or manually  as part of a hardware upgrade - all without affecting the state of the product key. For more details on PSQL Vx server licensing, please see the Pervasive website.