Microsoft Hyper-V Deployment Technical Notes

NIC Teaming

DataCore does not recommend using NIC teaming with iSCSI initiator or target ports.

Also See

Using NIC Teaming with SANsymphony

MS Initiator Ports

While technically, the MS initiator is available from ‘any’ network interface on the DataCore Server, the convention here is to treat MS Initiator connections used explicitly for any iSCSI Loopback connections as a separate, dedicated, IP address.

Creating Loopback Connections

Using SANsymphony’s Built-in Loopback Ports

Do not use SANsymphony’s built-in loopback ports for serving virtual disks to the hypervisor. See Known Issues for more information.

Using iSCSI Connections

Always connect to a DataCore Front-end (FE) port never from it when creating an iSCSI loopback (i.e. never initiate from the same IP address as a DataCore FE port). Also make sure that the Microsoft initiator connection is initiating from a different MAC address than the DataCore FE port (i.e. do not create the Loopback ‘within’ the same NIC that has multiple IP addresses configured it).

While looping back on the same IP/MAC address technically works, the overall performance for virtual disks using this I/O path will be severely restricted compared to looping virtual disks between different MAC addresses.

Using Virtual NIC Connections

The following illustration is an example showing the correct initiator/target loopback connections (highlighted in red) when using virtual NIC connections (vNICs).

DataCore FE ports are never used as the initiator - only the target - and that the interface used for the Microsoft Initiator never connects back to itself.

Here is the same example but with the incorrect initiator/target loopback connections (highlighted in red) when using vNICs.

Using Physical NIC Connections

With a physical NIC connections (pNICs) loopback connection both the Microsoft Initiator and the DataCore FE port each get assigned their own physical NIC which are both connected to an IP switch and logically connected to each other, creating the ‘loop’.

The following illustration is an example showing the correct initiator/target loopback connections (highlighted in red) when using pNICs.

DataCore FE ports are never used as the initiator - only the target - and that the interface used for the Microsoft Initiator never connects back to itself.

Performance using a vNIC Loopback compared to a pNIC Loopback

While DataCore have no preference over using virtual or physical NICs as loopbacks mappings, internal testing has shown that pNIC loopback configurations have been able to give as much as 8 times more throughput compared to vNIC loopback configurations under the same I/O workloads.

Maintaining Persistent Reservation connections (Microsoft Cluster Services)

If the DataCore Servers are configured within a Microsoft Cluster, an additional iSCSI Initiator connection is required for each MS Initiator designated vNIC/pNIC to ensure that all Cluster Reservations can be checked for/released by any server should the SANsymphony software be stopped (or unavailable) from one side of the high available pair.

Using the same MS Initiator IP address as those configured for iSCSI Loopback connections connect them into the corresponding ‘remote’ DataCore Server’s FE port as shown below. The following illustration shows the correct initiator/remote target connections (highlighted in red) when using vNICs.

The same correct initiator/remote target connections (highlighted in red) when using pNICs.

Unlike vNICs, an IP switch is required to provide both the ‘loop’ connection between the physical NICs and a route to the ‘remote’ DataCore FE port on the other DataCore Server.

SANsymphony’s Management connection

Avoid using the same IP address of any iSCSI port as SANsymphony’s Management IP address. Heavy iSCSI I/O can interfere with the passing of configuration information and status updates between DataCore Servers in the same Server Group. This can lead to an unresponsive SANsymphony Console, problems connecting to other DataCore Servers in the same Server Group (or remote Replication Group) and can also prevent SANsymphony PowerShell Cmdlets from working as expected as they also need to ‘connect’ to the Server Group to perform their functions.