Virtual Advisor

Heroes and Villains

• 04/01/2008

Server virtualization software, with the exception of OS virtualization (such as Solaris Containers and Parallels Virtuozzo) abstracts underlying physical hardware resources. So software licensing based on-or bound to-physical hardware may be difficult to manage in virtualized server environments. If you can't query the underlying physical hardware from within a virtual machine's (VM's) guest OS, how do you know if you're in compliance or not?

Further compounding the problem is VM mobility. Typically, this is observed with live migration such as VMware's VMotion. Live migration allows VMs to be relocated to other physical hosts while maintaining session state, and is often used to relocate VMs to facilitate scheduled hardware maintenance or load balance the workload of several VMs across multiple physical servers. Live migration is problematic for software licensing when licenses are bound to physical hardware instead of virtual hardware. For example, if a VM fails over or is live migrated from a two-way physical host to a four-way physical host, an application may no longer be in compliance with its software license (assuming the license is based on physical CPUs).

Current Software Licensing Approaches
Today, vendor licensing can be grouped into three general classes: Ideal; Defined, but not ideal; and Undefined. Vendors offering ideal licensing generally provide terms with the following elements:

• Organizations have the option to purchase bulk licenses based on physical hardware or individual licenses for each VM
• Individual system product licenses are not bound to any physical hardware element that would alter the license terms following a VM's relocation to a new physical server
• Organizations are not penalized for maintaining offline copies of a VM for backup and disaster recovery
• Organizations are not penalized for using virtualization technologies like VMware's VMotion or distributed resource scheduler (DRS)

Ideally, licenses should be bound to elements that are platform-agnostic, meaning that a given license could be applied to a physical or virtual system exactly the same way. Software licenses based on client connections or client seats are a good example of platform-agnostic licensing. Licensing based on client count is easily managed and tracked across any platform, physical or virtual. A number of vendors also offer instance-based licensing, allowing a license to be applied to a physical or virtual system the same way.

Granted, sometimes an instance-based license is determined by a server's CPU count. A similar metric could still be valid for VMs, assuming that the vendor allowed virtual CPUs to determine licensing requirements. Vendors will argue that it's possible to bind a virtual CPU to multiple physical CPUs, which is true. However, vendors could include restrictions in their end-user license agreements (EULAs) to not allow an application residing in a VM from using more physical CPUs than virtual CPUs.

A high number of enterprise application vendors have defined, but less-than-ideal licensing models for virtual environments. Such vendors' policies tend to restrict VM mobility by licensing exclusively to physical system hardware or prevent a license from following a VM as it moves from one physical server to another.

A vendor that only offers licensing based on physical CPUs is an example of a defined, but not ideal licensing model. Physical CPU-based licensing is very difficult to track in a virtual environment, as the physical CPUs would be abstracted by the virtualization hypervisor. Some vendors offer licensing that is first assigned to a physical server and then applied to a VM. This means that the license must be tracked across both physical and virtual boundaries.

Unfortunately, a high number of smaller software vendors exist today with no official public support policy or licensing terms for virtual environments. They fit into the "undefined" category.

Software Licensing Heroes
I think it's important to point out both the good (heroes) and bad (villains) of software licensing. There are vendors with ideal licensing for every product type: OS, client-server application, management application and middleware. Odds are that not every vendor in your environment has made a heroic effort to seamlessly support virtual environments. In those cases, it's good to be able to point an offending vendor to a competing vendor that's been able to make their licensing terms easy to manage in virtual environments. Vendors with ideal product licensing are listed in Table 1. As you can see, a number of vendors license products that are easily managed in both physical and virtual worlds. Citrix's XenApp Server, for example, is licensed per concurrent client connection. From a license-tracking perspective, it doesn't matter if XenApp Server is running on a VM or on a physical system.

Software Licensing Villains
Vendors that I'm categorizing as villains all have very good intentions when it comes to software licensing, but all offer flawed licensing models for at least some of their products. In the movies, many villains are likable characters, and the same can be said for most software vendors, but that doesn't change the flawed licensing models offered.

Microsoft is one of the most likable licensing villains because it supports more virtualization platforms than any other vendor. However, when you look at how Microsoft apps are licensed, you'll draw a different conclusion.

To visualize the licensing challenge, consider a physical three-node VM cluster. A business that requires a single SQL Server instance would prefer to purchase a license for the one VM instance. Current SQL Server 2005 licensing mandates that each license be bound to a physical server and applied to a single VM. Moving a VM running SQL Server Standard edition to a new physical host would require a transfer of license to the new physical host (assuming the organization hasn't purchased additional Standard edition licenses and assigned them to each physical host).

Current SQL Server 2005 licensing includes a 90-day restriction on license transfers, meaning that once a SQL 2005 Standard edition license is transferred to another physical host, it can't be transferred again for another 90 days. Ultimately, the easiest way to remain in compliance is by purchasing three SQL Server Standard edition licenses and assigning a license to each of the three physical nodes in the VM cluster. As you can see, running an app with a SQL back-end database in a VM could cause you to have to triple your software-licensing investment. Microsoft should allow Standard edition licenses to be bound directly to individual VMs with no relationship to underlying hardware. With such a model, it wouldn't matter if a VM was moved to a different physical host. The license would simply remain with the VM.

Rehabilitating the Villains
Of course, pointing out problems is the easy part-getting vendors to change their ways is another story. To compel vendors to change their ways, consider the following tactics:

• Use RFPs as leverage to require vendors to support your preferred server virtualization platform
• Consider software-licensing management complexity when making in all of your purchasing decisions
• Demand choices in licensing options
• Ask for vendor collaboration on open standards for software-licensing management in virtual environments

RFPs are a powerful tool. Vendors that see a lack of virtualization support as a deal-breaker to a potential sale will be much more motivated to support a particular server virtualization platform. License-compliance auditing complexity will now likely become a consideration when evaluating competing software solutions.

Willed to Change
Licensing for virtual environments is flawed, but far from broken. A number of vendors are doing it right, and the rest can be willed to change by an IT community not willing to accept the status quo. An IT budget is a powerful tool. Use it wisely to tame the villains of the virtual licensing universe.