![\"image\"](\"https:\/\/aidanfinn.com\/wp-content\/uploads\/2013\/01\/image1.png\" "\\"image\\"")
<\/a><\/p>\niSCSI storage typically has these two requirements:<\/p>\n
- \n
- Two NICs to connect to the SAN switches, each on a different subnet.<\/li>\n
- Each NIC is on a different subnet<\/li>\n<\/ul>\n
In the diagram focus on the iSCSI piece. That\u2019s the NIC team on the left.<\/p>\n
The Physical NICs and Switches<\/u><\/strong><\/p>\n
As usual with an iSCSI SAN, there are two dedicated switches for the storage connections. That\u2019s a normal (not always) support requirement by SAN manufacturers. This is why we don\u2019t have complete convergence to a single NIC team, like you see in most examples. <\/p>\n
The host will have 2 iSCSI NICs (10 GbE). The connected switch ports are trunked, and both of the SAN VLANs (subnets) are available via the trunk.<\/p>\n
The NIC Team and Virtual Switch<\/u><\/strong><\/p>\n
A NIC team is created. The team is configured with Hyper-V Port load distribution (load balancing), meaning that a single virtual NIC cannot exceed the bandwidth of a single physical NIC in the team. I prefer LACP (teaming mode) teams because they are dynamic (and require minimal physical switch configuration). This type of switch dependent mode requires switch stacking. If that\u2019s not your configuration then you should use Switch Independent (requires no switch configuration) instead of LACP.<\/p>\n
The resulting team interface will appear in Network Connections (Control Panel). Use this interface to connect a new external virtual switch that will be dedicated to iSCSI traffic. Don\u2019t create the virtual switch until you decide how you will implement QoS.<\/p>\n
The Management OS (Host)<\/u><\/strong><\/p>\n
The host does not have 2 NICs dedicated to it\u2019s own iSCSI needs. Instead, it will share the bandwidth of the NIC team with guests (VMs) running on the host. That sharing will be controlled using Quality of Service (QoS) minimum bandwidth rules (later in the post).<\/p>\n
The host will need two NICs of some kind, each one on a different iSCSI subnet. To do this:<\/p>\n
- \n
- Create 2 management OS virtual NICs<\/li>\n
- Connect them to the iSCSI virtual switch<\/li>\n
- Bind each management OS virtual NIC to a different iSCSI SAN VLAN ID<\/li>\n
- Apply the appropriate IPv4\/v6 configurations to the iSCSI virtual NICs in the management OS Control Panel<\/li>\n
- Configure iSCSI\/MPIO\/DSM as usual in the management OS, using the virtual NICs<\/li>\n<\/ol>\n
Do not configure\/use the physical iSCSI NICs! Your iSCSI traffic will source in the management OS virtual NICs, flow through the virtual switch, then the team, and then the physical NICs, and then back again.<\/p>\n
The Virtual Machines<\/u><\/strong><\/p>\n
Create a pair of virtual NICs in each virtual machine that requires iSCSI connected storage.<\/p>\n
Note: Remember that you lose virtualisation features with this type of storage, such as snapshots (yuk anyway!), VSS backup from the host (a very big loss), and Hyper-V Replica. Consider using virtual storage that you can replicate using Hyper-V Replica.<\/em><\/p>\n
The process for the virtual NICs in the guest OS of the virtual machine will be identical to the management OS process. Connect each iSCSI virtual NIC in the VM to the iSCSI virtual switch (see the diagram). Configure a VLAN ID for each virtual NIC, connecting 1 to each iSCSI VLAN (subnet) \u2013 this is done in Hyper-V Manager and is controlled by the virtualisation administrators. In the guest OS:<\/p>\n
- \n
- Configure the IP stack of the virtual NICs, appropriate to their VLANs<\/li>\n
- Configure iSCSI\/MPIO\/DSM as required by the SAN manufacturer<\/li>\n<\/ul>\n
Now you can present LUNs to the VMs.<\/p>\n
Quality of Service (QoS)<\/u><\/strong><\/p>\n
QoS will preserve minimum amounts of bandwidth on the iSCSI NICs for connections. You\u2019re using a virtual switch so you will implement QoS<\/a> in the virtual switch. Guarantee a certain amount for each of the management OS (host) virtual NICs. This has to be enough for all the storage requirements of the host (the virtual machines running on that host). You can choose one of two approaches for the VMs:<\/p>\n
- \n
- Create an explicit policy for each virtual NIC in each virtual machine \u2013 more engineering and maintenance required<\/li>\n
- Create a single default bucket policy on the virtual switch that applies to all connected virtual NICs that don\u2019t have an explicit QoS policy<\/li>\n<\/ul>\n
This virtual switch policy give the host administrator control, regardless of what a guest OS admin does. Note that you can also apply classification and tagging policies in the guest OS to be applied by the physical network. There\u2019s no point applying rules in the OS Packet Scheduler because the only traffic on these two NICs should be iSCSI.<\/p>\n
Note: remember to change the NIC binding order in the host management OS and guest OSs so the iSCSI NICs are bottom of the order.<\/em><\/p>\n
Support?<\/u><\/strong><\/p>\n
I checked with the Microsoft PMs because this configuration is nothing like any of the presented or shared designs. This design appears to be OK with Microsoft<\/em>. <\/p>\n
For those of you that are concerned about NIC teaming and MPIO: In this design, MPIO has no visibility of the NIC team that resides underneath<\/em> of the virtual switch so there is not a support issue.<\/p>\n
Please remember:<\/p>\n
- \n
- Use the latest stable drivers and firmwares<\/li>\n
- Apply any shared hotfixes (not just Automatic Updates via WSUS, etc) if they are published<\/li>\n
- Do your own pre-production tests<\/li>\n
- Do a pilot test<\/li>\n
- Your SAN manufacturer will<\/em> have the last say on support for this design<\/li>\n<\/ul>\n
EDIT1:<\/u><\/strong><\/em><\/p>\n
If you wanted, you could use a single iSCSI virtual NIC in the management OS and in the guest OS without <\/em>MPIO. You have the path fault tolerance that MPIO provides via NIC teaming. Cluster validation would give you a warning (not a fail), and the SAN manufacturer might get their knickers in a twist over the lack of dual subnets and MPIO.<\/p>\n
And \u2026 check with your SAN manufacturer for the guidance on the subnets because not all have the same requirements.<\/p>\n
Technorati Tags: Hyper-V<\/a>,Virtualisation<\/a>,Windows Server 2012<\/a>,Networking<\/a>,Storage<\/a><\/div><\/p>\n","protected":false},"excerpt":{"rendered":"A friend recently asked me a question. He had recently deployed a Windows Server 2012 cluster with converged fabrics. He had limited amounts of NICs that he could install and limited number of switch ports that he could use. His Hyper-V host cluster is using a 10 GbE connected iSCSI SAN. He also wants to … Continue reading “A WS2012 Hyper-V Converged Fabric Design With Host And Guest iSCSI Connections”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"_wpcom_ai_launchpad_first_post":false,"footnotes":""},"categories":[20],"tags":[181,80,99,195,118],"class_list":["post-13947","post","type-post","status-publish","format-standard","hentry","category-hyper-v","tag-hyper-v","tag-networking","tag-storage","tag-virtualisation","tag-windows-server-2012"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t