Download Principled Tech Report: VMware vSphere vs. Microsoft Hyper-V VM Migration Comparison and more Summaries Technology in PDF only on Docsity!
VIRTUAL MACHINE MIGRATION COMPARISON:
VMWARE VSPHERE VS. MICROSOFT HYPER-V
OCTOBER 2011
A PRINCIPLED TECHNOLOGIES TEST REPORT
Commissioned by VMware, Inc.
Businesses using a virtualized infrastructure have many reasons to move active virtual machines (VMs) from one physical server to another. Whether the migrations are for routine maintenance, balancing performance needs, work distribution (consolidating VMs onto fewer servers during non-peak hours to conserve resources), or another reason, the best virtual infrastructure platform executes the move as quickly as possible and with minimal impact to end users. We tested two competing features that move active VMs from one server to another, VMware vSphere 5 vMotion and Microsoft® Windows Server® 2008 R2 SP Hyper-V Live Migration. While both perform these moves with no VM downtime, in our testing the VMware solution did so faster, with greater application stability, and with less impact to application performance – clearly showing that not all live migration technologies are the same. VMware also holds an enormous advantage in concurrency: VMware vSphere 5 can move eight VMs at a time while a Microsoft Hyper-V cluster node can take part only as the source or destination in one live migration at a time. In our two test scenarios, the VMware vMotion solution was up to 5.4 times faster than the Microsoft Hyper-V Live Migration solution.
Virtual machine migration comparison: A Principled Technologies test report 2
WHY VM MIGRATION PERFORMANCE MATTERS
Being able to move active VMs as quickly and as seamlessly as possible from one physical server to another with no service interruption is a key element of any virtualized infrastructure. With VMware vSphere, maintenance windows are kept shorter and service level agreements (SLAs) are maintained or even improved because your virtual infrastructure platform is shifting your VM workloads faster and with more stability. Maintenance windows. Maintenance windows are critical slices of time where vital work is performed on the hardware that fuels your core business; the smaller the maintenance window, the better. These maintenance windows require time buffers on both ends for evacuating your hosts, then redistributing workloads afterwards. This is where VM migration performance is critical. The industry is trending towards denser virtualization; with Hyper-V Live Migration, these larger numbers of VMs take longer and longer to move to other servers. However, with the high performance of vMotion with VMware vSphere, you can keep maintenance windows to a minimum, moving VMs up to 5.4 times faster than with Hyper-V. SLAs. The indicator of your level of quality is the SLA with your customer, and your ability to keep this SLA is critical. Adaptive workload balancing, such as VMware vSphere Distributed Resource Scheduler (DRS), uses migration technologies to balance workloads across your hosts. This ever-changing, dynamic balancing act must happen as quickly and efficient as possible – vMotion with VMware vSphere is a key enabler of DRS. vSphere shows superior speed and quality of service over Hyper-V, as we demonstrate in this report. Low-impact migrations. Whatever the reason for moving your VMs, whether for maintenance or for SLA and quality of service, the end user should experience as little impact as possible from the migration. In our tests, application performance degradation during the migration window, as we show in this report, was significantly greater with Hyper-V than with vSphere.
VMWARE VMOTION ARCHITECTURE AND FEATURES
VMware vMotion transfers the entire execution state of the virtual machines being migrated. To do this, VMware breaks down the elements to be transferred into three categories: the virtual device state of the VM, the networking and SCSI device connections, and the physical memory of the VM. The virtual device state includes the state of the CPU and hardware adapters, such as network adapters and disk adapters. The contents of the virtual device state are typically quite small and can be transferred quickly. The networking and SCSI device connections of the VM can also be quickly transferred, given that the MAC address of the VM is independent of the hosts’ MAC addresses; the switch is simply informed by
Virtual machine migration comparison: A Principled Technologies test report 4
workload for testing real-world VM migration, as it exercises all elements of the solution, just as real-world applications do: CPU, memory, networking, and disk. In the host evacuation test, each of the three servers ran 10 two-vCPU VMs ( VMs total in the cluster), sized as follows: seven VMs were assigned 4 GB of RAM, two VMs were assigned 8 GB of RAM, and one VM was assigned 16 GB of RAM. Knowing that users and applications do not perform the same as benchmarking tools, we throttled back our workloads across our VM mix to reflect a more realistic scenario. By injecting “think time,” or artificial waits, into the benchmarking tool, we more closely simulated real users and real applications doing real work. We varied our think time mix across our VM mix (see Figure 1 on the next page) to provide for three profiles: an idle load, light load, and medium load. The idle profile loads were VMs with their database working set resident in RAM but otherwise idle. The light profile loads ran the workload with 500ms think time. The medium profile loads ran the workload with only 100ms think time, doing much more work than the medium profile loads by spending less time waiting between operations. We performed this test on both our Hyper-V environment and our vSphere environment. In the tier-one application test, we simulated a tier-one, heavily utilized, mission-critical workload. To do this, we ran one large four-vCPU VM on one server with 16 GB of RAM and a 16GB database. To show heavier usage in this scenario, we ran a heavier workload with more execution threads and no user think time, as we discuss further below. We performed this test on both our Hyper-V environment and our vSphere environment.
Host evacuation scenario All VMs ran Windows Server 2008 R2 SP1 and Microsoft SQL Server® 2008 R2. All 30 VMs contained copies of the DS2 database in varying sizes: the 4GB VMs contained a 4GB database, the 8GB VMs contained an 8GB database, and the 16GB VM contained a 16GB database. Using DS2, we warmed up each of the 30 VMs for a period of time to allow the VM’s memory pages to be utilized (see Appendix F for details on the warm-up period). Then we left 1 VM on each server idle and ran DS2 against the remaining 27 VMs (9 on each server) during the migration window, and varied the think time parameter to the DS2 workload. We created this mix to simulate a real-world system containing idle, light, and medium workloads running on VMs of different sizes. All workloads ran with 10 DS2 threads. We designated Server 1 as the server to evacuate and relied on vSphere DRS and Microsoft SCVMM to use their respective method of redistributing the VMs. Figure 1 provides details of the specifics of our varied workload mix.
Virtual machine migration comparison: A Principled Technologies test report 5
VM RAM
(GB)
DVD Store database size (GB)
Number of vCPUs Threads^
Workload mix (think time) during migration (ms) Server 1 VM 1 4 4 2 10 Idle VM 2 4 4 2 10 500 VM 3 4 4 2 10 500 VM 4 4 4 2 10 500 VM 5 4 4 2 10 100 VM 6 4 4 2 10 100 VM 7 4 4 2 10 100 VM 8 8 8 2 10 500 VM 9 8 8 2 10 100 VM 10 16 16 2 10 100 Server 2 VM 11 4 4 2 10 Idle VM 12 4 4 2 10 500 VM 13 4 4 2 10 500 VM 14 4 4 2 10 500 VM 15 4 4 2 10 100 VM 16 4 4 2 10 100 VM 17 4 4 2 10 100 VM 18 8 8 2 10 500 VM 19 8 8 2 10 100 VM 20 16 16 2 10 100 Server 3 VM 21 4 4 2 10 Idle VM 22 4 4 2 10 500 VM 23 4 4 2 10 500 VM 24 4 4 2 10 500 VM 25 4 4 2 10 100 VM 26 4 4 2 10 100 VM 27 4 4 2 10 100 VM 28 8 8 2 10 500 VM 29 8 8 2 10 100 VM 30 16 16 2 10 100 Figure 1. Details about the host evacuation test scenario.
During the main workload mix portion of DVD Store testing, we initiated a maintenance mode event on our source server; on both the VMware vSphere and Microsoft Hyper-V platforms, this induced an evacuation of all 10 VMs on the source
Virtual machine migration comparison: A Principled Technologies test report 7
Figure 3. Migration time for 10 VMs, in minutes, for the two platforms in the host evacuation scenario. Less time is better.
As Figure 4 shows, in the tier-one application scenario, migration using VMware vSphere vMotion was 3.4 times faster than Microsoft Hyper-V Live Migration.
Figure 4. Migration time for one VM, in minutes, for the two platforms in the tier-one application scenario. Less time is better.
In addition to the much faster migration time that VMware vSphere vMotion delivered, this platform also provided a much less disruptive and more productive
Virtual machine migration comparison: A Principled Technologies test report 8
experience to end users. Figure 5 shows application performance of a single VM in the tier-one application scenario over roughly 4 minutes; migration begins 1 minute into this period. With vSphere vMotion, performance dips for one very brief period, and then returns to its previous high level. With Hyper-V Live Migration, once migration begins, performance drops off briefly, climbs to roughly 80 percent of its pre-migration level, and then drops again for an extended period. It then returns to pre-migration levels. This extended period of application disruption could cause service disruption for some environments.
Figure 5. Application performance for the VMware vMotion and Microsoft Hyper-V, in orders per second, before, during, and after migration. Higher orders per second and less time are both better. Finally, as Figure 6 shows, in the tier-one application scenario, the greater speed at which VMware vSphere migrates VMs benefits users and their applications from a
Virtual machine migration comparison: A Principled Technologies test report 10
error and restarted, immediately causing the workload to fail. This failure was reproducible, in that it occurred on each of our three iterations for the Hyper-V host evacuation scenario. However, it was also unpredictable, in that the same VM did not fail every time.
Figure 7. Blue screen error from Microsoft Hyper-V VM during the host evacuation scenario.
CONCLUSION: VSPHERE IS MORE RELIABLE
The ability to move active VMs between physical servers greatly enhances your ability to meet the demands of your business, and can even conserve resources by shifting workloads to optimize power usage. Choosing a virtual infrastructure platform that executes these moves quickly and with minimal impact to application performance is critical. Our tests show that VMware vSphere 5 not only meets these requirements with its latest vMotion functionality, but delivers performance superior to that of Microsoft Hyper-V Live Migration, in terms of both time to migrate and end-user experience. This superior performance is due to the ability to migrate multiple VMs concurrently, a highly optimized migration design, and maturity of vMotion over many releases.
Virtual machine migration comparison: A Principled Technologies test report 11
APPENDIX A – TEST CONFIGURATION OVERVIEW
Figure 8 presents our test infrastructure. We used 21 load generator client virtual machines for the host evacuation scenario. Because of our differing workload mixes with different incoming parameters to the DVD Store workload, each client VM targeted either one or two target VMs. We first tested the VMs on VMware vSphere 5, and then on Microsoft Windows Server 2008 R2 SP1 (build 6.1.7601). We ran both environments, one by one, on the same hardware. Where necessary, we took advantage of the ability of DVD Store 2.1 to exercise multiple VMs with each instance targeting two databases. Each client VM was a two-vCPU VM running with 4 GB of RAM, running Windows Server 2003 R2 SP2 with the .NET framework 3.5 SP1 installed.
Figure 8. The test infrastructure we used for both the VMware vSphere 5 vMotion and Microsoft Hyper-V Live Migration testing.
Virtual machine migration comparison: A Principled Technologies test report 13
Setting up the external storage
- Using the command-line console, via serial cable, reset the first Dell EqualLogic PS5000XV by using the reset command.
- Supply a group name, group IP address, and IP address for eth0 on the first of three arrays.
- Reset the remaining two arrays in the same manner, supply the group name to join and IP address created in Step 2, and supply an IP address in the same subnet for eth0 on each remaining tray.
- After group creation, using a computer connected to the same subnet as the storage, use the Dell EqualLogic Web interface to do the following: a. Assign IP addresses on the remaining NICs (eth1 and eth2) on each array. Enable the NICs. b. Verify matching firmware levels on each array and MTU size of 9,000 on each NIC on each array. c. To create two storage pools, right-click Storage pools, select choose Create storage pool. Designate one storage pool for VM OS. Designate the other storage pool for VM SQL Server data, SQL Server transaction logs, and the utility virtual disk. d. Click each member (array), and choose Yes when prompted to configure the member. Choose RAID 10 for each array. e. Assign the two arrays containing 15K drives to the SQL Server data storage pool. Assign the one array containing 10K drives to the VM OS storage pool. f. Create eight 750GB volumes in the database storage pool—four for VMware vSphere 5 usage and four for Microsoft Hyper-V R2 SP1 usage. g. Create eight 460GB volumes in the OS storage pool—four for VMware vSphere 5 usage and four for Microsoft Hyper-V R2 SP1 usage. h. Enable shared access to the iSCSI target from multiple initiators on the volume. i. Create an access control record for the volume without specifying any limitations. j. During testing, offline the volumes not in use by the current hypervisor.
Virtual machine migration comparison: A Principled Technologies test report 14
APPENDIX C – SETTING UP THE MICROSOFT WINDOWS ENVIRONMENT
Adjusting BIOS settings
We used the latest released BIOS updates on each of the three Dell PowerEdge R710s, version 3.0.0, and adjusted the default BIOS settings. We enabled Virtualization Technology, disabled C-States, and set the performance profile to maximum performance on each server.
Setting up and configuring an Active Directory VM
Windows Failover Clustering requires an Active Directory® domain server. We configured a virtual machine to be used as an Active Directory server on a separate utility hypervisor.
Installing Windows Server 2008 R2 SP1 on the Active Directory VM
- Create a VM on a separate hypervisor host, choose two vCPUs, 4GB RAM, and 30GB virtual disk size.
- Install the operating system on the VM. a. Insert the installation DVD for Windows Server 2008 R2 SP1 into the DVD drive. Mount the DVD to the guest VM. b. Power on the VM, choose the language, time and currency, and keyboard input. Click Next. c. Click Install Now. d. Choose Windows Server Enterprise (Full Installation), and click Next. e. Accept the license terms, and click Next. f. Click Custom. g. Click the Disk, and click Drive options (advanced). h. Click NewApplyFormat, and click Next. i. Let the installation process continue. The server will reboot several times. j. After the installation completes, click OK to set the Administrator password. k. Enter the administrator password twice, and click OK. l. Install hypervisor integration tools on the VM, such as VMware tools if using ESXi as the utility hypervisor, or Hyper-V Integration services if using Hyper-V as the utility hypervisor. Restart as necessary. m. Run Windows Updates, and install all available updates.
Configuring TCP/IP and computer name on the Active Directory VM
- Connect to the AD VM.
- After the initial installation, you are presented with Initial Configuration Tasks. Click Configure networking.
- In Network Connections, right-click Local Area Connection, and click Properties.
- Click Internet Protocol Version 4 (TCP/IPv4), and click Properties.
- Select Use the following IP address and enter an appropriate IP address, subnet mask, and Preferred DNS.
- Close the Network Connections window.
- In Initial Configuration Tasks, click Provide computer name and domain.
- In System Properties, click Change. In Computer name, type the name of the domain controller machine, click OK twice, and click Close. When you are prompted to restart the computer, click Restart Now.
- After restarting, log in using the local administrator account.
- In Initial Configuration Tasks, click Do not show this window at logon, and click Close.
Configuring the Active Directory VM as a domain controller and DNS server
- Log into the AD VM.
- In the console tree of Server Manager, click Roles. In the details pane, click Add Roles, and click Next.
- On the Select Server Roles page, click Active Directory Domain Services, click Add Required Features, click Next twice, and click Install. When installation is complete, click Close.
Virtual machine migration comparison: A Principled Technologies test report 16
- After joining the domain and rebooting, log in using the domain administrator credentials.
- Repeat steps 1 through 17 on the remaining two servers.
Adding the Hyper-V R2 SP1 role
- Open Server Manager, and click Roles.
- Click Add Roles.
- On the Before You Begin page, check the Skip this page by default box, and click Next.
- Select Hyper-V, and click Next.
- On the Hyper-V Introduction page, click Next.
- On the Create Virtual Networks page, click Next.
- Confirm installation selections, and click Install.
- Once the installation is complete, click Close.
- When the system prompts a restart, click Yes.
- Allow the system to fully reboot, and log in using the administrator credentials.
- Once the desktop loads, the Hyper-V Installation Results window will finish the installation.
- Click Close. The Hyper-V role will now be available in Server Manager under Roles.
- Repeat steps 1 through 12 on the remaining two servers.
Installing the Failover Clustering feature
- Click Server Manager.
- At the Features Summary, click Add Features.
- In the Add Features Wizard, check Failover Clustering, and click Next.
- On the Confirm Installation Selections, click Install.
- On the Installation Results screen, click Close.
- Run Windows Updates, and install all available updates for Hyper-V and Failover Clustering.
- Repeat steps 1 through 6 on the remaining two servers.
Installing Dell EqualLogic Host Integration Tools for MPIO
- Log into Windows, and start the Dell EqualLogic Host Integration Tools installer.
- At the Welcome screen, click Next.
- At the License Agreement screen, click Next.
- At the Installation Type screen, select Typical (Requires reboot on Windows Server platforms), and click Next.
- In the Microsoft iSCSI Initiator service is not running window, click Yes to start the service and enable iSCSI traffic through the firewall.
- In the Microsoft iSCSI service window, click Yes.
- When the iSCSI Initiator Properties window pops up, accept the defaults, and click OK.
- If a Windows Firewall Detected window appears, click Yes to enable echo requests.
- At the Ready to install the components screen, click Install.
- In the Microsoft Multipath I/O feature is not detected window, click Yes to install the feature.
- When installing HIT on a failover cluster node, there will be an additional screen called the Cluster Access Information screen.
- Enter the appropriate credentials, specify a shared network path, and click Next.
- At the Installation Complete screen, click Finish.
- In the System Restart Required window, select Yes, I want to restart my computer now, and click OK.
- After reboot, open the Dell EqualLogic Host Integration Toolkit remote setup wizard, and click configure MPIO. Under Subnets included for MPIO, ensure only the iSCSI subnet is included in the “include” section.
- Repeat steps 1 through 15 on the remaining two servers.
Virtual machine migration comparison: A Principled Technologies test report 17
Connecting to the volumes with Microsoft iSCSI Initiator
- Using the Dell EqualLogic Web UI, ensure the Hyper-V-specific volumes are online and the VMware-specific volumes are offline.
- On the first server, click StartAdministrative ToolsiSCSI Initiator.
- Select the Discovery Tab, and click Discover Portal.
- Enter the IP address for the Dell EqualLogic Storage Group, and click OK.
- Select the Targets tab, and click Refresh.
- Select the first Inactive Target listed, and click Connect.
- Ensure that Add this connection to the list of Favorite Targets is selected, check the Enable multi-path check box, and click OK.
- Repeat until you have connected to all eight volumes, and click OK.
Configuring the external volumes in Windows Server 2008 R2 SP
- On the first server, click the Server Manager icon in the taskbar.
- In the left pane, expand Storage, and click Disk Management.
- Right-click the first external volume, and choose Initialize Disk.
- In the right pane, right-click the volume, and choose New Simple Volume.
- At the welcome window, click Next.
- At the Specify Volume Size window, leave the default selection, and click Next.
- At the Assign Drive Letter or Path window, choose a drive letter, and click Next.
- At the Format Partition window, choose NTFS and 64K allocation unit size, and click Next.
- At the Completing the New Simple Volume Wizard window, click Finish.
- Repeat steps 3 through 9 for the remaining external volumes.
Configuring the virtual network
- In Hyper-V Manager, right-click the server name in the list on the left side of Hyper-V, and choose Virtual Network Manager…
- Choose External, and click Add.
- Name the Virtual Network, and choose the appropriate NIC for your VM network from the drop-down menu. We used an onboard NIC on the domain subnet for VM traffic.
- Click OK.
- Repeat steps 1 through 4 on each server.
Running the Validate a Configuration Wizard
- On the first Hyper-V server, open the Server Manager utility.
- Expand Features, and select Failover Cluster Manager.
- Click Validate a Configuration…
- On the Before You Begin page, check the Do not show this page again box, and click Next.
- At the Select Servers page, type the name of each Hyper-V host server, and click Add. After adding both servers, click Next.
- On the Testing Options page, select Run all tests (recommended), and click Next.
- On the Confirmation page, click Next to begin running the validation tests.
- Once the validation tests complete successfully, click Finish.
Creating and configuring the cluster
- Ensure all three servers have been prepared with the steps above.
- On the first Hyper-V server, open the Server Manager utility.
- Expand Features, and select Failover Cluster Manager.
- Click Create a Cluster…
Virtual machine migration comparison: A Principled Technologies test report 19
- Create the following fixed size VHDs by choosing ActionNewVirtual Hard Drive: a. 20GB VHD stored on storage pool 1 for the VM OS (placed on the assigned OS/log volume) b. 10GB VHD stored on storage pool 2 for backup files (placed on the assigned SQL data/log/backup volume) c. 25GB (35GB for the 16GB database VMs) VHD stored on storage pool 2 for SQL Server data (placed on the assigned SQL data/log/backup volume) d. 15GB (20GB for the 16GB database VMs) VHD stored on storage pool 2 for SQL Server logs (placed on the assigned SQL data/log/backup volume)
- Right-click the VM, and choose Settings.
- Add the VM OS VHD to the IDE controller.
- Add the VM SQL VHD, the VM backup VHD, and the SQL log VHD to the SCSI controller.
- Click Processors, and adjust the number of virtual processors to 2.
- Start the VM.
- Attach the Windows Server 2008 R2 SP1 ISO image to the VM and install Windows Server 2008 R2 on your VM. See Appendix E for VM-related setup.
Configuring the cluster network for live migration
- Expand Services and applications.
- In the left pane, select a VM to configure.
- In the center pane, right-click the VM, and click Properties.
- Click the Network for live migration tab, and select the proper cluster network configured with subnet for live migration.
- Ensure that no other networks are selected, and click OK. This setting applies to all VMs in the cluster, and will not need to be configured for additional VMs.
- To ensure the functionality of live migration, select Services and Applications in the left pane.
- Power on a VM, and right-click it in the center pane.
- Select Live migrate this service or application to another node, and click another node in the cluster.
- The running VM will transfer to another node.
Setting up the System Center Virtual Machine Manager VM To manage our Hyper-V cluster, we used a VM running Windows Server 2008 R2 SP1 and Microsoft System Center Virtual Machine Manager 2008 (SCVMM). We installed this VM on a separate utility hypervisor host.
Installing Windows Server 2008 R2 SP
Follow the OS installation steps for the SCVMM VM provided in the section titled Installing Windows Server 2008 R2 SP1 on the Active Directory VM, and ensure that all Windows Updates are applied. Rename the system, assign a proper IP address, and join the domain.
Installing the prerequisites for SCVMM 2008
Install the following prerequisites using Server manager to add roles and features prior to installing SCVMM: Windows Remote Management (WinRM) 1.1 or 2.0; Windows Automated Installation Kit (WAIK) 1.1; and WEB ISS 7. with Metabase Compatibility, 6 WMI Compatibility, Static Content, Default Document, Directory Browsing, HTTP Errors, ASP .NET, .NET Extensibility, ISAPI Extensions, ISAPI Filters, and Request Filtering. See http://technet.microsoft.com/en- us/library/cc917964.aspx for more information.
Installing SCVMM 2008
- Log into the SCVMM VM.
- On the SCVMM screen, select VMM Configuration analyzer to verify you have all the prerequisites.
Virtual machine migration comparison: A Principled Technologies test report 20
- On the License Terms screen, select the accept radio, and click Next.
- On the Customer Experience Improvement Program screen, click I do not wish to participate.
- On the Product Registration screen, enter a username and company, and click Next.
- On the Install Location screen, click Next.
- On the SQL Server settings screen, click Next.
- On the Installation Settings screen, click Next.
- Once the installation has finished, click Close, and run Windows Update.
- After installing updates, run the SCVMM installation auto-start screen, and select the VMM Administration Console.
- On the License Terms screen, click I accept, and click Next.
- On the Prerequisites Check screen, click Next.
- On the Installation screen, click Next.
- On the Web Server Settings screen, click Next.
- On the Summary screen, click Install.
- Once finished, click Close, and run Windows Update.
Adding the Hyper-V failover cluster to the SCVMM administrator console
- On the SCVMM VM, open the VMM Administrator console.
- Click ActionsVirtual Machine ManagerAdd host.
- On the Select Host Location page, select Windows Server-based host on an Active Directory domain.
- Enter the domain administrator credentials, and click Next.
- On the Select Host Servers page, enter the name of the failover cluster in the Computer name field, and click Add.
- Click Next.
- Click Yes on the warning about the Hyper-V role.
- On the Configuration Settings page, accept all defaults, and click Next.
- On the Host Properties page, accept all defaults, and click Next.
- Ensure the added cluster settings are correct, and click Add hosts.
- Once the job completes in SCVMM, the cluster is listed under all hosts in the VMM Administrator console.
