What’s new in System Center 2012 R2 – Virtual Machine Manager?

During the last TechEd North America, Microsoft wraps off what will be the new System Center 2012 R2. The upgrade follows the impressive number of new features on Windows Server 2012 R2 as well as improvements to existing capabilities in Windows Server 2012.

Here are some of the new and improved features related to System Center 2012 R2 – Virtual Machine Manager (SCVMM):

Infrastructure improvements

• Guest and host support for Windows 2012 R2
• Auto-task resume after VMM server failover
• Expanded scope for update management
• Updated management packs:
  • Better integration with chargeback and reporting
  • Additional dashboards

Networking improvements

• Site-to-site networking
• IP Address Management (IPAM) integration
• Simplified guest IP management
• Top of rack switch integration
• Making forwarding extensions for Hyper-V extensible switch work with Hyper-V network virtualization (Cisco 1KV and NVGRE)

Storage improvements

• Synthetic fibre channel support
• Management of zones
• Offloaded Data Transfer (ODX) support
• Shared VHDX support
• Provision scale-out file server cluster from bare metal
• Integration with differencing disks

Services improvements

• Run scripts on first machine on a tier
• Shared VHDx across members of a tier
• Service Setting for Service Topology
• Service deployments work for VMs on Xen

VM and cloud improvements

• Differencing disks
• Live cloning
• Online VHDX resize
• Grant permissions to users for each cloud
• Ability to inject files into VM prior to the first boot

In my opinion one of the biggest news is the recommendation and best practices to have SCVMM on a VM on same virtualization platform that SCVMM is managing. This change a lot in your System Center design and infrastructure if you want to implement a High-Available and resilience System Center environment.

Cheers,

Marcos Nogueira
http://blog.marcosnogueira.org
Twitter: @mdnoga

Overview of Networking with Windows Server 2012 R2

Windows Server 2012 R2 makes it as straightforward to manage an entire network as a single server, giving you the reliability and scalability of multiple servers at a lower cost. Automatic rerouting around storage, server, and network failures enables file services to remain online with minimal noticeable downtime. In addition, Windows Server 2012 R2 provides the foundation for software-defined networking out-of-the-box – enabling seamless connectivity across public, private, and hybrid cloud implementations.

It offers several new and enhanced features that can help reduce networking complexity while lowering costs, simplifying management tasks, and delivering services reliably and efficiently.

Software-defined networking

Software-defined networking (SDN) enhances the management of modern networks by providing the ability for applications to control access to network resources dynamically. A key enabler of SDN is that it uses networking functionality that has been moved to a virtual switch, providing the ability to modify packets in transit and enabling integration of more advanced switch extensions. Finally, SDN also brings the benefit of unifying the management of both the physical and virtual infrastructure.

Hyper-V Network Virtualization and the Hyper-V Extensible Switch are the foundations of SDN in Windows Server 2012 R2. You can isolate network traffic from different business units or customers on a shared infrastructure and not be required to use VLANs. Hyper-V Network Virtualization also lets you move virtual machines as needed within your virtual infrastructure while preserving their virtual network assignments. You can even use Hyper-V Network Virtualization to transparently integrate these private networks into a preexisting infrastructure on another site.

Hyper-V Network Virtualization extends the concept of server virtualization to allow multiple virtual networks, potentially with overlapping IP addresses, to be deployed on the same physical network. With Hyper-V Network Virtualization, you can set policies that isolate traffic in your dedicated virtual network independently of the physical infrastructure.

The Hyper-V Extensible Switch in Windows Server 2012 R2 is a layer-2 virtual network switch that provides programmatically managed and extensible capabilities to connect virtual machines to the physical network. It is an open platform that makes it possible for multiple vendors to provide extensions that are written to standard Windows API frameworks, the reliability of which are strengthened through the Windows standard framework.

On the same physical network, with Hyper-V Network Virtualization and the Hyper-V Extensible Switch, you can run multiple virtual network infrastructures and you can have overlapping IP addresses with each virtual network infrastructure acting as if it was the only one running on the shared physical network infrastructure.

In Windows Server 2012, we also introduced a feature called cross-premises connectivity, with provides VPN site-to-site functionality to help establish cross-premises connectivity between enterprises and hosting service providers. Cross-premises connectivity enables enterprises to connect to private subnets in a hosted cloud network. It also enables connectivity between geographically separate enterprise locations. However, some of the limitations of this feature were that you needed one gateway per tenant. Windows Server 2012 R2 now includes a multi-tenant VPN gateway built right into the operating system. This function can provide a seamless connection over a site-to-site VPN link between multiple external organizations and the resources that those organizations own in a hosted cloud. It also enables connectivity between physical and virtual networks, enterprise datacenters, and hosting organizations, and between enterprise networks and Windows Azure.

Another challenge on the path to a software-defined datacenter has been the fact that today’s datacenters are made up of different classes of devices – such as load balancers, power distribution units, baseboard management controllers (BMCs), top-of-rack (TOR) switches, and routers – from a variety of device manufacturers.

Windows Server 2012 R2 includes standards-based switch configuration as a device management abstraction layer that further reduces the complexity of heterogeneous device management with the goal that devices can be easily managed and configured using standards technologies. Windows Server 2012 R2 allows you to enable device management using a common abstraction layer, working over standard protocol and schema; as a consequence, it allows you to move from a complex datacenter device world into a world of well-defined, standard based components; and build a ready to use solution for device management right in Windows.

High-performance networking

Single Root I/O Virtualization (SR-IOV) is a standard introduced by the PCI-SIG, the special-interest group that owns and manages PCI specifications as open industry standards. SR-IOV works in conjunction with system chipset support for virtualization technologies that provide remapping of interrupts and Direct Memory Access, and allows SR-IOV-capable devices to be assigned directly to a virtual machine.

Introduced with Windows Server 2012, Hyper-V enables support for SR-IOV-capable network devices and allows a SR-IOV virtual function of a physical network adapter to be assigned directly to a virtual machine. This increases network throughput and reduces network latency while also reducing the host CPU overhead required for processing network traffic. You can configure your systems to maximize the use of host system processors and memory to effectively handle the most demanding workloads. These Hyper-V features let you take full advantage of the largest available host systems to deploy mission-critical, tier-1 business applications with large, demanding workloads.

Windows Server 2012 R2 also helps you provide fault tolerance on your network adapters without having to buy additional hardware and software. Windows Server 2012 R2 includes NIC Teaming which allows multiple network interfaces to work together as a team, preventing connectivity loss if one network adapter fails. NIC Teaming also allows you to aggregate bandwidth from multiple network adapters, so for example, four 1-gigabyte (GB) network adapters can provide an aggregate of 4 GB/second of throughput. In Windows Server 2012 R2, the load-balancing algorithms have been further enhanced with the goal to better utilize all NICs in the team, significantly improving performance.

The advantages of a Windows NIC Teaming solution are that it works with all network adapter vendors, spares you from most potential problems that proprietary solutions cause, provides a common set of management tools for all adapter types, and is fully supported by Microsoft.

Improved manageability and diagnostics

Windows Server 2012 R2 builds on the networking advances in Windows Server 2012 with an array of new and enhanced features that help reduce networking complexity while lowering costs and simplifying management tasks. With Windows Server 2012 R2, you now have the tools to automate and consolidate networking processes and resources.

IP Address Management (IPAM), introduced in Windows Server 2012, is an out-of-the-box framework for discovering, monitoring, auditing, and managing the IP address space and the associated infrastructure servers on a corporate network. IPAM provides automatic IP address infrastructure discovery, migration of IP address data from spreadsheets or other tools, custom IP address space display, reporting and management, audit of server configuration changes and tracking of IP address usage, and monitoring and specific scenario-based management of DHCP and Domain Name System services. Windows Server 2012 R2 adds virtual IP address space management, which means that IPAM in Windows Server 2012 R2 now can show both the physical and the virtual address space in a single view, including tenant IP subnets and address spaces as well as the provider IP address space.

Since Windows Server 2012, you have been able to manage Quality of Service (QoS) policies and settings dynamically with Windows PowerShell. Most hosting providers and enterprises today use a dedicated network adapter and a dedicated network for a specific type of workload such as storage or live migration to help achieve network performance isolation on a server running Hyper-V. QoS minimum bandwidth benefits vary between service providers to enterprises. For service providers, QoS management allows them to host customers on a server running Hyper-V and still be able to provide a certain level of performance based on SLAs. It also helps them to ensure that customers won’t be affected or compromised by other customers on their shared infrastructure, which includes computing, storage, and network resources. For enterprises, QoS management allows them to run multiple application servers on a server running Hyper-V and be confident that each application server will deliver predictable performance.

Hyper-V in Windows Server 2012 R2 helps providers build a multitenant environment in which virtual machines can be served to multiple clients in a more isolated way. Because a single client may have many virtual machines, aggregation of resource use data can be a challenging task. However, Windows Server 2012 R2 simplifies this task by using resource pools, a Hyper-V feature that allows for resource metering. Resource pools are logical containers that collect the resources of the virtual machines that belong to one client, permitting single-point querying of the client’s overall resource use. Resource Metering in Windows Server 2012 R2 can measure and track a series of important data points, including the following:

• The average CPU, in megahertz, used by a virtual machine over a period of time.
• The average physical memory, in megabytes, used by a virtual machine over a period of time.
• The lowest amount of physical memory, in megabytes, assigned to a virtual machine over a period of time.
• The highest amount of physical memory, in megabytes, assigned to a virtual machine over a period of time.
• The highest amount of disk space capacity, in megabytes, allocated to a virtual machine over a period of time.
• The total incoming network traffic, in megabytes, for a virtual network adapter over a period of time.
• The total outgoing network traffic, in megabytes, for a virtual network adapter over a period of time.

Cheers,

Marcos Nogueira
http://blog.marcosnogueira.org
Twitter: @mdnoga

Overview of Storage with Windows Server 2012 R2

Storage solutions play a critical role in the modern datacenter. Windows Server 2012 R2 was designed with a strong focus on storage capabilities, from the foundation of the storage stack up, to improvements ranging from provisioning storage to how data is clustered, transferred across the network, and ultimately accessed and managed. With flexible capabilities that can be combined to meet your business needs, Windows Server 2012 R2 storage solutions deliver the efficiency, performance, resiliency, availability, and versatility you need at every level.

High-performance storage on industry-standard hardware

Windows Server 2012 R2 provides a rich set of storage features allowing you to take advantage of lower-cost industry-standard hardware rather than purpose-built storage devices, without you having to compromise on performance or availability.

For example, Storage Spaces provides sophisticated virtualization enhancements to the storage stack that you can use to pool multiple physical hard disk units together and provide feature-rich, highly resilient, and reliable storage arrays to your workloads. You can use Storage Spaces to create storage pools, which are virtualized administration units that are aggregates of physical disk units. With these storage pools, you can enable storage aggregation, elastic capacity expansion, and delegated administration. You can also create virtual disks with associated attributes that include a desired level of resiliency, thin or fixed provisioning, and automatic or controlled allocation on diverse storage media.

Storage tiering, a new feature in Windows Server 2012 R2, is a great example of how storage performance can be dramatically enhanced while using lower-cost industry standard hardware. With storage tiering, low cost, high capacity spinning disks are used to store less frequently used data, while high-speed solid state disks are reserved to store frequently used data. Storage tiering builds on storage virtualization with Storage Spaces by assigning solid state drives (SSD) and hard disk drives (HDD) to the same storage pool and using them as different tiers in the same tiered space. Windows Server 2012 R2 recognizes the tiers and optimizes them by moving often used “hot” data to the SSD tier. Windows Server 2012 R2 tracks data temperature and moves data at the sub-file level; only “hot” regions of a file (such as VHD or database) need to move to SSDs, the “cold” regions can reside on HDDs.

Since Windows Server 2012, with a feature referred to as SMB Direct, the SMB protocol has provided support for Remote Direct Memory Access (RDMA) network adapters, which allows storage performance capabilities that rival Fiber Channel. RDMA network adapters enable this performance capability by operating at full speed with very low latency due to the ability to bypass the kernel and perform write and read operations directly to and from memory. This capability is possible since reliable transport protocols are implemented on the adapter hardware and allow for zero-copy networking with kernel bypass. With this capability, applications, including SMB, can perform data transfers directly from memory, through the adapter, to the network, and then to the memory of the application requesting data from the file share.

Continuous application availability and robust recovery

Windows Server 2012 R2 reduces server downtime and application disruption by letting you store server application data on file shares and obtain a similar level of reliability, availability, manageability, and high performance that would typically be expected from a high-end Storage Area Network (SAN).

Introduced in Windows Server 2012, SMB Transparent Failover allows you to transparently move SMB file shares between the file server cluster nodes, without noticeable interruption of service for the SMB client. This is useful for planned events (for example, when you need to perform maintenance on a node) or surprise events (for example, when a hardware failure causes a node to fail). This is achieved regardless of the kind of operation that was underway when the failure occurred.

One the main advantages of file storage over block storage is the ease of configuration, paired with the ability to configure folders that can be shared by multiple clients. Windows Server 2012 has taken file-based storage one step further by introducing the SMB Scale-Out feature, which provides the ability to share the same folders from multiple nodes of the same cluster. This is made possible by the use of Cluster Shared Volumes (CSV), which since Windows Server 2012 support file sharing. New in Windows Server 2012 R2, SMB sessions can now also be managed per share (not just per file server), increasing flexibility. And SMB Scale-out now also offers finer-grained load distribution by distributing workloads from a single client across many nodes of a scale-out file server.

Another innovation around Windows Server 2012 R2 is the Windows Azure Hyper-V Recovery Manager offering, a related service which offers a robust recovery solution that takes advantage of Hyper-V Replica.

For organizations with two or more datacenters looking to protect vital workloads running in their datacenter, Windows Azure Hyper-V Recovery Manager enables them to combine Windows Azure, System Center Virtual Machine Manager, and Hyper-V Replica to deliver planned and cost-effective business continuity of workloads. With Windows Azure Hyper-V Recovery Manager, datacenters can be protected by automating the replication of the virtual machines that compose them at a secondary location. Windows Azure Hyper-V Recovery Manager also provides continuous health monitoring of the primary datacenter, and it helps automate the orderly recovery of services in the event of a site outage at the primary datacenter. Virtual machines are started in an orchestrated fashion to help restore service quickly. This process can also be used for testing recovery without disruption to services, or temporarily transferring services to the secondary location.

Comprehensive storage management and backup

Windows Server 2012 R2 provides great management and backup capabilities that help you better manage your storage capacity whether you have a single server or multiple servers, whether you have one class of storage or a variety of storage solutions, and whether you have a Windows only or a heterogeneous environment.

Storage QoS is a new feature in Windows Server 2012 R2 that allows you to restrict disk throughput for overactive or disruptive virtual machines and can be configured dynamically while the virtual machine is running. For maximum bandwidth applications, it provides strict policies to throttle IO to a given virtual machine to a maximum IO threshold. For minimum bandwidth applications, it provides policies for threshold warnings that alert of an IO starved VM when the bandwidth does not meet the minimum threshold.

Also, to help improve storage management efficiency and offset that cost, Windows Server 2012 R2 comes with a set of storage management APIs and provider interfaces that enables administrators to centrally manage disparate storage resources and solutions, such as SANs and storage arrays, from a centralized “single pane of glass” interface. Manageable resources can include SANs that are SMI-S compliant, storage devices with proprietary hardware that has compatible third-party storage management providers, or storage devices that are already being allocated through the use of Storage Spaces. This storage management capability will allow administrators to configure and manage all of the storage devices throughout their organization or management sphere through an easy-to-use management interface that they are already familiar with, the Server Manager in Windows Server.

By using Server Manager, administrators can populate server groups with file servers or storage clusters that leverage Storage Spaces, or reach out to populate manageable devices that have SMI-S agents enabled.

If you have a small number of servers to protect and you currently have no backup solution or you are using the inbox Windows Server Backup tool on these servers, Windows Azure Backup is a separate offering that extends the capabilities of Windows Server Backup and System Center Data Protection Manager to deliver simple and reliable off-site data protection at the cost of cloud storage. It is suitable for any workload, such as file servers, SharePoint, SQL, Exchange, and others.

Cheers,

Marcos Nogueira
http://blog.marcosnogueira.org
Twitter: @mdnoga

What’s New in Windows Server 2012 R2 – Hyper-V

During the last TechEd North America, Microsoft wraps off what will be the new Windows Server 2012 R2. The upgrade brings an impressive number of features as well as improvements to existing capabilities in Windows Server 2012.

Here are some of the new and improved features related to Hyper-V:

New Generation of Virtual Machines – Generation 2 of virtual machines

• Legacy free
• UEFI based
  • Many emulated devices removed
  • Boots from virtual SCSI or synthetic network adapters
  • Enables UEFI secure boot standard
• Supported guest operating systems:
  • 64-bit versions of Windows 8 and Windows Server 2012
  • 64-bit versions of Windows 8.1 and Windows Server 2012 R2

Enhanced VM Interaction – Remote Desktop over VMBus

• Full remote desktop capabilities
  • Shared clipboard
  • Audio redirection
  • Enhanced login
  • and more….
• Enabled even when the network is down
• Integrated into Hyper-V Management experience

Automatic Activation

• Zero touch activation of virtual machines
• Virtual machines automatically activated according to the hosting environment
• Reduces configuration for hosters / enterprises

Zero-downtime upgrade

• Live migrate virtual machines from
  Windows Server 2012 to Windows Server 2012 R2
• Includes shared nothing live migration

Faster Live Migration

• Compression
  • Over 2x improvement in live migration time
  • No hardware changes are required
  • Enabled by default
• SMB Direct
  • Utilizes existing and new high-end networks
  • Enables super high-speed live migrations
  • Supports SMB Multichannel to leverage multiple interfaces

Online VHDX resize

• Increase and decrease the size of virtual hard disks – while the virtual machine is running

Live virtual machine export / clone

While the virtual machine is running…

• Export a complete copy – including memory state
• Export any snapshot of a virtual machine

Continuing Linux Guest Support

• Full dynamic memory
• Online backup
• Online VHDX resize
• New video driver

Storage QoS

• Enables constant SLA delivery
• Dynamically configurable while the virtual machine is running
• Can restrict disk throughput for overactive / disruptive virtual machines

Guest clustering with shared virtual disks

• Guest Clustering
  • Guest Clustering with commodity storage
  • Sharing VHDX files provides shared storage for Hyper-V Failover Clustering
  • Maintains separation between infrastructure and tenants
• Virtual SAS
  • VM presented a shared virtual SAS disk
  • Appears as shared SAS disk to VM

Hyper-V Replica

• Extended replication
• Finer grained control of replication
• And more…

Cheers,

Marcos Nogueira
http://blog.marcosnogueira.org
Twitter: @mdnoga

Capacity Planner for Hyper-V Replica

Hyper-V in Windows Server 2012 includes a new capability called Hyper-V Replica. Hyper-V Replica allows administrators to replicate their virtual machines from a primary server/cluster to a replica server/cluster. The Capacity Planner for Hyper-V Replica guides the IT administrator to design the server, storage and network infrastructure which is required to successfully deploy Hyper-V Replica.

After reviewing the license terms, Click on ‘I accept the license term’ and click on ‘Next’.

Before proceeding from this page, ensure that a Hyper-V Replica server/cluster has been enabled to receive replication traffic from this primary server/cluster. As part of collecting various metrics, the capacity planner attempts to send a temporary VHD from the primary server/cluster to the replica server/cluster. This allows the tool to study the network characteristics of the link between the primary and replica server.

If your primary or replica server is part of a cluster, ensure that the Hyper-V Replica Broker role is added to the cluster.

Specify the following parameters in this screen and click ‘Next’:

Primary Server/Cluster details:

a. For a standalone primary server, enter the server name or FQDN.

b. If your primary server is part of a cluster, enter the FQDN of the (primary cluster) Hyper-V Replica Broker Client Access Point (CAP).

Replica Server/Cluster details:

a. For a standalone replica server, enter the server name or FQDN.

b. If your replica server is part of a cluster, enter the FQDN of the (replica cluster) Hyper-V Replica Broker Client Access Point.

Estimated WAN Bandwidth:

a. Enter the estimated WAN bandwidth link speed between the primary and replica server/cluster.

Duration of collecting metrics:

a. Enter an appropriate interval for which the metrics need to be collected. It is highly recommended that the tool is run during ‘production hours’ which ensures that the most representative data is collected. Running the tool for a short duration (eg: 10mins) may not give quality data.

The tool connects to the primary server and enumerates the virtual machines which are running on the primary. Ensure the following:

1) You are an administrator on the primary server/cluster. Remote-WMI is used to enumerate the virtual machines on the primary server – ensure that the right set of firewalls and permissions are set to allow this call to execute.

2) Ensure that replication has not been enabled on any of the VMs which are on the primary server/cluster.

3) Ensure that the VMs on the primary server/cluster are running.

The following details needs to be provided in the page:

1) Temporary VM location: As part of collecting various metrics, the tool creates a temporary VM on your primary server/cluster and enables replication on the VM. This allows the tool to study the network characteristics between the primary and replica server. Provide a location on the primary server/cluster in which this VHD/VM can be created. In a clustered deployment, ensure that the location is accessible from all the nodes in the cluster.

2) (Optional) Certificate: If your primary and replica servers are in a workgroup [or] if certificate based authentication is being used in your Hyper-V Replica environment, you should provide the required certificate in this page.

3) Select VMs and VHDs: You can select the VMs and VHDs on which the metrics need to be collected. If you are not planning to enable replication on any specific VM/VHD, you can uncheck the VM in this screen.

Click ‘Next’ after providing all the inputs.

The tool now captures the metrics in the background. The tool will run for a few minutes beyond the duration of the run. You can continue to operate on your VM during the duration of the run. Once completed, the screen will look as follows:

Click on ‘View Report’ to go over the recommendations.

Cheers,

Marcos Nogueira
http://blog.marcosnogueira.org
Twitter: @mdnoga

Statistics of a NIC Teaming

If the UI window is sufficiently tall a statistics tile appears at the bottom of the Team tile and the Adapters and Interfaces tile. These statistics windows reflect the traffic of the selected team and selected team member. If you don’t see the statistics try making the UI window a little taller.

Viewing statistics for a team interface

If the Team Interfaces tab is selected in the Adapters and Interfaces tile the statistics at the bottom of the Adapters and Interfaces tile will be those of the selected team interface.

Setting frequency of Statistics updates

The frequency of statistics updates and other updates can be set by selection Settings in the Servers tile Tasks menu. Selecting this item brings up the General Settings dialog box.

The two drop-down lists in this dialog box allow the user to change how often the UI is refreshed. The settings apply equally to all servers in the servers list.

This menu also allows the administrator to decide whether or not adapters that are not able to be part of a team should be shown in the UI. By default these non-teamable adapters are not shown.

Cheers,

Marcos Nogueira
http://blog.marcosnogueira.org
Twitter: @mdnoga

Microsoft System Center Virtual Machine Manager 2012 Cookbook

I definitely recommend this book for who wants to know in deep System Center 2012 Virtual Machine Manager SP1.

http://link.packtpub.com/POCsIQ

What you will learn from this book

• How to use VMM Architecture and plan for a real word deployment
• Utilize Network Virtualization, Gateway integration, Storage integration, Resource Throttling, and Availability options
• Deploy Operations Manager and integrate with VMM
• Integrate SC APP Controller with VMM to manage Private and Public Clouds (Azure)
• Cluster deployment with VMM Bare Metal
• Create and deploy Virtual Machines from Templates
• Deploy a highly available VMM Management Server
• Manage Hyper-V, Vmware, and Citrix from VMM
• How to upgrade from SCVMM 2008R2 to SCVMM 2012 SP1

In Detail

Microsoft System Center 2012 is a comprehensive IT infrastructure, virtualization, and cloud management platform. With System Center 2012, you can more easily and efficiently manage your applications and services across multiple hypervisors as well as across public and private cloud infrastructures to deliver flexible and cost-effective IT services for your business.

This cookbook covers architecture design and planning and is full of deployment tips, techniques, and solutions designed to show users how to improve VMM 2012 in a real world scenario. It will guide you to create, deploy, and manage your own Private Cloud with a mix of Hypervisors: Hyper-V, Vmware ESXi, and Citrix XenServer. It also includes the VMM 2012 SP1 features.

This book is a cookbook that covers architecture design, planning and is full of deployment tips, techniques and solutions designed to show users how to improve VMM 2012 in a real world scenario. It will guide you to create, deploy and manage your own Private Cloud with a mix of Hypervisors : Hyper-V, Vmware ESXi and Citrix XenServer.

Approach

This is a Packt Cookbook, full with over 75 recipes for VMM users to carry out vital tasks quickly and easily.

Who this book is for

This book is written for solutions architects, technical consultants, administrators, and any other virtualization lover who needs to use Microsoft System Center Virtual Machine Manager in a real world environment.

Cheers,

Marcos Nogueira
http://blog.marcosnogueira.org
Twitter: @mdnoga

Modifying a NIC Team through GUI and PowerShell

Modifying a team through the UI

Within the UI, modifications to the team can be done by selecting a team in the Team tile, right-clicking on the team, and selecting the Modify Team action. Selecting Modify Team will pop-up the Team properties dialog box. This dialog box is very similar to the

In the Team properties dialog box the following actions can be accomplished:

• Rename the team: Select the team name and edit it.
• Add team members: Select additional adapters from the Member Adapters tile
• Remove team members: De-select adapters from the Member Adapters tile. At least one adapter must be selected.

If the Additional properties drop-down item is selected then the Teaming mode and Load distribution mode may also be modified. This Additional properties drop-down also allows the administrator to select a standby adapter when active-standby mode is desired.

Modifying a team through Windows PowerShell

Renaming a team

To rename Team1 and give it the name TeamA, the Windows PowerShell is:

Rename-NetLbfoTeam Team1 TeamA

Changing the teaming mode

The Windows PowerShell options for teaming mode are:

• SwitchIndependent
• Static
• LACP

To change Team1 to an 802.1ax LACP team, the Windows PowerShell is:

Set-NetLbfoTeam Team1 ‑TeamingMode LACP

The “-TeamingMode” flag can be abbreviated “-TM”, as in

Set-NetLbfoTeam Team1 –TM LACP

Note: For security reasons teams created in VMs may only operate in SwitchIndependent mode.

Changing the load distribution algorithm

The Windows PowerShell options for load distribution algorithm are:

• TransportPorts
• IPAddresses
• MacAddresses
• HyperVPort

To change Team1’s Load balancing algorithm to Hyper-V Ports, the Windows PowerShell is:

Set-NetLbfoTeam Team1 ‑LoadBalancingAlgorithm HyperVPorts

The “-LoadBalancingAlgorithm” flag can be abbreviated “-LBA”, as in

Set-NetLbfoTeam Team1 ‑LBA HyperVPorts

To change the Teaming mode and Load balancing algorithm at the same time,

Set-NetLbfoTeam Team1 ‑TM LACP ‑LBA HyperVPorts

Note: Teams created in VMs may not use the HyperVPort load distribution algorithm.

Adding new members to the team

To add NIC1 to Team1 the Windows PowerShell command is:

Add-NetLbfoTeamMember NIC1 Team1

Removing members from the team

To remove NIC1 from Team1 the Windows PowerShell command is:

Remove-NetLbfoTeamMember NIC1 Team1

Setting a team member to be the Standby Adapter

A team member can be set as the Standby Adapter through Windows PowerShell:

Set-NetLbfoTeamMember NIC4 -AdministrativeMode Standby

At most one team member may be in standby mode at any point in time. If a different team member is already in standby mode that team member must be returned to active mode before this Windows PowerShell cmdlet will succeed.

Adding new interfaces to the team

To add a new interface to the team select the Team in the Teams Tile and the Team Interfaces tab in the Adapters and Interfaces tile. Select the Tasks menu in the Adapters and Interfaces tile, then select Add Interface.

Selecting the Add Interface action item pops-up the New team interface dialog box.

Since only one team interface, the primary team interface, can be in Default mode, the new team interface must have a specific VLAN value. As the specific VLAN value is entered the name of the interface will be modified to be the team name followed by the VLAN value of this team interface. The interface name can be modified to any other name (duplicates are not allowed) if the administrator chooses to do so.

Selecting OK will create the new team interface.

The Windows PowerShell to add a team interface with VLAN 42 to Team1 is

Add-NetLbfoTeamNIC Team1 42

Modifying team interfaces

There are only two modifications that can be done to a team interface:

• change the team interface name and/or
• change the VLAN ID.

To modify the team interface VLAN ID select and then right-click the team interface in the Team Interfaces tab. Select the Properties action item.

This pops-up the Network Adapter Properties dialog box. This dialog box has some useful information about the team interface. It also has the box where the new VLAN ID can be entered. If a new VLAN ID is entered and the team name is the one the system provided when the team interface was created the team interface name will be changed to reflect the new VLAN ID. If the team interface name has been previously changed then the team name will not be changed when the new VLAN ID is entered.

To modify a team interface’s VLAN ID in Windows PowerShell

Set-NetLbfoTeamNIC “Team1 ‑ VLAN 42” -VlanID 15

Just as in the UI, changing the VLAN ID will cause the team interface name to change if the team interface name is still the same as the one the system created when the team interface was created. I.e., if the team interface name is <teamName ‑ VLAN xx> where xx is the VLAN ID of the team interface, then the VLAN ID portion of the team interface name will be modified to reflect the new VLAN ID.

Removing interfaces from the team

To delete a team interface, select and then right-click the team interface in the Team Interfaces tab. Select the Delete team interface action item. A confirmation dialog box will pop-up. Once confirmed the team interface is deleted.

The Primary team interface (i.e., the one that was created when the team was created) can’t be deleted except by deleting the team.

To delete a team interface in Windows PowerShell

Remove-NetLbfoTeamNIC “Team1 ‑ VLAN 42”

Deleting a team

To delete a team from the server select the team in the Teams tile. Right-click the team and select the Delete team action item.

A confirmation dialog box will be displayed. Once confirmed the team will be deleted.

To delete a team in Windows PowerShell

Remove-NetLbfoTeam Team1

To remove all teams from the server in Windows PowerShell (i.e., to clean up the server),

Get-NetLbfoTeam | Remove-NetLbfoTeam

Cheers,

Marcos Nogueira
http://blog.marcosnogueira.org
Twitter: @mdnoga

Creating a NIC teaming

There are two ways to invoke the New Team dialog box:

• Select the Tasks menu in the Teams tile and then select New Team, or
• Right click on an available adapter in the Network Adapters tab and select the Add to new team item. Multi-select works for this: you can select multiple adapters, right-click on one, select Add to new team, and they will all be pre-marked in the New Team dialog box.

Both of these will cause the New Team dialog box to pop-up.

When the New Team dialog box pops-up there are two actions that MUST be taken before the team can be created:

• A Team name must be provided, and
• One or more adapters must be selected to be members of the team

Optionally, the administrator may select the Additional properties item and configure the teaming mode, load distribution mode, and the name of the first (primary) team interface.

In Additional properties the Load distribution mode drop-down provides only two options: Address Hash and Hyper-V Port. The Address Hash option in the UI is the equivalent of the TransportPorts option in Windows PowerShell. To select additional Address hashing algorithms use Windows PowerShell as described below.

This is also the place where those who want to have a Standby adapter in to set the Standby adapter. Selecting the Standby adapter drop-down will give a list of the team members. The administrator can set one of them to be the Standby Adapter. A Standby adapter is not used by the team unless and until another member of the team fails. Standby adapters are only permitted in Switch Independent mode. Changing the team to any Switch Dependent mode will cause all members to be made active members.

When the team name, the team members, and optionally any additional properties (including the Primary team interface name or standby adapter) have been set to the administrator’s choices, the administrator will click on the OK button and the team will be created. Team creation may take several seconds and the NICs that are becoming team members will lose communication for a very short time.

Teams can also be created through Windows PowerShell. The Windows PowerShell to do exactly what these figures have shown is New-NetLbfoTeam Team1 NIC1,NIC2

Teams can be created with custom advanced properties.

New-NetLbfoTeam Team1 NIC1,NIC2 -TeamingMode LACP ‑LoadBalancingAlgorithm HyperVPorts

If the team is being created in a VM, you MUST follow the instructions to allow guest teaming as described in previous post (NIC teaming on Virtual Machines).

Checking the status of a team

Whenever the NIC Teaming UI is active the current status of all NICs in the team, the status of the team, and the status of the server will be shown. In the picture bellow, in the Network Adapters tab of the Adapters and Interfaces tile, NIC 3 shows as faulted. The reason given is Media Disconnected (i.e., the cable is unplugged). This causes the team, Team1, to show a Warning as it is still operational but degraded. If all the NICs in the team were faulted it would show Fault instead of Warning. The server, DONST-R710, now shows Warning. If the team was not operational the server indication would be Fault. This makes it easy to scan the list of servers to see if there are any problems.

 

Cheers,

Marcos Nogueira
http://blog.marcosnogueira.org
Twitter: @mdnoga

Update on System Center 2012 SP1 Update Rollup 2 (UR2) for Virtual Machine Manager

Yesterday Microsoft added Update Rollup 2 for System Center 2012 SP1 Virtual Machine Manager to System Center 2012 SP1 Update Rollup 2 release. 

The master KB article for  System Center 2012 SP1 Update Rollup 2 has been updated to reflect the summary of issues and installation instructions for Update Rollup 2 for System Center 2012 SP1 – VMM.  You can refer to it here. 

Important actions for Update Rollup 2 for System Center 2012 SP1- Virtual Machine Manager

In order to install Update Rollup 2 package for System Center 2012 SP1-  Virtual Machine Manager, you will need to uninstall Update Rollup 1 for System Center SP1 – Virtual Machine Manager package from your system. 

– If you download Update Rollup 2 package for System Center 2012 SP1 Virtual Machine Manager from Microsoft Update Catalog and install Update Rollup 2 without un-installing Update Rollup 1  you should un-install Update Rollup 2 package for Virtual Machine Manager and then un-install Update Rollup 1 for System Center 2012 SP1 – Virtual Machine Manager via control panel. 

– If you are using WSUS to update System Center 2012 SP1 – Virtual Machine Manager and you have already installed Update Rollup 1 for System Center 2012 SP1 – Virtual Machine Manager then you will not receive Update Rollup 2 notification until Update Rollup 1 is uninstalled.

Why is this necessary?

When Update Rollup 2 is applied to a system which is running System Center 2012 SP1 Virtual Machine Manager with UR1, the installer does not patch files correctly. This is caused by the way UR 1 was packaged. As such the product fixes in UR1 are correct; it is the packaging of UR1 that causes this issue. If you do not need UR2, then you should continue to operate with UR1.   However, if you choose to stay on Update Rollup 1 for System Center 2012 SP1 Virtual Machine Manager and a later Update Rollup is released that you need to implement you will still need to remove Update Rollup 1 first.

Cheers,

Marcos Nogueira
http://blog.marcosnogueira.org
Twitter: @mdnoga

The components of the NIC Teaming Management UI

The NIC Teaming management UI consists of 3 primary windows (tiles):

• The Servers tile
• The Teams tile
• The Adapters and Interfaces tile

The Adapters and Interfaces tile is shared by two tabs:

• The Network Adapters tab
• The Team Interfaces tab

Each tile or tab has a set of columns that can be shown or hidden. The column chooser menus are made visible by right-clicking on any column header. (For illustrative purposes the screen shot in the picture bellow shows a column chooser in every tile. Only one column chooser can be active at a time.)

Contents of any tile may be sorted by any column. To sort by a particular column left click on the column title. In the picture bellow the Servers tile is sorted by Server Name; the indication is the little triangle in the Name column title in the Servers tile.

Each tile also has a Tasks dropdown menu and a right-click context menu. The Tasks menus can be opened by clicking on the Tasks box at the top right corner of the tile and then any available task in the list can be selected. The right-click context menus are activated by right-clicking in the tile. The menu options will vary based on context. (For illustrative purposes the screen shot in the picture bellow shows all the Tasks menus and a right-click menu in every tile. Only one right-click menu or Tasks menu can be active at any time.).

In the picture bellow shows the Tasks menus and right-click menu for the Team Interfaces tab.

 

Cheers,

Marcos Nogueira
http://blog.marcosnogueira.org
Twitter: @mdnoga

Windows Server 2012 NIC Teaming tools for troubleshooting

NIC Teaming and the powerful administration tools in Windows Server 2012 are very powerful tools that can be misused, misconfigured, and may cause loss of connectivity if the administrator isn’t careful. Here are some common issues:

Using VLANs

VLANs are another powerful tool. There are a few rules for using VLANs that will help to make the combination of VLANs and NIC Teaming a very positive experience.

1) Anytime you have NIC Teaming enabled, the physical switch ports the host is connected to should be set to trunk (promiscuous) mode. The physical switch should pass all traffic to the host for filtering.

2) Anytime you have NIC Teaming enabled, you must not set VLAN filters on the NICs using the NICs advanced properties settings. Let the teaming software or the Hyper-V switch (if present) do the filtering.

VLANs in a Hyper-V host

1) In a Hyper-V host VLANs should be configured only in the Hyper-V switch, not in the NIC Teaming software. Configuring team interfaces with VLANs can easily lead to VMs that are unable to communicate on the network due to collisions with VLANs assigned in the Hyper-V switch.

VLANs in a Hyper-V VM

1) The preferred method of supporting multiple VLANs in a VM is to provide the VM multiple ports on the Hyper-V switch and associate each port with a VLAN. Never team these ports in the VM as it will certainly cause communication problems.

2) If the VM has multiple SR-IOV VFs make sure they are on the same VLAN before teaming them in the VM. It’s easily possible to configure the different VFs to be on different VLANs and, like in the previous case, it will certainly cause communication problems.

3) The only safe way to use VLANs with NIC Teaming in a guest is to team Hyper-V ports that are

a. Each connected to a different Hyper-V switch, and

b. Each configured to be associated with the same VLAN (or all associated with untagged traffic only).

c. If you must have more than one VLAN exposed into a guest OS consider renaming the ports in the guest to indicate what the VLAN is. E.g., if the first port is associated with VLAN 12 and the second port is associated with VLAN 48, rename the interface vEthernet to be vEthernetVLAN12 and the other to be vEthernetVLAN48. (Renaming interfaces is easy using the Windows PowerShell Rename-NetAdapter cmdlet or by going to the Network Connections panel in the guest and renaming the interfaces.

Interactions with other teaming solutions

Some users will want to use other NIC teaming solutions for a variety of reasons. This can be done but there are some risks that the system administrator should be aware of.

1. If the system administrator attempts to put a NIC into a 3^rd party team that is presently part of a Microsoft NIC Teaming team, the system will become unstable and communications may be lost completely.

2. If the system administrator attempts to put a NIC into a Microsoft NIC Teaming team that is presently part of a 3^rd party teaming solution team the system will become unstable and communications may be lost completely.

As a result it is STRONGLY RECOMMENDED that no system administrator ever run two teaming solutions at the same time on the same server. The teaming solutions are unaware of each other’s existence resulting in potentially serious problems.

In the event that an administrator violates these guidelines and gets into the situation described above the following steps may solve the problem.

1. Reboot the server. Forcibly power-off the server if necessary to get it to reboot.

2. When the server has rebooted run this Windows PowerShell cmdlet:

Get-NetLbfoTeam | Remove-NetLbfoTeam

3. Use the 3^rd party teaming solution’s administration tools and remove all instances of the 3^rd party teams.

4. Reboot the server again.

Microsoft continues its longstanding policy of not supporting 3^rd party teaming solutions. If a user chooses to run a 3^rd party teaming solution and then encounters networking problems, the customer should call their teaming solution provider for support. If the issue is reproducible without the 3^rd party teaming solution in place, please report the problem to Microsoft.

Disabling and Enabling with Windows PowerShell

The most common reason for a team to not be passing traffic is that the team interface is disabled. We’ve seen a number of cases where attempts to use the power of Windows PowerShell have resulted in unintended consequences. For example, the sequence:

Disable-NetAdapter *

Enable-NetAdapter *

does not enable all the netadapters that it disabled. This is because disabling all the underlying physical member NICs will cause the team interface to be removed and no longer show up in Get-NetAdapter. Thus the Enable-NetAdapter * will not enable the team NIC since that adapter has been removed. It will however enable the member NICs, which will then cause the team interface to show up. The team interface will still be in a “disabled” state since you have not enabled it. Enabling the team interface will cause traffic to begin to flow again.

Cheers,

Marcos Nogueira
http://blog.marcosnogueira.org
Twitter: @mdnoga

NIC teaming on Virtual Machines

NIC Teaming in a VM only applies to VM-NICs connected to external switches. VM-NICs connected to internal or private switches will show as disconnected when they are in a team.

NIC teaming in Windows Server 2012 may also be deployed in a VM. This allows a VM to have virtual NICs (synthetic NICs) connected to more than one Hyper-V switch and still maintain connectivity even if the physical NIC under one switch gets disconnected. This is particularly important when working with Single Root I/O Virtualization (SR-IOV) because SR-IOV traffic doesn’t go through the Hyper-V switch and thus cannot be protected by a team in or under the Hyper-V host. With the VM-teaming option an administrator can set up two Hyper-V switches, each connected to its own SR-IOV-capable NIC.

· Each VM can have a virtual function (VF) from one or both SR-IOV NICs and, in the event of a NIC disconnect, fail-over from the primary VF to the back-up adapter (VF).

· Alternately, the VM may have a VF from one NIC and a non-VF VM-NIC connected to another switch. If the NIC associated with the VF gets disconnected, the traffic can fail-over to the other switch without loss of connectivity.

Note: Because fail-over between NICs in a VM might result in traffic being sent with the MAC address of the other VM-NIC, each Hyper-V switch port associated with a VM that is using NIC Teaming must be set to allow teaming There are two ways to enable NIC Teaming in the VM:

1) In the Hyper-V Manager, in the settings for the VM, select the VM’s NIC and the Advanced Settings item, then enable the checkbox for NIC Teaming in the VM.

2) Run the following Windows PowerShell cmdlet in the host with elevated (Administrator) privileges.

Set-VMNetworkAdapter -VMName <VMname> -AllowTeaming On

Teams created in a VM can only run in Switch Independent configuration, Address Hash distribution mode (or one of the specific address hashing modes). Only teams where each of the team members is connected to a different external Hyper-V switch are supported.

Teaming in the VM does not affect Live Migration. The same rules exist for Live Migration whether or not NIC teaming is present in the VM.

No teaming of Hyper-V ports in the Host Partition

Hyper-V virtual NICs exposed in the host partition (vNICs) must not be placed in a team. Teaming of virtual NIC’s (vNICs) inside of the host partition is not supported in any configuration or combination. Attempts to team vNICs may result in a complete loss of communication in the event that network failures occur.

Feature compatibilities

NIC teaming is compatible with all networking capabilities in Windows Server 2012 with five exceptions: SR-IOV, RDMA, Native host Quality of Service, TCP Chimney, and 802.1X Authentication.

· For SR-IOV and RDMA, data is delivered directly to the NIC without passing it through the networking stack (in the host OS in the case of virtualization). Therefore, it is not possible for the team to look at or redirect the data to another path in the team.

· When QoS policies are set on a native or host system and those policies invoke minimum bandwidth limitations, the overall throughput through a NIC team will be less than it would be without the bandwidth policies in place.

· TCP Chimney is not supported with NIC teaming in Windows Server 2012 since TCP Chimney has the entire networking stack offloaded to the NIC.

· 802.1X Authentication should not be used with NIC Teaming and some switches will not permit configuration of both 802.1X Authentication and NIC Teaming on the same port.

Feature	Comments
Datacenter bridging (DCB)	Works independent of NIC Teaming so is supported if the team members support it.
IPsec Task Offload (IPsecTO)	Supported if all team members support it.
Large Send Offload (LSO)	Supported if all team members support it.
Receive side coalescing (RSC)	Supported in hosts if any of the team members support it. Not supported through Hyper-V switches.
Receive side scaling (RSS)	NIC teaming supports RSS in the host. The Windows Server 2012 TCP/IP stack programs the RSS information directly to the Team members.
Receive-side Checksum offloads (IPv4, IPv6, TCP)	Supported if any of the team members support it.
Remote Direct Memory Access (RDMA)	Since RDMA data bypasses the Windows Server 2012 protocol stack, team members will not also support RDMA.
Single root I/O virtualization (SR-IOV)	Since SR-IOV data bypasses the host OS stack, NICs exposing the SR-IOV feature will no longer expose the feature while a member of a team. Teams can be created in VMs to team SR-IOV virtual functions (VFs).
TCP Chimney Offload	Not supported through a Windows Server 2012 team.
Transmit-side Checksum offloads (IPv4, IPv6, TCP)	Supported if all team members support it.
Virtual Machine Queues (VMQ)	Supported when teaming is installed under the Hyper-V switch.
QoS in host/native OSs	Use of minimum bandwidth policies will degrade throughput through a team.
Virtual Machine QoS (VM-QoS)	VM-QoS is affected by the load distribution algorithm used by NIC Teaming. For best results use HyperVPorts load distribution mode.
802.1X authentication	Not compatible with many switches. Should not be used with NIC Teaming.

NIC Teaming and Virtual Machine Queues (VMQs)

VMQ and NIC Teaming work well together; VMQ should be enabled anytime Hyper-V is enabled. Depending on the switch configuration mode and the load distribution algorithm, NIC teaming will either present VMQ capabilities to the Hyper-V switch that show the number of queues available to be the smallest number of queues supported by any adapter in the team (Min-queues mode) or the total number of queues available across all team members (Sum-of-Queues mode). Specifically,

· if the team is in Switch-Independent teaming mode and the Load Distribution is set to Hyper-V Port mode, then the number of queues reported is the sum of all the queues available from the team members (Sum-of-Queues mode);

· Otherwise the number of queues reported is the smallest number of queues supported by any member of the team (Min-Queues mode).

Here’s why.

· When the team is in switch independent/Hyper-V Port mode the inbound traffic for a VM will always arrive on the same team member. The host can predict which member will receive the traffic for a particular VM so NIC Teaming can be more thoughtful about which VMQ Queues to allocate on a particular team member. NIC Teaming, working with the Hyper-V switch, will set the VMQ for a VM on exactly one team member and know that inbound traffic will hit that queue.

· When the team is in any switch dependent mode (static teaming or LACP teaming), the switch that the team is connected to controls the inbound traffic distribution. The host’s NIC Teaming software can’t predict which team member will get the inbound traffic for a VM and it may be that the switch distributes the traffic for a VM across all team members. As a result the NIC Teaming software, working with the Hyper-V switch, programs a queue for the VM on every team member, not just one team member.

· When the team is in switch-independent mode and is using an address hash load distribution algorithm, the inbound traffic will always come in on one NIC (the primary team member) – all of it on just one team member. Since other team members aren’t dealing with inbound traffic they get programmed with the same queues as the primary member so that if the primary member fails any other team member can be used to pick up the inbound traffic and the queues are already in place.

There are a few settings that will help the system perform even better.

Each NIC has, in its advanced properties, values for *RssBaseProcNumber and *MaxRssProcessors.

· Ideally each NIC should have the *RssBaseProcNumber set to an even number greater than or equal to two (2). This is because the first physical processor, Core 0 (logical processors 0 and 1), typically does most of the system processing so the network processing should be steered away from this physical processor. (Some machine architectures don’t have two logical processors per physical processor so for such machines the base processor should be greater than or equal to 1. If in doubt assume your host is using a 2 logical processor per physical processor architecture.)

· If the team is in Sum-of-Queues mode the team members’ processors should be, to the extent possible, non-overlapping. For example, in a 4-core host (8 logical processors) with a team of 2 10Gbps NICs, you could set the first one to use base processor of 2 and to use 4 cores; the second would be set to use base processor 6 and use 2 cores.

· If the team is in Min-Queues mode the processor sets used by the team members must be identical.

Cheers,

Marcos Nogueira
http://blog.marcosnogueira.org
Twitter: @mdnoga

Management Tasks for Hyper-V Replica

The Hyper-V Manager interface is used to manage standalone Hyper-V Primary, Replica servers, and the virtualized workloads running on those servers.   The Failover Cluster Manager interface is used if the Primary or Replica servers are part of a Hyper-V Failover Cluster. Hyper-V Replica management tasks can be categorized as follows:

• Hyper-V Server Primary Site Management Tasks
• Hyper-V Server Replica Site Management Tasks
• Virtual Machine Primary Site Management Tasks
• Virtual Machine Replica Site Management Tasks
• Modifying Virtual Machine Replication Settings

Note: In the above list, Hyper-V Failover Cluster can be substituted for ‘Hyper-V Server’.

Hyper-V Server Primary Site

Management tasks involving the Hyper-V Server at a Primary Site include:

Ensure the Hyper-V server (Hyper-V Failover Cluster) at the Primary site is configured as a Replica server to support Reverse Replication for a Planned Failover event

To configure the Hyper-V server at the Primary site as a Replica server:

1. In the Hyper-V Manager interface, Click on Hyper-V Settings in the Actions pane
2. In the Hyper-V Settings dialog box, Click on Replication Configuration
3. In the Details pane, Select Enable this computer as a Replica server
4. Choose an Authentication method to include the port that will be used (if not using the default port)
5. Configure Authorization and storage.  This includes designating a specific location to store replica virtual machine files if the default location is not to be used.  Should you not desire to allow all Hyper-V Primary servers to be serviced, you have the option to allow only specific Hyper-V servers (Primary servers) to send replication requests. Click Apply or OK when finished

Note:  In a Replica cluster, use the Hyper-V Replica Broker role to configure the cluster nodes for replication.

Monitor the Replication Health of virtual machines configured for replication

To monitor the Replication Health of a virtual machine configured for replication:

1. Open Hyper-V Manager
2. In the details pane, Right-click on one of the Column Headings and select Add\Remove Columns
3. Choose Replication Health in the Available Columns list, click Add to move it to the Displayed Columns list
4. Move the new column to the desired location in the listing and click OK

Monitor Hyper-V Replica specific Performance counters using Performance Monitor

To monitor Hyper-V Replica performance:

1. Click the Start button,  then click Run and type perfmon.msc and press ENTER
2. In the navigation tree, expand Monitoring Tools, and then click Performance Monitor
3. In the menu bar above the Performance Monitor graph display, either click the Add button (+) or right-click anywhere in the graph and click Add counters from the menu. The Add Counters dialog box opens
4. In the Available Counters section, select counters to view in the Performance Monitor display.  The counters for Hyper-V Replica are virtual machine specific and are listed under Hyper-V F Counter VM
5. Choose the desired counters and instances (virtual machines) then click the Add button to add the counters
6. When finished, click OK

For more information Performance Monitor, visit the Performance Monitor Getting Started Guide.

Evaluate Hyper-V Replica log data using the Microsoft-Windows-Hyper-V-VMMS\Admin log

To review Hyper-V Replica log data:

1.  In the Server Manager Menu Bar, Click on Tools and choose Event Viewer from the list
2. In the navigation tree, expand Application and Services Logs,  expand Microsoft, expand Windows, expand Hyper-V-VMMS
3. Click on Admin 

   Hyper-V Replica event messages are registered in the Hyper-V-VMMS channel.

Hyper-V Server Replica Site

Management tasks involving the Hyper-V Server at a Replica Site include:

Ensure the Hyper-V server (Hyper-V Failover Cluster) at the Replica site is configured as a Replica server

To configure the Hyper-V server at the Primary site as a Replica server:

1. In the Hyper-V Manager interface, Click on Hyper-V Settings in the Actions pane
2. In the Hyper-V Settings dialog box, Click on Replication Configuration
3. In the Details pane, Select Enable this computer as a Replica server
4. Choose an Authentication method to include the port that will be used (if not using the default port)
5. Configure Authorization and storage.  This includes designating a specific location to store replica virtual machine files if the default location is not to be used.  Should you not desire to allow all Hyper-V Primary servers to be serviced, you have the option to allow only specific Hyper-V servers (Primary servers) to send replication requests. Click Apply or OK when finished

Note:  In a Replica cluster, use the Hyper-V Replica Broker role to configure the cluster nodes for replication.

Monitor the Replication Health of virtual machines configured for replication

To monitor the Replication Health of a virtual machine configured for replication:

1. Open Hyper-V Manager
2. In the details pane, Right-click on one of the Column Headings and select Add\Remove Columns
3. Choose Replication Health in the Available Columns list, click Add to move it to the Displayed Columns list
4. Move the new column to the desired location in the listing and click OK

Monitor Hyper-V Replica specific Performance counters using Performance Monitor

To monitor Hyper-V Replica performance:

1. Click the Start button,  then click Run and type perfmon.msc and press ENTER
2. In the navigation tree, expand Monitoring Tools, and then click Performance Monitor
3. In the menu bar above the Performance Monitor graph display, either click the Add button (+) or right-click anywhere in the graph and click Add counters from the menu. The Add Counters dialog box opens
4. In the Available Counters section, select counters to view in the Performance Monitor display.  The counters for Hyper-V Replica are virtual machine specific and are listed under Hyper-V Replica  Counter VM
5. Choose the desired counters and instances (virtual machines) then click the Add button to add the counters
6. When finished, click OK

For more information Performance Monitor, visit the Performance Monitor Getting Started Guide.

Evaluate Hyper-V Replica log data using the Microsoft-Windows-Hyper-V-VMMS\Admin log

To review Hyper-V Replica log data:

1. In the Server Manager Menu Bar, Click on Tools and choose Event Viewer from the list
2. In the navigation tree, expand Application and Services Logs,  expand Microsoft, expand Windows, expand Hyper-V-VMMS
3. Click on Admin

Hyper-V Replica event messages are registered in the Hyper-V-VMMS channel.

Virtual Machine – Primary Site

Management tasks involving virtual machines at the Primary Site include:

Planned Failover – This action initiates a failover of a virtual machine from a Primary to a Replica server.  This is a ‘planned’ event as opposed to a Failover action, which is unplanned.  Since it is a ‘planned’ event, there should be no data loss.  This action executes a series of checks prior to executing the failover.  One check determines if the Primary server has also been configured as a Replica server.  This is done because the assumptions are first, the virtual machine being failed over to a Replica server will eventually be moved back to the Primary server and second, the Primary server will become the Replica server for the virtual machine that is being failed over.  This action provides an Administrator the flexibility to execute the failover of a virtual machine to a replica server in a controlled manner before a disaster occurs

To execute a Planned Failover for a virtual machine:

1. Open Hyper-V Manager
2. In the details pane, select a virtual machine
3. With the virtual machine selected, Right-click and select Replication and then choose Planned Failover
4. A list of Pre-Requisites and Actions is presented.  If the Virtual Machine has not been shut down and the Primary Server not configured as a Replica Server, complete those tasks before proceeding. By default, Start the replica virtual machine after Failover is checked (uncheck if this is not the desired action for the virtual machine after a Planned Failover completes)
5. Click on the Failover button.
6. If the Failover is successful, a pop-up dialog box appears reporting the Failover completed successfully (Note: If the option to start the virtual machine after the Planned Failover was left checked, then the virtual machine will be started on the Replica server).  Close the dialog box.
7. If the Planned Failover does not complete successfully, review the information contained in the General Methodology for troubleshooting the virtual machine Failover process in the troubleshooting section.

Pause Replication – This action pauses replication for the selected virtual machine.  The Replication Health column in the Hyper-V Manager interface (if selected for display) reflects a Warning Status

To Pause Replication for a virtual machine:

1. Open Hyper-V Manager
2. In the details pane, select a virtual machine that is not paused
3. With the virtual machine selected, Right-click and select Replication and then choose Pause Replication
4. The Replication Health, if visible, in Hyper-V Manager, will be updated and the Replication Health for the virtual machine will indicate a Warning.  The State column still shows the Virtual Machine as Running
5. Right-click on the Virtual Machine, select Replication and then click on View Replication Health.  The health report reflects an accurate Replication State which should be Replication Paused

Resume Replication (Available only if replication has been paused for a virtual machine) – This action resumes replication for the selected virtual machine (the action must be executed in the same site where replication was Paused).  The Hyper-V Replica Network Services component re-establishes a connection to the Replica server (if needed) and replication resumes.  If the virtual machine was in a Resynch Required state, Resume Replication performs a resynchronization.  A resynchronization essentially compares blocks between the Primary and Replica VHDs and then sends the delta blocks to the Replica. Scenarios where this can happen include, but may not be limited to, a failure occurred on the Primary server when changes were being made to the replication log or, if the Primary is a Failover Cluster, an unplanned cluster failover occurred.  The Replication Health column in Hyper-V Manager interface (if selected for display) reflects a status of Normal

To Resume Replication for a virtual machine:

1. Open Hyper-V Manager
2. In the details pane, select a paused virtual machine
3. With the virtual machine selected, Right-click and select Replication and then choose Resume Replication
4. The Replication Health, if visible, in Hyper-V Manager, is updated and the Replication Health for the virtual machine is Normal

View Replication Health – This action provides data about the replication events for a virtual machine.

A Replication Health Report can be saved as a CSV file.  A Replication Health Report indicates if it is being viewed as either a Primary or a Replica virtual machine (see a sample of a Replication Health Report on a Replica virtual machine later in this guide)

To view Replication Health for a virtual machine:

1. Open Hyper-V Manager
2. In the details pane, select a virtual machine
3. With the virtual machine selected, Right-click and select Replication and then choose View Replication Health
4. The Replication Health Report for the virtual machine is displayed. The report can be saved as a CSV file by clicking on Save as … Button

Remove Replication – This action stops replication for the virtual machine.  All connections for the virtual machine to the Replica server are terminated.  The Replication Health in Hyper-V Manager on the Primary server, if selected for viewing, is Not Applicable.  A corresponding action must be accomplished on the Replica server.  Failure to execute this same action on the Replica server will result in errors should a Hyper-V Administrator attempt to re-enable replication for the virtual machine (more information is provided in the Troubleshooting section)

To Remove Replication for a virtual machine:

1. Open Hyper-V Manager
2. In the details pane, select a virtual machine
3. With the virtual machine selected,  Right-click and select Replication and choose Remove Replication
4. Acknowledge the pop-up Warning by clicking on Remove Replication
5. The Replication Health column, if displayed, indicates Not Applicable for the virtual machine
6. Connect to the Replica server and execute Steps 1-5.  This will remove replication for the virtual machine on the Replica server and will initiate a merge for all the replica information for the virtual machine
7. The Replication Health column, if displayed, indicates Not Applicable for the virtual machine
8. Additional cleanup action is required on the Replica server.  In Hyper-V Manager, Right-click on the virtual machine and choose Delete.  Acknowledge the pop-up Warning by clicking on Delete.  This removes the virtual machine reference in Hyper-V Manager.  Some data files remain on the Replica server in the storage location specified for the replication data.  To recover storage space, manually remove the data.

Enable Replication (Available only if replication is not enabled for a virtual machine) – This action enables replication for a virtual machine

To Enable Replication for a virtual machine:

1. Open Hyper-V Manager
2. In the details pane, select a virtual machine
3. With the virtual machine selected,  Right-click and select Enable Replication
4. Review the information in the Before You Begin screen and click Next
5. In the Specify Replica Server screen, provide the name for the Replica Server using the Fully Qualified Domain Name (FQDN) or NetBIOS format.   There is also the option to Browse Active Directory for the server.  If the Replica Server is configured correctly, the Specify Connection Parameters screen is populated.  If not, an error is registered and an option to Configure Server is available to configure the server to be a Replica Server. If data compression is not desired, Uncheck the box Compress the data that is transmitted over the network. Click Next
6. In the Choose Replication VHDs screen, ensure all disks to be replicated are Checked and then click Next (i.e. uncheck those disk you do not want replicated.  An example might be a disk functioning as a repository for the virtual machine page file)
7. In the Configure Recovery History screen, select as desired. For an explanation of the options, review the section on Enabling a virtual machine for replication.  Click Next
8. In the Choose Initial Replication Method screen, select as desired. For an explanation of the options, review the section on Enabling a virtual machine for replication.  Click Next
9. Review the information in the Summary screen, and click Finish

Once replication has been enabled for a virtual machine, the Replication Health column, if visible, in Hyper-V Manager will be updated.  Once the Initial Replication (IR) has been completed, the Replication Health for a virtual machine will be Normal.

Virtual Machine – Replica Site

Management tasks involving virtual machines at the Replica Site include:

Failover – This action executes a process that starts a virtual machine on the Replica server using a replica (Recovery Point) selected by the Hyper-V Administrator.  This is an unplanned event unlike the Planned Failover action, which is a planned event.  Executing a Failover for a virtual machine could result in data loss depending on which recovery point is selected

To Failover a virtual machine:

1. Open Hyper-V Manager
2. In the details pane, select a virtual machine
3. With the virtual machine selected,  Right-click and select Replication and then choose Failover
4. In the next screen, choose a recovery point from the drop-down listing of all the recovery points associated with the virtual machine and then click Failover
5. The virtual machine starts and the Replication Health indicates Warning.  If the Primary server remains the same, the Replication Health for the virtual machine that was recovered is also Warning. To complete the process and remove the Warnings, either Cancel Failover or configure Reverse Replication and allow Initial Replication to complete.  If a new Replica Server is needed, configure Reverse Replication to the new Replica server.

Test Failover – This action allows a Hyper-V Administrator to test a virtual machine on the Replica server without interrupting the production workload running on the Primary server.  The network configuration for the test virtual machine is disconnected by default so as not to interfere with the production workload. If network connectivity is to be tested, the recommendation is to create a separate test network and connect the test virtual machine to that network. The virtual machine created and started has the same name as the original virtual machine with a modifier of Test added on to the end

To start a Test Failover for a virtual machine:

1. Open Hyper-V Manager
2. In the details pane, select a virtual machine
3. With the virtual machine selected,  Right-click and select Replication and then choose Test Failover
4. In the next screen, choose a recovery point from the drop-down listing of all the recovery points associated with the virtual machine and then click Test Failover.  A new test virtual machine is created but is not started.  At this point, the virtual machine can be started and then a connection can be made to the virtual machine and a verification process can be completed

Stop Test Failover (Available only if a test is already running for the selected virtual machine) – This action stops a test that is in progress for the selected virtual machine.  The virtual machine is stopped and deleted from Hyper-V Manager (Note:  If the Test Failover is being executed on a Replica cluster, the Test-Failover role that is created in Failover cluster Manager will have to be manually deleted)

To stop a Test Failover for a virtual machine:

1. Open Hyper-V Manager
2. In the details pane, select the virtual machine being tested, not the test virtual machine that is running. Right-click on the virtual machine, select Replication and then choose Stop Test Failover
3. The test virtual machine is stopped if it is running and is removed from Hyper-V Manager as the test is completed

Pause Replication – This action pauses replication for the selected virtual machine.  The Replication Health column in Hyper-V Manager, if selected for viewing, indicates a Warning

To Pause Replication for a virtual machine:

1. Open Hyper-V Manager
2. In the details pane, select a virtual machine that is not paused
3. With the virtual machine selected, Right-click and select Replication and then choose Pause Replication
4. The Replication Health, if visible, in Hyper-V Manager, is updated and indicates a Warning

Resume Replication (Available only if replication has been paused for a virtual machine on the Replica server) – This action resumes replication for the selected virtual machine.  If a ‘resynch’ is required for the virtual machine, that action will be initiated on the Primary server.  The Replication State column, if selected for viewing in Hyper-V Manager, indicates Replication Enabled

To Resume Replication for a virtual machine:

1. Open Hyper-V Manager
2. In the details pane, select a paused virtual machine
3. With the virtual machine selected, Right-click and select Replication and then choose Resume Replication
4. The Replication Health, if visible, in Hyper-V Manager, is updated and indicates Normal

View Replication Health – This action provides data about the replication events for a virtual machine.

A Replication Health Report can be saved as a CSV file.  A Replication Health Report indicates if it is being viewed on either a Primary or a Replica server

To View Replication Health for a virtual machine:

1. Open Hyper-V Manager
2. In the details pane, select a virtual machine
3. With the virtual machine selected, Right-click and select Replication and then choose View Replication Health
4. The Replication Health Report for the virtual machine is displayed. The report can be saved as a CSV file by clicking on Save as…

Remove Replication – If a Remove Replication action is executed on the Replica server, a corresponding action must be executed on the Primary Server. This action stops replication for the virtual machine.  Prior to re-enabling replication, the virtual machine must be deleted in Hyper-V Manager on the Replica server.  This destroys the virtual machine on the Replica Server.  If the virtual machine is not deleted, a Replication error is reflected in Hyper-V Manager and associated error logs are registered (more information is provided in the Troubleshooting section)

To Remove Replication for a virtual machine:

1. Open Hyper-V Manager
2. In the details pane, select a virtual machine
3. With the virtual machine selected,  Right-click and select Replication and then choose Remove Replication
4. Acknowledge the pop-up Warning by clicking on Remove Replication
5. The Replication Health column, if displayed, indicates Not Applicable
6. A process will start to merge all recovery point data into the VHD that was initially replicated
7. Connect to the Primary server.  In Hyper-V Manager, the virtual machine Replication Health indicates Normal
8. Execute Steps 1-5.  This removes replication for the virtual machine on the Primary server
9. The Replication Health column, if displayed, now indicates Not Applicable on the Primary server.  If Step 8 is not accomplished before the next 5 minute replication interval, Replication Health will indicate Critical
10. Additional cleanup action is required on the Replica server.  In Hyper-V Manager, Right-click on the virtual machine and choose Delete.  Acknowledge the pop-up Warning by clicking on Delete.  This removes the virtual machine reference in Hyper-V Manager.  Some data files remain on the Replica server in the storage location specified for the virtual machine.  To recover storage space, manually remove this data

Cancel Failover – This action is available if a Failover action was executed for a virtual machine.  This allows a Hyper-V Administrator to cancel the Failover action if, for example, he decides the recovery point chosen was not the desired one.  After cancelling the Failover, another recovery point can be selected and another Failover process initiated. A Failover can only be cancelled if the virtual machine state is Failed over – Waiting Completion.  If a Reverse Replication has been completed, the Failover can no longer be cancelled

To Cancel Failover for a virtual machine:

1. Open Hyper-V Manager
2. In the details pane, select a virtual machine that has a Replication Health of Warning but viewing the Health Report shows Failover Complete
3. With the virtual machine selected,  Right-click, select Replication and then choose Cancel Failover
4. Acknowledge the pop-up Warning by clicking on Yes.  On the Replica server, the virtual machine is turned off and the Replication Health indicates Normal.  On the Primary server, the Replication Health shows Critical.
5. To clear the Critical health state,  right-click on the virtual machine and select Replication and then choose Resume Replication

Reverse Replication – This action is available if a Failover action was executed for a virtual machine.  This allows the Hyper-V Administrator to designate a Hyper-V server as a Replica server for the virtual machine that was recovered

To enable Reverse Replication for a virtual machine:

1. Open Hyper-V Manager
2. In the details pane, select a virtual machine that has a Health of Warning
3. With the virtual machine selected, Right-click, select Replication, and then choose Remove Recovery Points.   This merges all the recovery points into the original VHD.  This completes Failover but Replication Health still indicates Warning
4. With the virtual machine selected, Right-click, select Reverse Replication
5. Complete the Reverse Replication wizard by either selecting the Primary server (the default) as the Replica y server or choosing another Replica server.  Keep in mind that if the selected Hyper-V server has not been enabled as a Replica server and the appropriate firewall rule enabled, the Reverse Replication process will fail

Remove Recovery Points – This action is available only during a Failover scenario.  When this action is executed, all recovery points (snapshots) for a Replica virtual machine are deleted.  When the action is executed, a pop-up dialog box is presented to the user indicating all recovery points will be removed and Cancel Failover will no longer be available.  The user must acknowledge the pop-up by clicking either Yes or No.  If Yes is selected, the Failover is committed and the recovery points are merged down into the base VHD for the virtual machine.  At this point Reverse Replication can be configured to clear the Warning for Replication Health and an Initial Replication can begin to the new Replica Server

Troubleshooting Hyper-V Replica

Introduction to Troubleshooting Hyper-V Replica

This section explains how to troubleshoot Hyper-V Replica.  Use this guide when:

• You have problems with connectivity between Primary and Replica servers
• You have problems enabling a virtual machine for replication
• You have problems with virtual machine replication whether it is Initial Replication (IR) or Delta Replication (DR)
• You have problems executing management actions associated with virtual machines on a Primary or Replica server
• You have problems with the Replication Broker configured in a Hyper-V Failover Cluster.
• You need to collect Performance monitoring data for replicated virtual machines.

Tools for Troubleshooting Hyper-V Replica

Utilities and Commands for Troubleshooting Hyper-V Replica

Performance Monitor

Performance Monitor contains Hyper-V counters specific to Hyper-V Replica.  These counters monitor replication statistics for configured virtual machines.  The specific counter is Hyper-V Failover Replication Counter VM.  The data that can be collected for each selected virtual machine includes:

• Average Replication Latency
• Average Replication Size
• Last Replication Size
• Network Bytes Received
• Network Bytes Sent
• Replication Count
• Replication Latency
• Resynchronized Bytes

Hyper-V Replica Integration into the Hyper-V Best Practice Analyzer (BPA)

Rules pertaining to Hyper-V Replica are included in the Hyper-V Best Practice Analyzer. The following BPA Rule details are provided to assist with troubleshooting:

Summary	Detail
Rule Title	A Replica server must be configured to accept replication requests
Severity	Red
Category	Configuration
Issue	This computer is designated as a Hyper-V Replica server but is not configured to accept incoming replication data from primary servers.
Impact	This server cannot accept replication traffic from primary servers.
Resolution	Use Hyper-V Manager to specify which primary servers this Replica server should accept replication data from.
Summary	Detail
Rule Title	Replica servers should be configured to identify specific primary servers authorized to send replication traffic
Severity	Yellow
Category	Configuration
Issue	As configured, this Replica server accepts replication traffic from all primary servers and stores them in a single location.
Impact	All replication from all primary servers is stored in one location, which might introduce privacy or security problems.
Resolution	Use Hyper-V Manager to create new authorization entries for the specific primary servers and specify separate storage locations for each of them. You can use wildcard characters to group primary servers into sets for each authorization entry.
Summary	Detail
Rule Title	Compression is recommended for replication traffic
Severity	Yellow
Category	Configuration
Issue	The replication traffic sent across the network from the primary server to the Replica server is uncompressed.
Impact	Replication traffic will use more bandwidth than necessary. This impacts the following virtual machines:<List of VMs>
Resolution	Configure Hyper-V Replica to compress the data transmitted over the network in the settings for the virtual machine in Hyper-V Manager. You can also use tools outside of Hyper-V to perform compression.
Summary	Detail
Rule Title	Configure guest operating systems for VSS-based backups to enable application-consistent snapshots for Hyper-V Replica
Severity	Red
Category	Configuration
Issue	Application-consistent snapshots require that Volume Shadow Copy Services (VSS) is enabled and configured in the guest operating systems of virtual machines participating in replication.
Impact	Even if application-consistent snapshots are specified in the replication configuration, Hyper-V will not use them unless VSS is configured. This impacts the following virtual machines:<List of VMs>
Resolution	Use Hyper-V Manager to install integration services in the virtual machine.
Summary	Detail
Rule Title	Integration services must be installed before primary or Replica virtual machines can use an alternate IP address after a failover
Severity	Red
Category	Configuration
Issue	Virtual machines participating in replication can be configured to use a specific IP address in the event of failover, but only if integration services are installed in the guest operating system of the virtual machine.
Impact	In the event of a failover (planned, unplanned, or test), the Replica virtual machine will come online using the same IP address as the primary virtual machine. This configuration might cause connectivity issues. This impacts the following virtual machines:<List of VMs>
Resolution	Use Hyper-V Manager to install integration services in the virtual machine.
Summary	Detail
Rule Title	To participate in replication, servers in failover clusters must have a Hyper-V Replica Broker configured
Severity	Red
Category	Configuration
Issue	For failover clusters, Hyper-V Replica requires the use of a Hyper-V Replica Broker name instead of an individual server name.
Impact	If the virtual machine is moved to a different failover cluster node, replication cannot continue.
Resolution	Use Failover Cluster Manager to configure the Hyper-V Replica Broker. In Hyper-V Manager, ensure that the replication configuration uses the Hyper-V Replica Broker name as the server name.
Summary	Detail
Rule Title	Virtual hard disks with paging files should be excluded from replication
Severity	Yellow
Category	Configuration
Issue	Paging files should be excluded from participating in replication, but no disks have been excluded.
Impact	Virtual hard disks that experience a high volume of input/output activity will unnecessarily require much greater resources to participate in replication. This impacts the following virtual machines:\n{0}
Resolution	If you have not already done so, create a separate virtual hard disk for the Windows paging file. If initial replication has already been completed, use Hyper-V Manager to remove replication. Then, configure replication again and exclude the virtual hard disk with the paging file from replication.
Summary	Detail
Rule Title	Configure the Failover TCP/IP settings that you want the Replica virtual machine to use in the event of a failover
Severity	Yellow
Category	Configuration
Issue	Replica virtual machines configured with a static IP address should be configured to use a different IP address from their primary virtual machine counterpart in the event of failover.
Impact	Clients using the workload supported by the primary virtual machine might not be able to connect to the Replica virtual machine after a failover. Also, the primary virtual machine’s original IP address will not be valid in the Replica virtual machine network topology.
Resolution	Use Hyper-V Manager to configure the IP address that the Replica virtual machine should use in the event of failover. This impacts the following virtual machine(s): <List of VMs>
Summary	Detail
Rule Title	Authorization entries should have distinct tags for primary servers with virtual machines that are not part of the same security group.
Severity	Yellow
Category	Configuration
Issue	The server will accept replication requests for the replica virtual machine from any of the servers in the authorization list associated with the same replication tag as of the VM.
Impact	There might be privacy and security concerns with a virtual machine accepting replication from primary servers belonging to different authorization entries. This impacts the following authorization entries:<List of VMs>
Resolution	Use different tags in the authorization entries for primary servers with virtual machines that are not part of the same security group. Modify the Hyper-V settings to configure the replication tags.
Summary	Detail
Rule Title	Certificate-based authentication is configured, but the specified certificate is not installed on the Replica server or failover cluster nodes
Severity	Red
Category	Configuration
Issue	The security certificate that Hyper-V Replica has been configured to use to provide certificate-based replication is not installed on the Replica server (or any failover cluster nodes).
Impact	In the event of a cluster failover or move to another node, Hyper-V replication will pause if the new node does not also have the appropriate certificate installed. This impacts the following nodes: <List of nodes>
Resolution	Install the configured certificate on the Replica server (and all associated nodes in the failover cluster, if any).
Summary	Detail
Rule Title	Replication is paused for one or more virtual machines on this server
Severity	Yellow
Category	Operation
Issue	Replication is paused for one or more of the virtual machines. While the primary virtual machine is paused, any changes that occur will be accumulated and will be sent to the Replica virtual machine once replication is resumed.
Impact	As long as replication is paused, accumulated changes occurring in the primary virtual machine will consume available disk space on the primary server. After replication is resumed, there might be a large burst of network traffic to the Replica server. This impacts the following virtual machines: <List of VMs>
Resolution	Confirm that pausing replication was intended. If replication was paused to address low disk space or network connectivity, resume replication as soon as those issues are resolved.
Summary	Detail
Rule Title	Initial replication is complete, but no test failover has been attempted
Severity	Red
Category	Operation
Issue	No test failovers have been attempted since completing initial replication.
Impact	A test failover confirms that failover will succeed and that all workload operations on the primary virtual machine continue properly after failover to the Replica virtual machine. This impacts the following virtual machines: <List of VMs>
Resolution	Use Hyper-V Manager to conduct a test failover.
Summary	Detail
Rule Title	There has been no test failover in at least one month
Severity	Yellow
Category	Operation
Issue	Test failovers should be carried out at least monthly to verify that failover will succeed and that virtual machine workloads will operate as expected after failover.
Impact	A test failover confirms that failover will succeed and that all workload operations on the primary virtual machine continue properly after failover to the Replica virtual machine. This impacts the following virtual machines: <List of VMs>
Resolution	Use Hyper-V Manager to conduct a test failover.
Summary	Detail
Rule Title	Certificate-based authentication is recommended for replication.
Severity	Yellow
Category	Configuration
Issue	One or more virtual machines selected for replication are configured for Kerberos authentication.
Impact	The replication network traffic from the primary server to the replication server is unencrypted. This impacts the following virtual machines:<List of VMs>
Resolution	If another method is being used to perform encryption, you can ignore this. Otherwise, modify the virtual machine settings to choose certificate-based authentication.
Summary	Detail
Rule Title	Configure a policy to throttle the replication traffic on the network
Severity	Yellow
Category	Configuration
Issue	There might not be a limit on the amount of network bandwidth that replication is allowed to consume.
Impact	Network bandwidth could become completely dominated by replication traffic, affecting other critical network activity. This impacts the following ports: <List of Ports>
Resolution	If you use another method to throttle network traffic, you can ignore this. Otherwise, use Group Policy Editor to configure a policy that will throttle the network traffic to the relevant port of the Replica server.
Summary	Detail
Rule Title	Resynchronization of replication should be scheduled for off-peak hours.
Severity	Yellow
Category	Configuration
Issue	Resynchronization of replication for the primary VMs is not scheduled for off-peak hours.
Impact	Replication logs and Replication Point Objective will increase when the VM is in a resynchronize-required state for a longer time. At the same time, resynchronization will affect the IOPS bandwidth on the primary and the replica server, hence might affect production workloads.
Resolution	Use Hyper-V Manager VM Replication settings to configure the auto-resynchronize replication window of the primary VM within the off-peak hours.
Summary	Detail
Rule Title	VHDX-based virtual hard disks are recommended for virtual machines that have recovery history enabled in replication settings.
Severity	Yellow
Category	Configuration
Issue	VHD-based virtual hard disks are being used for the virtual machines that are enabled for replication with recovery history turned on.
Impact	Under some circumstances, the VHDs on the replica server could experience consistency issues. This impacts the following virtual machine(s): <List of VMs>
Resolution	Use the new virtual hard disk format (VHDX) for the virtual machines that are enabled for replication with recovery history turned on. You can convert a virtual hard disk from VHD format to VHDX format. The VHDX format has reliability mechanisms that help protect the disk from corruptions due to system power failures. However, do not convert the virtual hard disk if it is likely to be attached to an earlier release of Windows at some point. Windows releases earlier than {1} do not support the VHDX format.
Summary	Detail
Rule Title	Recovery snapshots should be removed after failover.
Severity	Yellow
Category	Operation
Issue	A failed over virtual machine has one or more recovery snapshots.
Impact	Available space may run out on the physical disk that stores the snapshot files. If this occurs, no additional disk operations can be performed on the physical storage. Any virtual machine that relies on the physical storage could be affected. This impacts the following virtual machines: <List of VMs>
Resolution	For each failed over virtual machine, use the Complete-VMFailover cmdlet in Windows PowerShell to remove the recovery snapshots and indicate Failover completion.
Summary	Detail
Rule Title	A large number of recovery points has been configured
Severity	Yellow
Category	Configuration
Issue	Hyper-V Replica has been configured to store more than nine previous recovery points.
Impact	Maintaining too many recovery points could cause the Replica server to run out of available disk space. This impacts the following virtual machines: <List of VMs>
Resolution	Review the number of recovery points configured, taking into account factors such as the number of virtual machines on the server and the oldest recovery point that is really required.