VMware to Microsoft Hyper-V Notes from the field

VMware to Microsoft Hyper-V Notes from the field

Best practices: from planning to migration

Windows Server 2008 R2 including Hyper-V has been available on the market for 1,5 years. A lot of greenfield implementations have been performed and also migrations from VMware in this period. Time to summarize and make conclusions. What are the critical success factors for a good functioning Hyper-V environment and a migration from VMware? What has been learned in practise and what are the best practices? This article answers these questions.

Nowadays the most organizations make use of virtualisation technology for servers. Desktop virtualisation is growing rapidly. For both solutions a hypervisor is needed. The Microsoft hypervisor is Hyper-V. For server as well for desktop virtualisation purposes.

VMware vs. Hyper-V planning

There are multiple hypervisors available on the market. Which hypervisor could you choose? What are the arguments? These question aren’t easily answered separately. Many organizations have made a choice in the past to use for example VMware ESX or vSphere as hypervisor for server virtualisation. When an organization wants to virtualize desktops and wants to unroll a Virtual Desktop Infrastructure (VDI) a lot of times the choice of hypervisor is reconsidered. Microsoft offers excellent possibilities to make Hyper-V the second hypervisor next to an already existing hypervisor such as VMware. Hyper-V could also be used as the only hypervisor for the whole ICT environment so that VMware could be replaced completely.

An argument that is used a lot not to use Hyper-V is that Hyper-V isn’t installed directly on the hardware but functions as application in Windows. This is a misunderstanding. Hyper-V is the first hypervisor of Microsoft that is directly installed on hardware. In terms of architecture Hyper-V isn’t an application inside Windows Server 2008 R2. Hyper-V is also available on Windows Core so that the footprint is smaller and that less patches needs to be installed. The maturity and feature-set of Hyper-V also gets mentioned often as argument to not use Hyper-V or do an implementation of Hyper-V. Hyper-V has proven in a relatively short period that it is a full hypervisor that offers enough functionality for the most environments. In the first half of 2011 Windows Server 2008 R2 SP1 is expected. The servicepack adds a couple of important features for Hyper-V, such as: Dynamic Memory and RemoteFX.

The choice for a hypervisor gets more important with VDI: depending on the VDI broker choice multiple hypervisors are supported. There are also some VDI broker products that have a lock-in with a specific hypervisor and don’t support other third party hypervisors.

Choosing a – other – hypervisor seems to be an operational technical choice. However, this choice cannot be seen as an isolated choice. Not only (maintenance) costs and the feature set of the hypervisor plays a role. An important part is the management and the available management tools for the hypervisor. With the arrival of cloud computing the virtual machines (VMs) should be taken into account that will be places in the cloud. Microsoft offers excellent system administration possibilities for Hyper-V and VMware. This is performed by additional System Center tools such as Virtual Machine Manager and Operations Manager. It’s also possible to migrate a VM from Hyper-V to a Microsoft cloud solution such as the Azure VM role. This is done by a virtual to virtual (V2V) migration. The VM that is hosted on the Microsoft Azure platform could be monitored by Operations Manager. With this a real hybrid management environment is created; monitoring in the public cloud and on-premise done by one interface.

Hyper-V infrastructure design

The architecture of Hyper-V has been developed in a way that there is no lock-in in terms of the usable hardware. Hyper-V is scalable and flexible. But this could be a pitfall. After all, a lot of options could have wrong choices or false configurations causing Hyper-V to possibly function less than for example VMware. A solid design is also necessary with Hyper-V to function well. A design of Hyper-V exists of more than just a design of the hypervisor. The total architecture has to be mapped and the hypervisor can’t been seen as the silo of the (server) infrastructure. For example, an important choice is will Hyper-V  be installed on blade or on rack servers. A rackserver has a lot of times many more expandability in terms of interconnections which could be crucial for the design of Hyper-V. Interconnections refer mostly to the number of network interfaces and the interfaces to the storage infrastructure.

A practical example is given for the number of network interfaces. The starting point is a two node Hyper-V cluster with disk majority, storage via iSCSI, Cluster Shared Volumes and Live Migration. For this the following networks are recommended:

  1. Management network: communication between servers for management purposes, such as: SCVMM, RDP and DCOM;
  2. Cluster interconnect network: failover cluster communication (cluster heartbeat);
  3. Live Migration network: content of the memory of the Virtual Server, delta copies and CPU and device status during Live Migration;
  4. Clustered Shared Volumes network: gets used for IO redirection of CSV traffic;
  5. Client Access network: connection from the client LAN to servers, such as CIFS, Exchange/Outlook, application data and web traffic;
  6. iSCSI network: iSCSI network traffic.

It is a best practice to separate networks logically from each other with the help of VLANs. The configuration mentioned above assumes an average load per physical servers. To get more bandwidth it could be necessary to make use of channels for the Client Access network and MPIO for the iSCSI network.

Next to the network interconnections the storage infrastructure also has a large influence on the configuration and achievements of Hyper-V. For example fiberchannel or iSCSI could be used. Specific tooling from the vendor for aligning of the disks should also be taken into account depending on the vendor of the storage. Disk alignment is also required for the disks inside the VMs for Windows 2000, 2003 and XP. Planning of the storage infrastructure is too comprehensive for the goal of this article. However, it is of importance that not only the net quantity storage gets calculated but also for example the number of I/O’s per seconds (IOPS). These are certainly crucial items in the case of VDI solutions that have to be sized. With migrations of VMware to Hyper-V you have to pay attention to VMware specific settings such as Disk IO Throttling. Hyper-V doesn’t have such a setting and this should be taken into account in the sizing of the storage and the placing of VMs on physical hosts.

It is of importance that Hyper-V gets installed in a Microsoft supported configuration. A so called ‘Designed for Windows’ server hardware should be used. This can be checked by choosing ‘validate a cluster configuration’ in Windows Server 2008 R2. When everything is validated and the configuration has been accepted there is support of the cluster configuration from Microsoft.

Validation

 

 

 

 

 

 

 

 

 

 

Management of VMware and Hyper-V

After the implementation of the Hyper-V role the Hyper-V Manager is available to manage the virtual environment. Hyper-V Manager is limited but has enough functionality for the initial configuration of Hyper-V and the VMs.

When a migration takes place from VMware to Hyper-V there are temporarily two hypervisors present in the infrastructure that has to get managed. With Microsoft System Center Virtual Machine Manager (SCVMM) it is possible to manage both hypervisors through one management interface (console). SCVMM is indispensable to have complete control over the virtual environment. SCVMM cloud be used for rollout of VMs by means of templates, managing of installation sources in a shared library and generating reports. In combination with System Center Operations Manager (SCOM) it’s possible to expand SCVMM with PRO-Tips for performance based Live Migrations. SCVMM however doesn’t make Hyper-V Manager completely unnecessary: the mounting of an ISO file or the optimising of the network configuration (VMQ) are easily realised with Hyper-V Manager than with SCVMM.

The product Hyper-V is costless. However, there are a few issues concerning licences.

There could be chose for Windows Server Enterprise Edition, Datacenter Edition and Hyper-V Server for the instalment of a Hyper-V cluster. To be able to host a VMware environment with the help of SCVMM VMware vCenter is needed to execute the most common tasks. Customers that didn’t purchase a vCenter licence can’t host their existing VMware environment with SCVMM. This is because SCVMM makes use of the vCenter API.

It’s recommended to purchase licenses for the System Center Server Management Suite Enterprise (SMSE) or for Datacenter (SMSD). This is as a bundle of all the Microsoft System Center products (such as SCOM, SCVMM, SCDPM, etc.) specifically bundled for managing and commanding of virtual environments.

Migrating VMware to Hyper-V

When the design of Hyper-V is made, eventual licenses have been purchased and the management tools have been chosen, then Hyper-V could be installed. It is a best practice to build a Proof-of-Concept inclusively load tests to validate the configuration of Hyper-V. When the Proof-of-Concept has been executed successfully then it is possible to migrate from VMware to Hyper-V. It’s necessary to have a migration plan with a rollback scenario included. The migration could be a big bang migration where all the VMs are migrated at the same time. In practise it seems that a phased migration is more applicable to migrated from VMware to Hyper-V.

The migration of a virtual server (VM) from VMware to Hyper-V is a so called virtual to virtual (V2V) migration and could be executed by SCVMM in both an online as an offline mode. It’s a recommendation to execute a test migration in a testing environment. Or test the V2V process during the Proof of Concept. A V2V migration doesn’t have an impact on the source server, this gets turned off by SCVMM after a successful migration. The roll-back scenario is quite easy: turn off the migrated server and turn the source server back on. Be careful with database servers and Exchange servers that do not use shared storage: not committed data could get lost because the data is only written on the target server!

Moreover the simplicity of a V2V migration with SCVMM isn’t a safeguard for making a (consistent) backup. During the migration most of the time is taken by uninstalling the integration tools of VMware including the needed restart of the VM. Also, it shows in practise that after a restart of the VM on vSphere the network configuration isn’t available anymore. A workaround is there to add the network drivers manually as these are necessary for a migration with SCVMM. Migrations performed by SCVMM have a small downtime. However, it deserves the recommendation to plan migration in predetermined service windows.

Another possibility to migrate VMs of VMware to Hyper-V is via the VMDK to VHD (VMDK2VHD) or disk to VHD (DISK2VHD) converter tools. These tools convert a virtual hard disk of the VMware format to the VHD format sector-based. Before the VMDK2VHD converter is started it is importang that the integration tools get uninstalled. If the VMs make use of a SCSI disk, which is recommended by VMware, and Windows XP, 2003 or earlier versions are installed then an IDE driver should be added manually. If this doesn’t get done then the VM will give a blue screen in Hyper-V with the notification: inaccessible Boot Device. This is because the converted VM doesn’t have primary IDE channel, which is exactly what Hyper-V expects. When all the data is inside a VM, it is possible that temporarily extra storage capacity is needed to execute the V2V migration. The current storage could possibly be expended or it’s needed to hire temporary storage. In practise it seems that it’s possible to use existing storage with big adjustments or extensions in a phased migration scenario.

You should test the VM after that it is migrated. When the migration has been a success the virtual discs of the source server (VMware) can be deleted. To make sure that the migrated server work as they should it is recommended to monitor this directly with the help of Operations Manager.

Practical limitations Hyper-V

As described before Hyper-V is scalable and flexible, but of course Hyper-V also has its limitations. In practise it has shown that configuring network interfaces of Windows Core is laborious. NTSH and PowerShell scripting are needed to correctly configure the networks. This could be time-consuming. The Remote Server Administration Tools (RSAT) are also necessary to configure Hyper-V.

Not all the guest operating systems are supported by Hyper-V. A couple of vendors have virtual appliances available, such as: firewall and anti-spam. In most of the cases they are based on Linux. There is most of the time support for VMware but not (yet) for Hyper-V. Not all suppliers of applications give support for Hyper-V. It is recommended to ask the application supplier about the support for Hyper-V at.

For troubleshooting it could be desirable to analyse network traffic by an isolated network port. Unfortunately it isn’t possible to put a virtual switch in promiscuous mode to be able to monitor all the traffic of a virtual server. There is also a number of security and intrusion packages that make use of port voltage to inspect network traffic. These can’t be virtualised on Hyper-V.

Conclusion

In practise it seems that Hyper-V is an excellent hypervisor for both server and desktop virtualisation. It’s possible to realise savings by migrating VMware to Hyper-V. These savings aren’t only in the costs for the hypervisor itself, but also the costs of maintenance and management tooling. By putting in more products from the Microsoft System Center stack it is possible to realise further savings and to create more dynamic infrastructure. The migrations of VMware to Hyper-V are relatively easy if the steps that are mentioned above are executed carefully.

Critical success factors: – Make a design of the whole infrastructure – Make sure there are enough interconnection on the physical servers – Sizing of the shared storage has to be executed beforehand (IOPS, etc.) – Pay enough attention to a solid network interface design – Build a PoC and carry out a representative load test – Provide the Hyper-V hosts of the latest hotfixes, patches, etc. – Make sure that there is enough scripting knowledge for Windows Core – Make sure there is a good back-up and recovery for rollback possibilities during a migration.

Best practices

  1. Next to SCVMM Hyper-V Manager can be useful for management tasks
  2. Automate common tasks with scripting (VBS, PowerShell, WMI)
  3. Keep the use-case and business-case in mind with the virtualizing of servers or desktops
  4. Ask a licence specialist for advice about the licence (bundles) that you are going to use
  5. Use, if preferred, SCVMM for V2V instead of tooling such as VMDK2VHD
  6. Inventory the migration before the configuration of the VM (IPConfig, disks, etc.)

Useful resources