Contents

About the Author Acknowledgments Introduction Chapter 1: Welcome to the Virtualization World Chapter 2: Intro Into Hyper-V Chapter 3: Hyper-V 3.0

About the Author:

I am Mohamed Waly, Egyptian Microsoft Student Partner since September 2012, Member @ IT Academy Strike Team for the World Wide MSP Program, Rank 1 in Egypt Ranking @ Microsoft Virtual Academy, Blogs Writer (Write about Cloud Computing and Microsoft Servers).

Acknowledgments:
The author acknowledge : Andrew Page of Microsoft Hands-on Guide: Understanding Hyper-V Mastering Microsoft Virtualization

Introduction
In the last few years, the word virtualization has been a topic of discussion in most, if not all, IT organizations. Not only has it promised to save organizations money, but it has consistently delivered on that promise. The first area that this has generally been applied to is the server space. Organizations often take three, four, or more physical servers, create virtual machines running what previously ran on a physical server, and run those workloads on a single physical server hosting multiple virtual machines. Reducing the number of physical servers saves the cost of purchasing, maintaining, powering, and in some cases licensing those physical servers. Server virtualization is one of those technologies that has had a major, some might even say revolutionary, effect on how IT does its job. But too often, virtualization has been interpreted to only mean running more than one operating system environment on a single physical host. That definition is a little too limiting, particularly when seen in light of all the virtualization technologies that are available from Microsoft. Microsoft takes the approach that different requirements are best served by different technologies. For example, if we look at the simple understanding above, Microsoft does have a capability (Hyper-V) designed to efficiently run more than one operating system environment on a single physical host. With Hyper-V, we can look at virtualization as a way to abstract the physical resources of the host system in such a way that multiple software partitions can be created, and each partition can simultaneously run its own operating system environment. Hyper-V creates and removes these partitions via software, so they are very dynamic and can adjust to changing needs. This is different from hardware partitioning, where a physical machine is partitioned into two or more physical machines from a common set of hardware resources, creating fairly static operating system environments.

Chapter 1: Welcome to the Virtualization World

Just about every business today is either evaluating or implementing server virtualization, or partitioning a physical computer into multiple virtual computers. With hardware systems becoming so powerful, many applications do not require all the available horsepower that comes on a commodity server today. As a result, many companies are viewing server virtualization as a way to either save money by consolidating several underutilized systems onto larger, more efficiently utilized servers or create a dynamic data center that allows movement of virtual machines from one host to another as the needs dictate. Consolidation will enable companies to save money on physical hardware purchases, possibly some licensing costs, and definitely power and cooling. From a development and test environment, it also speeds up the ability to set up test environments and restore to earlier points to rerun tests. These scenarios promise cost savings of various amounts. Other companies are looking at how virtualization will make it easier and faster to change their infrastructure as their business environment changes.

Evolution Of Virtualization
In the 1970s, mainframes ruled the datacenter. Partitioning ensured both optimum use and efficient sharing of resources. This was a great way to get the most for the many, many dollars organizations spent to acquire, implement, and manage these behemoths. All processing was performed on a single computer with data retrieved from and stored to storage located in the datacenter. Access to the datacenter was tightly controlled. In many cases, users received reports from the computer operators through a window or slot. They accessed electronic information with dumb terminals with no local processing capabilities. The terminals were simple devices which collected keystrokes and presented data in green screen text. Distributed processing began in the 1980s, with personal computers finding their way to the desktop. These were fat clients which participated in client/server configurations and connected to the mainframes smaller cousin, the minicomputer. Although many companies still performed the bulk of their business processing in a centralized environment, both applications and data began to drift out to endpoint devices.

During the 1990s, another shift in business processing architecture took place with the advent of layered system technology. This included building applications with presentation and data access logic layers. Data resided in database servers in the datacenter. Still, fat client endpoint devices continued to run applications, and more data than ever before found its way to local hard drives. This was also a time when malware writers began perfecting their art. Attacks that eventually spread across entire enterprises often started on an unprotected or weakly protected personal computer. In the twenty first century, IT managers began to realize that traditional methods of managing desktop and laptop systems were no longer effective in dealing with changes in business requirements, user demands regarding technology implementations, and black hat hackers transitioning from fun and games to an organized crime business model. Demands for the rapid turnaround of application installation or upgrade requests, the need to quickly apply security patches to operating systems and applications, and many other management headaches are driving a new approach to endpoint and server processing and management virtualization. Figure 1.1 shows a timeline for the development of virtualization technology.

1970s Mainframes

1980s

1990s

Today Virtualization

Minis and Client Increased Server Distribution FIGURE 1.1 Evolution of virtualization timeline.

Virtualization Architectures
There are three primary forms of system virtualization. Figure 1.2 illustrates these three architectures.

Figure 1.2 Virtualization architectures

The Type 2 architecture is implemented with things like Java Virtual Machines or Microsoft Common Language Runtime environment. It provides a runtime environment in which commands or processes can be run, regardless of the underlying operating system. There is a dependency on the virtual machine manager to understand the underlying operating system, but the language used to create the process has no dependencies on the operating system. Type 2 focuses on process virtualization, not server virtualization. Therefore, we will not spend any more time discussing this form of virtualization. Hybrid and Type 1 architectures deal with hardware virtualization. In the hybrid (also sometimes called full or hosted) environment, the virtual machine manager runs alongside the operating system. It is installed as an application on the operating system and emulates an entire physical environment. This enables virtualizing the whole operating system environment in the virtual machine. Microsofts Virtual PC and Virtual Server and VMwares Workstation and Server products are examples of hybrid architectures.

The Type 1 architecture is what we are considering with Hyper-V. In this case, the hypervisor runs directly on the hardware without the need for an intervening operating system. This is the most efficient way to virtualize an environment because it has the least amount of interference between the hardware and the guest machines.

Virtualization Definition
As with all emerging technologies, there are several definitions or perceptions of what constitutes virtualization. To remove ambiguity, it is important to understand what virtualization means within the context of this book. Let us start with the definition provided by Amit Singh, author of kernelthread.com, in An Introduction to Virtualization: Virtualization is a framework or methodology of dividing the resources of a computer into multiple execution environments, by applying one or more concepts or technologies such as

hardware and software partitioning, time sharing, partial or complete machine simulation, emulation, quality of service, and many others. This is an accurate definition, but it fails to consider business drivers. It should be more specific about expected outcomes. Integrating outcomes, I arrived at the following: Virtualization is the configuration of servers or clients which results in the division of resources into multiple, isolated execution environments, by applying one or more concepts or technologies to reduce costs and enhance flexibility associated with the acquisition, implementation, management, expansion, and recovery of critical business systems. My definition takes virtualization beyond the realm of cool technology and places it where you can make a case for allocating IT budget. Virtualization, if properly planned and positioned, can quickly demonstrate return on investment (ROI) while improving your ability to agilely react to new solution requests from business managers.

Server virtualization
Figure 1.3 is a simple depiction of how to get the most from your server hardware with Hyper V. Building a Hyper V virtual environment begins with a hardware platform designed for Windows compatibility. It must be capable of 64 bit operation and be virtual technology enabled. Installed on top of the hardware layer, and abstracting it from future virtual machines (VMs), is the hypervisor. The hypervisor decouples hardware from the production operating systems running in the VMs. Configured and managed via the parent VM, it oversees hardware resources by Supporting the creation and deletion of VMs Managing memory access and security rules

Partitions

FIGURE 1.3 Hyper V concepts.

Enforcing CPU usage policy Scheduling and managing processor usage Managing attached/installed device ownership

VMs in a Hyper V world live in partitions. The first partition created contains the parent VM, which must run Windows Server 2008 x64, or Windows Server 2012 x64, or Windows Server Core. Once the parent partition is in production, you can create child partitions which contain your business server environments.

Client virtualization

Microsofts approach to client virtualization focuses on efficient, controlled, and safe distribution of applications from a central point. Based on technology acquired during Microsofts purchase of SoftGrid, App V technology has evolved into a powerful solution for organizations of any size. I think it is important to understand how Microsofts approach to application virtualization compares to other solutions. Figure 1.4 shows three primary methods used today.

FIGURE 1.4 General approaches to client virtualization.

Figure 1.5 depicts a basic Microsoft App V enabled desktop. Each application runs in an isolated environment. Although the applications share OS services and hardware resources, components unique to each application (e.g., registry entries, dynamic link libraries, COM objects, etc.) are private running within the application sandbox. App V does not virtualize the OS, just the applications.

The second piece of an App V solution for endpoint availability and security management is centralized distribution and management of applications. There are two ways to do this. First, entire applications can be downloaded to virtualized runtime environments. Second, only those components necessary for initial load and execution of the virtualized applications are downloaded. App V supports both methods and downloads additional application components as needed. Hyper V, App V, Virtual PC/MED V, and RDS are the basic building blocks of Microsoft virtualization.

FIGURE 1.5 Basic App V architecture.

Chapter 2: Intro Into Hyper-V

Hypervisor I like the definition of hypervisor that Microsoft uses in its device driver kit on MSDN (http://msdn.microsoft.com/en-us/library/ff541670.aspx) The hypervisor is a layer of software that runs above the physical hardware and below one or more operating systems. The hypervisors main purpose is to provide isolated execution environments called partitions. The hypervisor provides each partition with the partitions own set of hardware resources (for example, memory, devices, and CPU cycles). The hypervisor must control and arbitrate access to the underlying hardware. The hypervisor is a single binary that contains several components (for example, scheduler, partition management, and virtual processor management).

Hyper-V Architecture
If you really want to understand how a product works, it is often helpful to understand the architecture of that product. And understanding the architecture is easier if regularly used terms are defined.

Guest The operating system environments that run in the partitions are referred to as guests. They are also often called virtual machines, or VMs. One of the goals of the hypervisor is to be agnostic to what sort of operating system environment is running in the guest.

Parent Partition In general all partitions created by the hypervisor are equal. However, you will see as we get deeper into the specifics of Hyper-V that the parent partition (sometimes called the root partition) acts as the owner of all the hardware resources. The ownership of physical memory and logical cores presents a special case. When a child partition is created, the parent partition allocates physical memory to the child and then the child partition manages it. Similarly, virtual cores are allocated to the child partitions and then scheduled by the operating system running in the child partitions. This is different from the architecture of VMware ESX, as in that architecture the hypervisor owns the hardware resources.

Because the parent partition in Hyper-V owns all the hardware resources, it also handles other system functions generally thought as being part of an operating system. These include things like booting the system, creating and managing other partitions, Plug and Play recognition, hardware error reporting, and so on. This is different from ESX, which handles all these functions in the hypervisor. Hardware Virtualization Hardware virtualization is the act of providing multiple logical instances of physical hardware for use by the operating system environments running in the partitions. For example, on a system with only two cores, it may be possible to run three or four virtual machines, each with two cores.

Emulation Emulation is the process by which a virtualized device mimics a real physical hardware device so that guests can use the typical drivers for that hardware device. This means that a well-known hardware device, like the DEC 21140 network card, can use the device driver that is included in nearly every operating system. Emulated devices are less efficient than synthetic devices, but emulated devices provide support for operating systems that do not have integration components installed.

VM Bus The VM Bus is a high-speed memory bus that was developed specifically for Hyper-V. Any I/O traffic that passes to/from a child partition to the parent partition traverses the VM Bus. This special kernel-mode driver is installed when the Hyper-V role is installed. Requests for access to physical devices, such as disks and network cards, are transmitted over the VM Bus to achieve the highest possible performance.

Synthetic Device Synthetic devices are purely virtualized devices with no physical hardware counterparts. They function only in the context of virtual machines running under Hyper-V. Drivers for synthetic devices are included with the Integration Components for the guest operating system. The synthetic device drivers use the VM Bus to communicate with the virtualized device software in the root partition.

Emulated or Legacy Device Hyper-V provides the ability to run operating systems that were written to run on physical hardware and have no knowledge of what virtualization is. This applies to older operating systems, such as Windows NT and Windows 98. These are known as legacy operating systems. Hyper-V provides emulated or legacy hardware devices. A given devices functions are emulated entirely in software in order that the legacy operating systems can access whatever the physical device is on the host computer. For example, the legacy NIC is a software-emulated DEC 21140 network interface card. By providing this legacy network interface, legacy operating system environments can still operate under Hyper-V even though the host environment might have a totally different physical device.

Integration Components Integration Components are a set of services and drivers that improve the integration and performance between the physical and virtual machines. These components enable the guest operating systems to use the higher-performing synthetic devices instead of emulated devices. This reduces the overhead required for the emulation of devices. Integration Components make use of the VM Bus directly, thereby bypassing any emulation of a physical hardware device. Performance of synthetic devices with Integration Components approaches the performance of a physical device. Integration Components provide the following capabilities to the supported operating systems: Synthetic devices (IDE, SCSI, NIC, video, mouse) OS shutdown Time synchronization Data exchange Heartbeat Volume Shadow Copy Services

Virtual Processors Each child partition has one or more virtual processors, sometimes called cores or logical processors, associated with it. A virtual processor is a virtualized instance of an x86 or x64 processor complete with user-level and system-level registers. Hyper-V does not use hard processor affinities, so a virtual processor may move from one physical processor to another, depending on how the individual thread gets scheduled. Hyper-V schedules virtual processors according to specified scheduling policies and constraints to try to maintain locality for better performance, but there may be situations that move a virtual processor from one physical core to another.

Address Translation Any virtual memory system provides each application with a zero-based virtual address space. It then has a page table in memory that is used to map the virtual addresses to the physical addresses in the host. A hypervisor introduces a second level of complexity into this. Because it allocates chunks of physical memory to each virtual machine, it needs to provide a physical memory virtualization facility to allow each partition to have a zero-based contiguous physical address space. Virtual processors support all the paging features and memory access modes that are supported in the physical environment so that the virtualized operating system runs the same in the virtual environment as it would in a physical environment. To put this into practice, the hypervisor needs to implement two levels of address translation. The first level is what comes out of the box with the guest operating system environment. This is done via standard page tables maintained by the guest. Again, because I want the

guest to run unmodified, this works exactly the same way as it would if the guest were installed on a physical host, except that the guest is writing to virtual memory instead of physical memory. A second level of address translation is provided by the hypervisor without knowledge of the guest. This allows the hypervisor to virtualize physical memory, mapping guest virtual addresses to system physical addresses. The guest physical address space is defined at the time the partition is created.

Before Hyper-V Server 2012

Hyper-V was first introduced as part of Windows Server 2008, but later that year, in October 2008, a standalone, free edition of Hyper-V, known as Microsoft Hyper-V Server 2008 was released. This standalone version contained only the core virtualization components and Windows driver model, and as a result, offered a reduced disk footprint, and a reduced number of services running on the host OS. In October 2009, just 1 year later, both Windows Server 2008 and Microsoft Hyper-V Server 2008 were updated with the R2 release, which introduced a number of compelling capabilities to help organizations reduce costs, whilst increasing agility and flexibility. Key features introduced included: Live Migration Enabling the movement of virtual machines (VMs) with no interruption or downtime Cluster Shared Volumes Highly scalable and flexible use of shared storage (SAN) for VMs Processor Compatibility Increase the Flexibility for Live Migration across hosts with differing CPU architectures Hot Add Storage Flexibly add or remove storage to and from VMs Improved Virtual Networking Performance Support for Jumbo Frames and Virtual Machine Queue (VMq)

Finally, in February 2011, With the addition of Service Pack 1 (SP1) for Hyper-V, Microsoft introduced 2 new, key capabilities to help organizations realize even greater value from the platform: Dynamic Memory More efficient use of memory while maintaining consistent workload performance and scalability. RemoteFX Provides the richest virtualized Windows 7 experience for Virtual Desktop Infrastructure (VDI) deployments.

Chapter 3: Hyper-V 3.0

This chapter is designed to get you started quickly with Hyper-V 3.0. It starts with a discussion of the hardware requirements for Hyper-V 3.0 and then explains a basic Hyper-V deployment followed by an upgrade from Hyper-V 2.0 to Hyper-V 3.0. The chapter concludes with a demonstration of migrating virtual machines from Hyper-V 2.0 to Hyper-V 3.0

Hardware requirements
According to Microsoft, the minimum hardware required for deploying Windows Server 2012 includes: A 64-bit processor operating at 1.4 GHz or higher 512 MB of RAM 32 GB of hard disk space A DVD Drive A monitor and video card with a minimum display resolution of 800 x 600 Keyboard and mouse (or other compatible pointing device) Internet access

Because Hyper-V is designed to use the servers hardware to host a number of virtual machines, the minimum system requirements are not suitable for Hyper-V. Specifically, you will need more memory and hard disk space, and its advisable to have a server with multiple sockets and/or multiple CPU cores. In addition to the hardware requirements listed above, the CPU must support hardware-level virtualization. It is worth noting that virtualization has been disabled by default on many servers, so you may need to enable virtualization through the system BIOS, as shown in Figure 3.1. If your servers BIOS contains a setting for Data Execution Prevention (DEP), you will need to enable that setting as well.

FIGURE 3.1 Enable virtualization in the servers BIOS.

Installing Windows Server 2012 and Hyper-V 3.0

Setting up a clean installation of Windows Server 2012 and Hyper-V 3.0 is relatively simple and straightforward. First, install Windows Server 2012 by checking this blog post : http://bit.ly/YNvx5g or completing these steps : 1. Boot your server from the Windows Server 2012 installation media. 2. When the Windows Server 2012 splash screen launches, verify that the language, time and currency format, and keyboard or input methods are correct (Figure 3.2).

FIGURE 3.2 Verify installation preferences.

3. Click Next. 4. Click Install Now (Figure 3.3).

FIGURE 3.3 Click Install Now.

5. Choose the operating system that you want to install (Figure 3.4). It is worth noting that a default Windows Server 2012 does not include the GUI. If you want to use the GUI then do not choose the Server Core option. Although Server Core is Microsofts preferred method for deploying Windows Server 2012, it is easier to manage Hyper-V through a GUI. Therefore, the instructions found throughout this book will assume that you are using the GUI.

FIGURE 3.4 Choose the edition of Windows Server 2012 that you want to install.

6. Accept the license agreement and click Next (Figure 3.5).

FIGURE 3.5 Accept Microsofts license agreement.

7. When prompted for the type of installation you want to perform, choose the option for Custom: Install Windows Only (advanced) (Figure 3.6).

FIGURE 3.6 Choose the option to perform a custom installation.

8. Choose the volume on which you want to install Windows and click Next (Figure 3.7).

FIGURE 3.7 Select the drive or volume on which you want to install Windows Server 2012.

9. Setup will now begin the installation process (Figure 3.8). After the Windows installation completes , you must work through a separate process to install Hyper-V.

FIGURE 3.8 The installation process will now begin.

Deploying Hyper-V 3.0

After Windows Server 2012 is up and running, the next step is to install the Hyper-V role. To do so, follow these steps: 1. Open the Server Manager if it is not already open. 2. Choose the Add Roles and Features command from the Manage menu (Figure 3.9).

FIGURE 3.9 Choose the Add Roles and Features command.

3. When the Add Roles and Features Wizard launches, click Next to bypass the wizards Welcome screen. 4. Click Next. 5. Choose the Role-Based or Feature-Based Installation option (Figure 3.10).

FIGURE 3.10 Choose the Role Based or Feature Based Installation option.

6. Click Next. 7. On the Server Selection screen, make sure that the local server is selected and click Next (Figure 3.11).

FIGURE 3.11 Make sure that your local server is selected.

8. Select Hyper-V from the list of server roles (Figure 3.12).

FIGURE 3.12 Select the Hyper-V role.

9. If you are prompted to install additional features, click the Add Features button. 10. Click Next. 11. When the wizard displays the list of available features, click Next. 12. Click Next on the Hyper-V introductory screen. 13. Select the network adapters that you want to make available to your virtual machines. Be sure to reserve at least one network adapter for host management traffic (Figure 3.13).

FIGURE 3.13 Be sure to reserve a network adapter for host management traffic.

14. Click Next. 15. At this point you will see a screen asking if you want to allow the server to send and receive live migrations of virtual machines. click Next to accept the defaults. 16. When prompted, click Next to accept the default stores. 17. When the Confirmation screen is displayed, click the Install button.

Post deployment tasks

After the installation process completes, you may need to perform a number of postdeployment tasks, which might include:

Configure the hosts IP address Rename the host Join the host to a domain

The sections that follow will walk you through performing each of these tasks.

Configure the hosts IP address

In most cases, Hyper-V host servers need to have at least one NIC that is dedicated to hosting management traffic. As a best practice, you should assign a static IP address to this NIC. You can assign an IP address to the servers management NIC as follows: 1. Move the mouse to the lower left corner of the screen and right click. Choose the Control Panel option from the right-click menu. 2. When the Control Panel appears, click on Network and Internet. 3. Click on Network and Sharing Center. 4. Click on the Change Adapter Settings link. 5. Right click on the icon representing your management NIC and choose the Properties command from the shortcut menu. 6. Assuming that IPv4 is being used, select the Internet Protocol Version 4 (TCP/IPv4) option and click the Properties button (Figure 3.14). 7. Enter the IP address that you want to assign to the NIC and click OK (Figure 3.15).

FIGURE 3.14 Select Internet Protocol Version 4 (TCP/IPv4) and click the Properties button.

FIGURE 3.15 Provision your management NIC with a static IP address and click OK.

Rename the host

Windows Server 2012 automatically assigns a unique host name to each server, but it is generally advisable to assign a more meaningful name to each Hyper-V host. Doing so will make the host management process easier. To assign a new name to your Hyper-V host server, follow these steps: 1. Move the mouse to the lower left corner of the screen and right click. Choose the System option from the right-click menu. 2. When the System properties sheet appears, click on the Change Settings link (Figure 3.16).

FIGURE 3.16 Click the Change Settings link.

3. Verify that the Computer Name tab is selected and then click the Change button (Figure 3.17).

FIGURE 3.17 Click the Change button.

4. Enter a new name for the server and click OK (Figure 3.18).

FIGURE 3.18 Enter a new computer name and click OK.

5. Click OK to acknowledge the message indicating that you must restart your computer to apply the new name. 6. Click Close. 7. When prompted, click Restart Now (Figure 3.19).

FIGURE 3.19 You must restart the server before your changes will take effect.

Join the host to a domain

The process of joining a Windows Server 2012 host to a domain is very similar to that used in joining a Windows Server 2008 R2 host to a domain. To join a domain, follow these steps: 1. From the Metro interface, click the Desktop tile. 2. Move your mouse to the lower left corner of the screen and right-click on the Start tile. 3. Click on the System option on the right-click menu. 4. When the System dialog box appears, click on the Change Settings link (Figure 3.16). 5. When the System Properties sheet appears, go to the Computer Name tab and click the Change button (Figure 3.17). 6. Select the Domain option and enter the fully qualified domain name (Figure 3.18). 7. Click OK. 8. When prompted, enter a set of administrative credentials for the domain. 9. Click OK to clear the message indicating that the computer has been joined to a domain. 10. Reboot the server (Figure 3.19).

Performing an in-place upgrade from Hyper-V 2.0

If your organization is currently running Hyper-V 2.0, it is usually possible to perform an inplace upgrade to Hyper-V 3.0. In preparation for an upgrading a standalone Hyper-V 2.0 server, you must shut down any virtual machines that are currently running. To complete the upgrade, follow these steps: 1. Shut down any virtual machines that are running on the server to be upgraded. If any virtual machines are left running, the Compatibility Report will prevent the upgrade from continuing (Figure 3.20).

FIGURE 3.20 You must shut down the virtual machines prior to beginning the upgrade.

2. With Windows Server 2008 R2 still running, insert your Windows Server 2012 installation media and run the Setup program. 3. When the Windows Server 2012 splash screen appears, click Install Now (Figure 3.21).

FIGURE 3.21 Click the Install Now button.

4. When prompted, click on the option to go online to install updates (Figure 3.22).

FIGURE 3.22 You should go online to get the latest updates.

5. Enter your product key and click Next. 6. Select whether you want to perform a server core deployment or a full-server deployment that includes the GUI (Figure 3.23). It is worth noting that Windows Server 2012 is designed to perform a server core deployment by default. However, you cannot perform an in-place upgrade of a full Windows Server deployment (with a GUI) to a server core deployment. If you want a server core deployment, you will have to upgrade to the full GUI version of Windows Server 2012 and then uninstall the GUI later. The instructions provided in this book assume that you will be working with a full GUI-based installation.

FIGURE 3.23 Choose the edition of Windows Server 2012 that you want to install.

7. Click Next. 8. When prompted, accept the license agreement and click Next (Figure 3.24).

FIGURE 3.24 You must accept Microsofts license agreement.

9. Choose the option to Upgrade: Install Windows and keep files, settings, and applications (Figure 3.25).

FIGURE 3.25 Choose the option to upgrade the existing operating system.

10. Take a moment to review the Compatibility Report, which informs you of issues you need to address prior to moving forward with the upgrade (Figure 3.26). When you are finished, click Next.

FIGURE 3.26 Take a moment to read the compatibility report.

11. At this point, Windows will be installed. The remainder of the upgrade process is automated.

Migrating virtual machines from Hyper-V 2.0 to Hyper-V 3.0

One of the big disadvantages to performing an in-place upgrade is that it can cause virtual machines to be down for a significant amount of time. One way to reduce the amount of time during which virtual machines are unavailable is to perform a migration rather than an upgrade. A migration involves deploying Hyper-V 3.0 onto new hardware while your existing hardware continues to run Hyper-V 2.0. Once the deployment is complete, you can migrate the individual virtual machines from the Hyper-V 2.0 deployment to the Hyper-V 3.0 deployment.

Exporting the virtual machines

The first step in migrating virtual machines from Hyper-V 2 to Hyper-V 3 is to export the virtual machines to either a network share or to removable media. To complete the export process, follow these steps: 1. Open the Hyper-V Manager on the Hyper-V 2.0 Server. 2. Select the virtual machines that you want to export (Figure 3.27).

FIGURE 3.27 Select the virtual machines that you wish to export.

3. Click on the Export link. 4. Specify a path to write the exported content (Figure 3.28). Be sure to choose a location with plenty of free storage space.

FIGURE 3.28 Enter an export path and click the Export button.

5. Click Export. You can monitor the progress of the export by scrolling the Hyper-V Manager to view the virtual machine Status (Figure 3.29).

FIGURE 3.29 You can monitor the export process through the Hyper-V Manager.

Importing virtual machines

Importing virtual machines into Hyper-V 3.0 is a relatively easy and straightforward process. You can import one or more virtual machines as follows: 1. Open the Hyper-V Manager. 2. Right-click on the name of the Hyper-V host and select the Import Virtual Machine command from the right-click menu (Figure 3.30).

FIGURE 3.30 Right click-on your the server and select the Import Virtual Machine command from the right-click menu.

3. When the Import Virtual Machine wizard launches, click Next to bypass the wizards Welcome screen. 4. Click the Browse button. 5. Navigate to the folder containing the virtual machine that you want to import and click the Select Folder button. 6. Choose the virtual machine that you want to import (Figure 3.31).

FIGURE 3.31 Select the virtual machine that you want to import.

7. Click Next. 8. The next screen asks you to choose an import type (Figure 3.32). Unless you have a compelling reason to choose one of the other options, it is usually best to choose the option to Copy the Virtual Machine (Create a New Unique ID). This allows the exported virtual machine to be re-imported later should the need ever arise.

FIGURE 3.32 Choose the appropriate import type.

9. Click Next. 10. The following screen asks if you want to store any of the virtual machine components in a different location. Generally, it is safe to accept the defaults. Click Next. 11. The wizard will now ask where you want to store the imported Virtual Hard Disks. Select a folder on an appropriate volume and click Next. 12. Verify the summary information screen and click Finish (Figure 3.33).

FIGURE 3.33 The import process begins when you click Finish.

The import process can take a considerable amount of time to complete, depending upon the size of the virtual machine and the speed of the hardware. When the import process finishes, you should see the newly imported virtual machine within the Hyper-V Manager. Before you power-up the newly imported virtual machine, you need to connect the virtual machine to a virtual switch. To do so, right click on the virtual machine and choose the Settings command from the right-click menu. When the Settings page appears, click on the Network Adapter option and then connect the virtual machine to the appropriate virtual switch (Figure 3.34). When you have finished, click OK.

FIGURE 3.34 You must connect your virtual machine to a virtual switch.

This completes the process of importing a virtual machine. Previous versions of Hyper-V required you to re-enter the IP address configuration for each virtual network adapter. However, Hyper-V 3.0 preserves the virtual machines IP address configuration. The only change that you might need to make to the virtual machine is to install an updated version of the Hyper-V Integration Services.