Confusion about routing on a standard vSwitch

[wcrosb01]

We are moving towards a clustered vCenter and I've read everywhere that VLANs are your best friend when configuring these types of environments.  Our hosts will have 8 physical NICs to work with.  

My main issue is, I would have liked to have our Management vmkernels on a separate VLAN than all our VMs, but it doesn't look that our network team provided a separate VLAN for that purpose and it will have to share the same subnet as one of our port groups.    

Some background:

We're using VLAN100 for Management Kernels (Assigned one physical NIC),  

VLAN100, VLAN110, VLAN120 (Assigned 3 Physical NICs)

routable VLANs (130,140,150) for (vMotion, HA, ISCSI).    

vMotion (One NIC), HA (One NIC), ISCSI (2 NICS for Port Binding).  

My question is, are there any potential pitfalls with having your Management vkernel on the same VLAN or subnet as one of your VM Port Groups assigned to VMs? 

.  

[a_p_]

There's basically no issue with having the Management Network in a production VLAN/subnet. I'd just recommend that it is a server subnet (i.e. not a client network).

What I'm more concerned about is the configuration you posted. You mentioned routed VLANs for vMotion and iSCSI, and also a separate VLAN for HA? vCenter uses the host's Management Network for HA by default, so this should be configured with at least a secondary uplink. I'd actually suggest you have the network team configure trunk/tagged ports (802.1Q) with the required VLANs allowed on these ports, and you create tagged port groups on the hosts. This way you could - for example - create a vSwitch with two uplinks, and port groups for Management and vMotion, where you configure an active/standby policy on the port group level, so that each port group has its default uplink. iSCSI and vMotion should be placed in non-routed VLANs (except you are planning for long-distance vMotion).

André

[wcrosb01]

Thank you Andre.  I must have lopped off the "non" in my mention of vMotion, iscsi vlans in my original post.

Thank you for your explanation to the answer to my original question.  I was going to actually go one step further and put ha on its own vswitch with its own management vkernel, but from what you have explained,  its still going to send ha traffic over my management vkernel on vswitch0.