Comparing vendor licensing and support policies is not much different than comparing chili recipes. On the surface, it’s chili. But the taste and smell can be far different. Many enterprises invest in software to track licensing compliance and vendor support policies because variations in the policies often differ substantially among vendors.
Most large enterprises have already had a taste of negotiating licensing and support policies for software deployed to virtual environments or to cloud platforms. For most, licensing concerns focused on deploying server applications to server virtualization infrastructures.
Problems that come from trying to understand licensing and product support vary in the server application space. They can be magnified when an organization considers deploying desktop applications to a virtual desktop infrastructure or evaluates moving applications to the cloud.
Licensing: Server, Client and Cloud
Clear differences exist in how applications are deployed and managed on servers, on clients and in the cloud. However, several common problems with many licensing models today apply to all distribution models. Some vendors still require software licensing to be bound to physical hardware. For example, Oracle’s CPU-based licensing model is based on physical CPU cores and not virtual CPUs.
Suppose you had two Oracle database virtual machines (VMs)—each with two virtual CPUs—running on a two-node ESX cluster that uses two four-socket four-core servers. Because it’s possible that you would have a VM on each node, you would need to purchase licensing to cover the 32 total cores.
If you deployed the Oracle VMs to Oracle’s hypervisor—Oracle Virtual Machine (OVM)—you could license by virtual CPU, but this is allowed only if you pin the VM to fixed CPU cores by hard-coding CPU bindings. This does create a slight advantage for OVM over competing products, but by binding a VM to one or more physical CPU cores, you have to give up advanced virtualization functionality such as live migration.
Oracle’s competitors in the database arena allow their products to be licensed by virtual CPU without requiring physical bindings. That is an important step because Microsoft and IBM customers are able to run their databases in VMs and move them to platforms with different hardware—different CPU or core counts—without having to worry about changes to software licensing requirements.
Other issues exist when it comes to licensing in the server space. Take Microsoft’s policy with regards to licensing its server operating systems. Licenses are assigned to physical hosts. Because standard edition licensing applies to a single server OS instance, it can then be applied to one VM. This means that organizations are responsible for tracking licensing compliance across both physical and virtual realms.
The reason that tracking is crucial is that the company’s policy for “Licensing Microsoft Windows Server 2008 to Run with Virtualization Technologies” states the following:
For Windows Server software, you can reassign server software licenses from one server to another but not more often than every 90 days.
There is an exception to this policy— no restrictions are placed on license transfer if the transfer is the result of a permanent hardware failure. The policy would not be an issue if not for technologies such as live migration that allow VMs to be moved from one physical host to another for operational tasks such as load balancing or scheduled hardware maintenance.
Many organizations license around the mobility restriction issue by purchasing Data Center Edition server OS licenses. For example, Windows Server 2008 Data Center Edition is licensed by the physical server CPU and allows an unlimited number of VMs to run on a licensed physical server. So administrators are free to move VMs between licensed physical servers without having to worry about license transfer restrictions.
That Data Center Edition licensing model works fine until you bring cloud computing into the picture. Suppose an organization wants to move a Windows server workload to the cloud. If a server OS license is bound to a physical piece of hardware, how can it be moved to the cloud and reside on a shared virtual infrastructure? The answer is that it can’t.
Microsoft allows organizations to bring their own licenses to the cloud as long as the provider gives the organization dedicated physical infrastructure. Many organizations that run workloads in the cloud require dedicated physical infrastructure anyway because of security and regulatory compliance concerns over sharing virtual infrastructure with other organizations.
So for some, requiring dedicated physical hardware is not a big deal. That’s not to say that you can’t move a Windows server workload to a shared virtual infrastructure in the cloud—assuming security and compliance concerns have been addressed—because you can. The only real issue is cost.
The cloud provider is responsible for purchasing and managing the server OS license and, as a result, has to build that into the cost of the hosting service. Microsoft is well aware of such concerns—I have personally discussed them with Microsoft’s licensing team—and is working on remedies that are fair for its customers yet also protect Microsoft’s revenue streams.
For example, allowing a license to reside in a VM without any mobility restrictions makes it easy for a particular VM to “follow the sun.” This issue is significant because it may mean that an organization can “ping-pong” a VM between two different corners of the world to save on software licensing costs. The current alternative may be to run separate instances of the application at each facility.
The problem with licensing, cloud and follow-the-sun scenarios isn’t a Microsoft issue, it’s an industry issue. This is why many of Microsoft’s partners and competitors also struggle with such issues. At the end of the day, most organizations require choice. Licensing model choices may consist of any of the following:
- Physical instance: Licenses are assigned for each physical system instance.
- Instance (physical or virtual): Licenses are assigned for each managed instance, either physical or virtual.
- Physical hardware (CPU, CPU socket or CPU core): Licenses are assigned based on the number of physical CPUs, sockets or cores on a system.
- Virtual hardware: Licenses are allocated based on the number of virtual CPUs (vCPUs) assigned to a VM.
- Hybrid (includes physical and virtual metrics): Licenses are tracked across multiple layers—assigned to a physical host and applied to a VM on that host.
- Usage-based: License cost is determined by the consumed resources over a period of time, such as those used by Amazon EC2 or Terremark vCloud Express.
- Client-based (seats, concurrent connections and so on): Licenses are based on the number of supported users, such as concurrently connected or total seats.
Instance-based licensing has long been popular with many management applications. Each managed object—for example, server or workstation—counts as a managed instance, with licensing editions often accounting for the number of managed instances, including a single instance, up to 500 instances or unlimited instances.
Physical-instance licensing remains popular with some applications. For example, organizations can license Symantec NetBackup 6.5 for Vmware environments by purchasing one enterprise client for each OS type backed up per ESX host. So if you’re backing up Windows on six ESX hosts, you would need six licenses, regardless of the total number of VMs being backed up.
Most application vendors are moving away from licensing based on physical hardware because such licensing is difficult to track in virtual environments, especially when VMs are deployed to clusters with physical hosts consisting of different CPU counts—for example, a mix of two-socket and four-socket servers. Furthermore, mobility to the cloud is further restricted. If the underlying physical infrastructure is abstracted, you or your license-tracking software may not know what physical hardware is present under the VM in which the application resides.
Applications licensed by virtual hardware don’t have similar problems because the application has clear visibility to the number of vCPUs presented to the application’s VM. Products that have no awareness of the quantity of users being serviced—such as a back-end database for a Web service handling anonymous Web traffic—are often licensed by CPU. Extending the licensing model to apply to vCPUs is a reasonable step to ensure virtualization compatibility.
Hybrid models that require a license to be tracked in both virtual and physical layers can be difficult to track when validating compliance. These models will likely dissipate eventually because they are completely incompatible with cloud based virtual infrastructures supporting multiple tenants. Binding a license installed in a VM to a physical asset prevents the follow-the-sun scenario described earlier. But it's impractical in environments where the underlying physical infrastructure is abstracted via technologies like virtualization.
As cloud-based infrastructure as a service (IaaS) platforms such as Amazon EC2 and Terremark vCloud Express grow in popularity, so will usage-based licensing models. Both Amazon and Terremark allow organizations to lease and run VMs on their platforms and pay for the minutes they use. Such models are economical for bursty workloads and short-term projects as well as development, test or training activities.
Paying less than five cents a minute to run a VM sounds like a great deal, but for 24/7 mission-critical applications, those models are typically cost-prohibitive compared to internally hosting such applications.
Client-based licensing models are becoming more popular for both server and client applications. Two emerging methods for tracking client application usage are to base licensing on the number of user seats or on the number of concurrent users.
Citrix has employed concurrent user licensing for a number of years and recently began offering a per-user licensing model with its XenDesktop 4.0 release. I am a strong proponent of peruser licensing.
Virtualization is changing the way client applications are licensed. Some licensing models are incompatible with virtualization, while others are incapable of addressing the needs of mobile users. Consider a client application whose licensing or registration binds to a physical hardware platform. If the application resides in a VM, and the VM is moved to new hardware, the user may have to re-activate the application or acquire an updated license before the application will run.
In some cases, licensing a user application per device makes sense. Take today’s physical home computer, for example. A family can install a copy of Microsoft Office, and all family members are able to use Office under the single-device license.
Now try applying that model to mobile users. Suppose a user accesses his or her virtual desktop from a thin client in the office, a personal computer at home and a laptop and smart phone while traveling. How many licenses are required in that model?
If the application is licensed per device, is the number four? For the OS alone, Microsoft’s Vista Enterprise Centralized Desktop licensing is licensed per device and includes a “home use” provision. So a single-device license could cover the user’s thin client and home PC. But what about access from a laptop or iPhone? Is another license required?
Unfortunately, the answer today is yes. The same issues surface with individual application licensing. This is why a peruser licensing option is needed, which would free users to access their data using whatever device they prefer without penalty. In time, the cloud will become the user’s desktop, with the thin client, laptop, PC, netbook or smart phone being the device that is used to access a user’s virtual system.
Finally one other area that remains relatively undefined is vendor treatment of virtualized applications—such as applications virtualized using App-V, ThinApp or XenApp. Suppose administrators want to pre-cache applications on a user’s device so that the application doesn’t have to download over the WAN or LAN the first time it’s used. In these cases, is the application considered an “installed instance,” even if the user has not run the application and the application does not appear to be present to the user.
Does the physical presence of the application bits constitute an installation? If you downloaded an application’s setup file to your hard drive but haven’t installed it, then it’s not considered an installed instance. You would think the same logic would apply for pre-cached virtualized applications, but vendors have not been clear on how their licenses apply. I asked Microsoft’s licensing team for clarification on this specific issue, and they offered the following statement:
Any machine that can or will access Office needs a license. Thus, a PC with a cached copy will need to carry an Office license. For Office, App-V and its cache is licensed to the device, and the instance of Office is in the cache.
Vendors typically support virtualization in one of three ways:
- Full support
- Best effort support
Full support is the most preferable. Vendors offering full support allow their applications to run on a virtualization platform without restriction. The vendor typically has either certified the virtualization platform in-house or has a support hand-off agreement in place with the virtualization platform’s vendor, including VMware, Citrix or Microsoft.
Vendors that do not offer full support may provide “best-effort” support instead. This means that the virtualization platform is supported, but if vendor support thinks a problem is related to the virtualization software, the vendor may require the problem to be reproduced on physical hardware.
Some vendors offer no support for virtualization and will require all problems to be reproduced on physical hardware before allowing support incidents to progress. Reproducing problems on physical hardware is a significant drain on IT resources and increases total cost of ownership. Organizations should strongly consider not purchasing any application that does not offer best effort support at a minimum on the organization’s virtual infrastructure.
How to proceed with licensing
As you can see, many unanswered questions remain when it comes to application licensing and support in virtualized environments. Don’t feel that you have to live with a broken system because everyone else does. In many cases, “everyone else” has negotiated a custom licensing or support agreement during the sales cycle.
In the push to streamline licensing and support for virtual environments, your greatest weapon is the request for proposal (RFP) document. When you put vendors through the RFP process, make support for your virtualization environment a requirement. Even if the vendor doesn’t publicly support your virtualization platform, it may make an exception to win the sale. On the flip side, if the vendor refuses to support your virtualization environment, you have these options:
- Reassess your choice of virtualization platform and decide if it is the right strategic platform for your organization.
- Purchase software that is fully supported on the organization’s virtual infrastructure.
- Absorb the risk of running the software in the virtual infrastructure, with the understanding that support incidents may come at the added cost— and downtime—of virtual-to-physical conversions
- Deploy the application to physical hardware, foregoing the benefits of running the application on virtual infrastructure.
As long as you’re running a virtualization platform that enjoys broad third party vendor support, there shouldn’t be a need to go in another direction. If a particular application vendor refuses to support your virtual infrastructure, then you have to assess whether that vendor should be part of your long-term IT strategy.
Also, don’t consider support to be a checkbox. When negotiating support agreements, make sure language is included in the agreement that protects your organization against unnecessary virtual-to-physical conversions. If a vendor offers best-effort support, the support agreement should clearly state the specific support incidents that require these types of conversions—for example, a performance issue suspected within the virtual I/O subsystem—along with all other incidents being fully supported.
When it comes to licensing, the use case is likely to drive the licensing model. Sometimes, licensing by physical host makes sense, such as when the organization prefers the flexibility to run an unlimited number of OSes in VMs on a licensed physical server.
But for most virtualization use cases and applications, there should not be any license requirements that bind an application to a physical system. Such restrictions impede both user and application mobility. For example, one should expect to be able to move an application to another physical server or cloud based infrastructure to facilitate maintenance or other IT projects.
In addition, users should be able to access their applications using the device of their choice. Giving users a choice often leads to increased productivity. Early desktop virtualization adopters that are Burton Group clients have seen productivity gains as high as 10% among users given remote access to their virtual desktops. Users are more inclined to do additional work at home and, as a result, are more productive.
About the Author
Chris Wolf, an analyst at Midvale, Utah-based Burton Group’s Data Center Strategies service, has more than 15 years of experience in the IT trenches and nine years of experience with enterprise virtualization technologies. Wolf provides enterprise clients with practical research and advice about server virtualization, data center consolidation, business continuity and data protection. He wrote Virtualization: From the Desktop to the Enterprise, the first book published on the topic, and has published dozens of articles on advanced virtualization topics, high availability and business continuity.