2

I have a Windows 2008 server running Hyper-V. There are 6 NICs on the server configured like this:

  • NIC01 & NIC02: teamed administrative interface (RDP, mgmt, etc)
  • NIC03: connected to iSCSI VLAN #1
  • NIC04: connected to iSCSI VLAN #2
  • NIC05: dedicated to one virtual switch for VMs
  • NIC06: dedicated to another virtual switch for VMs

The iSCSI NICs are used obviously for storage to host the VMs. I put half the VMs on the host on the switch assigned to NIC05 and the other half on the switch assigned to NIC06. We have multiple production networks that the VMs could appear on so the switch ports that NIC05 & NIC06 are connected to are trunked and we then tag the NIC on the VM for the appropriate VLAN. No clustering on this host.

Now I wish to assign some iSCSI storage direct to a VM. As I see it I have 2 options:

  1. Add the iSCSI VLANs to the trunked ports (NIC05 and NIC06), add two NICs to the VM that needs iSCSI storage, and tag them for the iSCSI VLANs

  2. Create two additional virtual switches on the host. Assign one to NIC03 and one to NIC04. Add two NICs to the VM that needs iSCSI storage and let them share that path to the SAN with the host.

I'm wondering about how much overhead the VLAN tagging in Hyper-V has and haven't seen any discussion about that. I'm also a bit concerned that something funky on the iSCSI-connected VM could saturate the iSCSI NICs or cause some other problem that could threaten storage access for the entire host which would be bad.

Any thoughts or suggestions? How do you configure your hosts when VMs connect direct to iSCSI?

3
  • 2
    Can I ask why you're teaming two NICs for RDP, mgmt, etc.? I would think that of all the applications of your interfaces, the management/RDP load would be the smallest by a large margin.
    – gravyface
    Apr 23, 2010 at 23:55
  • 1
    @Gravyface: It's common to team the management NICs for redundancy. It's also common to team the VM Virtual Switch NICs. You don't team the iSCSI NICs because MPIO fails-over faster if it knows about the independent paths. The 6 NIC setup is extremely common for Hyper-V clusters. If one of the physical switches on the network fails, nothing is interrupted.
    – Chris S
    Apr 24, 2010 at 2:37
  • good to know, Chris.
    – gravyface
    Apr 24, 2010 at 2:57

3 Answers 3

2

With VMware ESXi (at least), your iSCSI storage is abstracted to your guests in the form of VMFS datastores, so there's really not much more to it than assigning more storage to a guest through the VI Client. While easier to administer and manage, this also gives you a layer of additional host security as your guests do not have direct access to the physical storage layer.

However if you have a legitimate reason to do this, I would think the best way for you to accomplish this would be to put your guest VM on the same VLAN as your iSCSI devices as described in #1.

2
  • 1
    It's relatively common in ESX\ESXi 3 environments to pass iSCSI traffic directly through to VM's, bypassing the hypervisor's storage layer entirely because the older ESX iSCSI initiator wasn't all that efficient. With ESX(i) 4 this is less of an issue but it's still easy to do - just add another VM NIC (or more) and connect it to the vSwitch(es) used for the VMKernel iSCSI ports. You do lose iSOE acceleration but TOE still does its heavy lifting.
    – Helvick
    Apr 24, 2010 at 15:27
  • Our ESXi (v3) setup is pretty low load so never really noticed any iSCSI bottlenecks (not that we're looking for any either). Good to know.
    – gravyface
    Apr 24, 2010 at 16:01
2

When it comes to iscsi, we often make special config:

  • Enable Jumbo frames (mtu 9000)
  • Activate flow control
  • Use dedicated physical switch for the iscsi network
  • Disable spanning tree
  • ....

So i wouldn't mix production network with data network (iscsi).

Giving direct iscsi access to storage can be helpful on VM, if you then do snapshot through the Storage, for example. (Equallogic provide then integration between SQL/Exchange and the equallogic snapshot).

1

Attach the iSCSI target to the Hyper-V host, then make it a pass-through drive for the appropriate guest.

3
  • I've considered this option but I don't like building a VM on a host and making it "difficult" to move to another host. I prefer to allow the VMs to be more portable.
    – icky3000
    Apr 24, 2010 at 5:07
  • Unfortunately there's only the two options, use a pass-through disk, or expose the VM to the iSCSI vlan (preferably via routing in the switch). Hyper-V's VLan tagging doesn't slow down the traffic, but I'd keep the VMs away from the iSCSI NICs anyway. You don't want your iSCSI traffic going through a virtual switch, so I wouldn't put NICs 3 & 4 on them unless they're iSCSI HBAs (True or iSOE). It's a simple trade-off, performance for configuration options; you know you're environment best.
    – Chris S
    Apr 24, 2010 at 14:50
  • Many iSCSI targets support multi-mounting of servers, so you can have more than one server mounting a LUN. This is useful in certain circumstances such as multi-pathing or clustering. If you've got the ability to move VMs between hosts dynamically, you can also move your iSCSI store between hosts dynamically.
    – sysadmin1138
    Jun 22, 2010 at 21:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .