olly - Fotolia
Multi-hypervisor environments are a fact of life for many organizations that need to break the shackles of vendor lock-in, undesirable product feature roadmaps, restrictive licensing terms and other unwelcome changes in the vendor relationship. But managing multiple hypervisors can be a complicated and time-consuming challenge. Too many organizations reduce hypervisor management to silos, which do absolutely nothing to facilitate superior agility and resource allocation that will benefit the company. Centralizing the management of multiple hypervisors must be a key priority, but IT professionals must understand the concerns and tools needed for efficient hypervisor management.
What are the concerns when managing a heterogeneous hypervisor environment?
Perhaps the biggest issue with managing a multi-hypervisor environment is the suitability and compatibility of any management tool. For example, if you use Hyper-V and ESXi, the tool should offer comprehensive support for both hypervisors -- and provide ongoing support as each supported hypervisor changes.
But dig a little deeper to investigate the ways in which a prospective management tool handles heterogeneous hypervisors. Ensuring adequate performance and support is particularly important when selecting a management tool from a hypervisor vendor. As one example, VMware vCenter Server will support Hyper-V machines, but this requires the addition of vCenter Multi-Hypervisor Manager Server to form an interface between the non-VMware VMs and vCenter Server. This added "interface" software, if not properly designed and optimized, might adversely impact the performance of non-native VMs or limit their available features. Consider that vCenter Multi-Hypervisor Manager Server may not see the complete inventory of third-party VM hosts. Third-party VM management tools may not exhibit such behavior since all hypervisors are treated in a similar manner.
Evaluate the way that prospective multi-hypervisor management tools interact with each hypervisor's native management console. Ideally, the management tool should provide the same level of management capabilities and insights for all installed hypervisors without the need to rely on each hypervisor's native management console. When this occurs, the overarching management tool must often use each hypervisor's APIs for functions like service catalogs, orchestration and self-service provisioning. This can lead to uneven feature support, which still demands individual console management -- often imposing more management overhead than it removes.
Consider the impact of managing multiple hypervisors on IT staff. Remember that each hypervisor adds to the total amount of knowledge required from staffers, and the deployment of an overarching management tool adds even more conceptual load. Each additional product increases the potential for management errors and oversights. Some organizations respond to this by fostering silos of management expertise, but this should be avoided in favor of comprehensive cross-training opportunities that develop a broader base of expertise across more staff.
Finally, critical interrelationships between complex software products can lead to unforeseen consequences when changes occur, so consider the ways that a prospective management tool responds to patching or version changes. Any proof-of-principle project should include hypervisor patches (as well as management tool patches) to determine if features or capabilities are adversely affected. For example, if upgrading to a later version of ESXi causes the management tool to lose oversight of ESXi VMs (at least until the management tool is also updated), it might underscore sensitivity to changes that make the tool difficult to use.
Dig Deeper on Virtualization vendor comparisons
Related Q&A from Stephen J. Bigelow
ALM and SDLC both cover much of the same ground, such as development, testing and deployment. Where these lifecycle concepts differ is the scope of ... Continue Reading
Eliciting performance requirements from business end users necessitates a clearly defined scope and the right set of questions. Expert Mary Gorman ... Continue Reading
Requirements fall into three categories: business, user and software. See examples of each one, as well as what constitutes functional and ... Continue Reading