When the memory configured for a virtual machine is greater than the available memory on the destination server. Consolidation of physical servers to virtual machines, or consolidation of multiple instances of Hyper-V to one instance. Hyper-V role migration involves moving the virtual machines, virtual networks, and all the associated settings from one physical computer to another physical computer in the enterprise. The migration tools include cmdlets that you use to perform some of the tasks required to migrate the Hyper-V role.
The Export cmdlet captures the majority of the Hyper-V settings that are required to perform a successful migration, including the virtual machine configurations, virtual networks, and virtual hard disks. The instructions for this are provided later in the guide. On the destination server, the import cmdlets will recreate the virtual machines. The following section describes the impact of migration on the source server and on other computers in the enterprise.
The source server should be turned off or removed from the network before you run the import cmdlets on the destination server so that there are no conflicts between the virtual machines running on the source server and the virtual machines that will be recreated on the destination server.
The point at which you should perform this task is identified in the migration steps, later in this guide. This migration may impact any computer either virtual or physical that relies on the applications or workloads running in the virtual machines to be migrated as part of the Hyper-V role migration, because the virtual machines will be offline for the duration of the migration.
For example, if a virtual machine hosts a database, any applications in the enterprise that require access to that database will be impacted. As a result, you will need to plan for this downtime by either scheduling a planned outage or by redirecting traffic to other servers to provide the services.
The user account that runs the cmdlets and tools must be a member of the local Administrators group on the source server and the destination server.
The length of time it takes to migrate the Hyper-V role depends on the size of the data to be transferred. Of the various types of files to be transferred, the.
The length of time is affected by the size of the. Windows Server Migration Portal. Skip to main content. This browser is no longer supported. Download Microsoft Edge More info. Contents Exit focus mode. Note Your detailed feedback is very important, and helps us to make Windows Server Migration Guides as reliable, complete, and easy to use as possible. The TCP connection is established to transfer the virtual machine configuration data from the source node to the destination node, and the data is used to create a new virtual machine with identical settings on the destination node.
The virtual machine configuration data includes the number and type of virtual storage adapters, virtual network adapters, virtual processor and memory allocations, and other required virtual machine configuration parameters. The next step after the virtual machine is created on the destination node is the transfer of virtual machine memory pages from the source node to the destination node. This is an iterative process since the virtual machine continues to execute on the source node as the memory data is transferred to the destination node.
In order to ensure that data is not lost, Hyper-V tracks all modifications to the memory pages on the source node and continues to transfer the memory pages to the destination node until an iteration threshold is reached or all modified memory pages are copied successfully to the destination node.
Then, the virtual machine is paused on the source node, remaining modified memory pages are copied to the destination node, and the processor register and device state is transferred from the source node to the destination node. At this stage, the Live Migration process can no longer be cancelled.
During the short period of time when the virtual machine is paused, the virtual machine storage control, including virtual hard disks and pass-through disks, is also assigned to the destination node. At this point, the virtual machine is in a consistent state and resumes execution on the destination node. The next step in the process is to force the physical network switches to update their tables with the new port to direct the network traffic for the virtual machine.
The new port is the physical network switch port that connects the destination node to the physical network. Finally, the virtual machine information is removed from the source node. The Virtual Machine is implemented as a cluster resource and when a host node fails, the Virtual Machine resource fails over to the other node. Like all other Windows Server Failover solutions, the resource is brought offline before it actually fails over. This results in a relatively small period of downtime which is unacceptable in certain environments.
A Failover cluster is a logical server consisting of two or more Windows Server servers. Windows Server supports a maximum of 16 servers in a Failover cluster. These servers are called Cluster Nodes. All Cluster Nodes in the Failover cluster are connected to a shared storage solution where the data is stored. The Virtual Machines running under Hyper-V that need to be highly available are configured as a resource in the cluster. All servers in the cluster must run the same Operating System, all nodes must either be Enterprise or Datacenter Edition and for Live Migration all servers must run the same processor family even the same processor stepping.
Therefore, if a Virtual Machine needs to be failed-over to another Cluster Node, the complete disk resource needs to be brought down, moved to the other Cluster Node and be brought online again.
To bring the Virtual Machine in a saved state a certain amount of time is needed. Starting the Virtual Machine on the new node will take the same amount of time. Needless to say, failing over a Virtual Machine can cause a significant downtime. Figure 1. One of the highest priorities for Microsoft in Windows Server R2 was to add this capability.
Installing the Storage Migration Service Proxy service on a Windows Server or Windows Server computer automatically opens the necessary firewall ports on that computer.
If the computers belong to an Active Directory Domain Services domain, they should all belong to the same forest. The destination server must also be in the same domain as the source server if you want to transfer the source's domain name to the destination when cutting over.
Cutover technically works across domains, but the fully-qualified domain name of the destination will be different from the source.
Storage Migration Service can't yet cut over from domain controllers, but can inventory and transfer files from them. You can migrate the following additional source types if the orchestrator is running Windows Server with KB installed or Windows Server The destination servers can be standalone servers or part of a Windows failover cluster.
While the Storage Migration Service does not support Azure Files as a destination, it fully supports servers running the Azure File Sync agent with cloud tiering. Destination servers running Windows Server or Windows Server have double the transfer performance of earlier versions of Windows Server.
This performance boost is due to the inclusion of a built-in Storage Migration Service proxy service.
0コメント