Kirill Kedrinski - Fotolia
Open source hypervisor technical support, update considerations
Even though open source software itself is completely free to obtain and use, effective hypervisor technical support options for production environments might cost money.
Enterprise adoption of an open source hypervisor is typically tempered by three important practical considerations: product maturity, stability and technical support. If a business adopts a mission-critical platform, such as server virtualization, the hypervisor must offer a competitive, reliable feature set and available help as needed.
Unfortunately, these aspects can sometimes be weak when a complex software platform such as a hypervisor is community-developed and supported. The diverse developer community that freely shares code and expertise usually does so to meet their own unique perspectives, needs and skill levels. Thus, a feature or compatibility found in a major commercial hypervisor might not be present or at the same functional level in its open source equivalent.
As an example, some IT administrators that use open source hypervisors might seek better technical support and integration for third-party backup, snapshot and restore tools, the way that VMware vSphere and Microsoft Hyper-V support tools such as Veeam Backup & Replication.
It's one thing to obtain an open source hypervisor, but getting it to work can be another exercise entirely. In many cases, open source products might only be available as source code downloaded from a repository such as GitHub. This leaves admins to organize dependencies, such as related libraries, and then compile the build before they can deploy it. This demands a level of software development expertise on the part of the enterprise adopting the open source product.
It might be far faster and easier to seek prebuilt versions of the open source hypervisor, though this prevents further modification or adaptation of the open source product. If admins plan to modify the codebase, they should obtain the source code.
Technical support for open source hypervisors
Finally, there is the issue of technical support. Potential adopters might have questions or need help when compiling a build, understanding basic system requirements, deploying the hypervisor and performing basic troubleshooting.
It's easy enough to post questions on open source community forums, but there is no guarantee that a useful answer will appear promptly from the community. This makes open source products such as hypervisors problematic in production environments.
An enterprise might opt for paid support options before adopting an open source hypervisor for production. Paid support can offer access to detailed documentation; access to reliable, bug-fixed and high-performing builds; access to patches and updates; and a level of live telephone support.
Red Hat is one example of a company that foregoes upfront licensing in favor of a two-tier -- standard and premium -- annual subscription fee for product access, updates, patches and technical support. By contrast, Citrix uses a more conventional two-tier -- standard and enterprise -- licensing model that includes 24/7 technical support.
The actual cost of each support offering varies depending on the scope of the deployment, such as the number of populated processor sockets running the hypervisor, as well as the level of support required. Therefore, it's important to contact the hypervisor provider for a detailed quote.
Ultimately, an open source hypervisor might lack a meaningful development roadmap. Features, compatibilities and optimizations might take years to arrive, if ever, depending on the skills and objectives of the developer community. And effective technical support options might cost money, even though the open source software itself is completely free to obtain and use. This means it's extremely important for potential adopters to perform extensive due diligence testing before adopting an open source hypervisor.
