Wilco van Bragt - LinkeIn Wilco van Bragt - Twitter rssa 

The need for Advanced Features within Server Virtualization Part 2

 

Introduction

In this first part I started describing advanced feature available for hypervisor infrastructures. In this second part I will continue with the other available features and give my final conclusion.




vCenter Update Manager (vSphere) / XenServer Patch Management (XenServer)

 

Maintaining both the host as the VMs with the latest hotfixes and service packs can be accomplished using this feature both available for vSphere as XenServer. Update Manager offers a lot more of functionality then Citrix offers at this moment. Out of practical experience I see that most IT department are using another tool to patch the VMs, because such functionality is also needed for the workstations and other available physical machines. Then again it depends how many hypervisors hosts are available if it's necessary to patch the host via such a system or this is done with a procedure or scripts.

Usefully:            2
Necessity:         2

Data Recovery (vSphere) / VM Protection & Recovery (XenServer)

Although a VM cannot fail on hardware, a software failure is still possible. Also it can happen that an administrator by accident removes a VM out of the infrastructure. Both products have a feature available to create (smart) back-ups of VMs in such a way not many disk/tape space is required and a recovery can be performed pretty quickly.  Sounds great again, but again in real life I see that most customers don't use this option, but are using features available in their own back-up product of purchased a third party product especially for this task offering more functionalities.

Usefully:             2
Necessity:          2

Fault Tolerance (vSphere) / EverRun (XenServer)

With this feature/product (with XenServer it's not a Citrix product, but from Marathon where Citrix cooperates real close) it's possible to create a full fault tolerant VM. When the host fails where the VM is running a kind of standby VM is activated directly which is full mirror of the VM. So in comparison with High Availability there is no interruption of the availability of the functionally running on the VM. Again a cool technique but with several requirements, additional resource usage and it's not cheap to purchase. Normally this would be used with a few real important VMs and probably there are several companies which do not really need this feature from a cost benefit analysis.

Usefully:             4
Necessity:          2

Distributed Switch (vSphere) / Distributed virtual switching (XenServer)

With previous version of the hypervisor host you should create the virtual switches per host. This feature creates a switch which is available on all hosts within the hypervisor infrastructure. Again for large infrastructures this is an ideal feature especially because the switches can be from well-known switch suppliers like Cisco. So managing the switches can be leveraged by network administrators again. For smaller companies with a relative simple network setup, it's not that bad to create a virtual switch probably once during setup.

Usefully:             4
Necessity:          3

Thin Provisioning (vSphere) / Provisioning Services (XenServer)

Although these features are not fully comparable with each other (Thin Provisioning is using the same files for multiple VMs, where Provisioning Services is streaming a virtual operating system to a VM) the result is the same: saving disk space on the expensive storage. This technique can be used for both virtual servers as virtual workstations; however the real benefit is accomplished using VDI scenarios. So as long as there is no VDI requirement I don't expect that the feature is a requirement for those infrastructures.

Usefully:             3
Necessity:          3

Site Recovery (vSphere / XenServer)

VMware offers this as a separate product, while with Citrix XenServer it's a feature in the highest edition. The product/feature arranges that in case of a disaster recovery in the primary data centre the configured VMs will be transferred/started up in the backup data center. A real cool feature/product, but logically this is only applies to companies who have a second data centre and have a big hypervisor infrastructure with requirements that in case of a disaster the environment should be running within on-hour. In other case there are other cheaper scenarios available.

Usefully:            4
Necessity:          2

Memory Optimization (vSphere/XenServer/Hyper-V)

Optimizing memory (usage) on the hypervisor host is available in many options and names (like ballooning, swapping, compression s in VMware, Memory Optimization in XenServer and Dynamic Memory in Hyper-V). All techniques are arranging that het available memory in the host is used as dynamically and efficient as possible. Logically this can arrange that more VMs can be hosted on a host or that memory is used more efficient. Some products support over commitment (more memory can be assigned to VM than that's actual available in the hosts) , but you should be careful with that specific option.

Usefully:             3
Necessity:          3

Conclusion

Especially VMware and Citrix are offering a lot of features, which are available in one or more versions offered of the hypervisor product. Most features are from a technical view point great and really useful, but if you think from a business view or conceptual point most features are not solving real issues, but less or more solve things caused by improper design or wrong estimations. Personally I think that many companies have enough with the features arranging automatically start-up VMs when a host files (high availability/host clustering), the possibility to move machines manually to another host (vMotion/XenMotion/Live Migration) and central management (vCenter,XenCenter,Virtual Machine Manager). If the other features are necessary depends of other available product/roles in the whole infrastructure (for example back-up, VDI) and the complexity of the infrastructure (Site Recovery, Distributed Switching, Fault Tolerance).