However, the connection between the virtual network adapter and the physical network adapter must be re-established manually, as described in the migration steps. The following configurations and settings require manual intervention after the migration tools are used:.
Firewall settings. Firewall settings are recreated on the destination server using the default values that Hyper-V is installed with.
If you have modified any of the firewall settings from these default values, you will need to make the same modifications on the destination server.
External virtual networks. The migration tool recreates the virtual networks on the destination server, but recreates external virtual networks as internal virtual networks.
You will need to modify each of these networks to connect it to the appropriate physical network adapter on the destination server, as described in the migration steps. These files are not migrated because they are not required for the virtual machine to operate and are not supported by the Import and Export cmdlets.
To make them available to a migrated virtual machine, manually copy these files to the destination server and then reattach them to the virtual machine after it is migrated.
Connections to physical disks directly attached to virtual machines. To make a physical disk available to a migrated virtual machine, connect the disk to the destination server and then to the virtual machine after it is migrated, as described in the migration steps. Customized remote administration settings. The migration steps identify the point at which you should take perform these procedures, as well as provide a recommended tool or script to complete the procedure.
The Hyper-V role is not dependent on any other roles. As a best practice, we recommend that no other roles are installed on a server running Hyper-V. When the number of virtual processors configured for the virtual machine is more than the number of logical processors on the destination server. 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.
When paired with Windows Failover Clustering, live migration allows the creation of highly available and fault tolerant systems. Live migration is often used in conjunction with a few related technologies like Failover Clustering and System Center Virtual Machine Manager. If you're using Live Migration via these technologies, here are pointers to their latest documentation:.
If you're using older versions of Windows Server, or need details on features introduced in older versions of Windows Server, here are pointers to historical documentation:. In Windows Server , there are fewer restrictions on live migration deployment. It now works without Failover Clustering.
Other functionality remains unchanged from previous releases of Live Migration. For more details on configuring and using live migration without Failover Clustering:.
Therefore, it is crucial to fully understand and test the configuration of any Hyper-V failover cluster that will support Live Migration. In particular, you should use high-speed network connection links, with a minimum of 1 Gbps Ethernet, to optimize the memory and state data transfers between the source and destination nodes. Additionally, you must be aware that a Live Migration is not an instantaneous event, and that the amount of time needed to complete the migration process is dependent on several parameters:.
Although not a requirement, if you want to optimize the shared storage configuration of a Hyper-V Failover Cluster to support Live Migration, you should implement Cluster Shared Volumes. You should also take into consideration that each Hyper-V failover cluster node can take part only as the source or destination in a single live migration at a time. Therefore, in a fully expanded, node failover cluster, you can only perform a maximum of eight concurrent Live Migrations.
Up until Windows Server R2, only a single failover cluster node was allowed to have ownership of a LUN and access to the data stored on it. In contrast, the new Cluster Shared Volumes feature in Windows Server R2 allows multiple cluster nodes to concurrently access a LUN on a shared storage system while providing a consistent file namespace to all cluster nodes.
However, all virtual machine VHDs can reside on a single LUN, and every cluster node can have access to the volumes using the same fully qualified path. By default, Cluster Shared Volumes are created as directories beneath a root folder named ClusterStorage. However, you can modify the root folder name as required in your environment. If you are designing a virtualization infrastructure with the requirement to dynamically move virtual machines without data loss or service interruption, you should download Windows Server R2 Hyper-V , and begin to learn and test the new Live Migration feature.
Janique Carbone has been working in IT for over 20 years on projects ranging from application development to enterprise infrastructure design. After 7 years at Microsoft, she founded the Infrastructor Group to deliver virtualization and cloud computing consulting services. Janique has developed technology training for events such as TechEd, partner training courses for Microsoft Learning, and co-authored two MSPress titles on virtualization. In her precious spare time, Janique is an avid tennis player and fan.
Your email address will not be published.
0コメント