1000v - Importance of "system vlan" in port-profile

[Paul Marks]

Hi All,

Can someone help me understand the importance of the "system vlan" command in a port profile?

As I understood it, it was used to mark critical system vlans (packet, data, etc.) so their config was pushed to vCenter so they would continue to work should the VSM be down. Is that right?

Every example I look at seems to just mark every VLAN (even VM data VLANs) as "system vlan" in their ethernet uplink prot profiles. Is that now best practice?

Also, is there any reason to mark vEthernet ports with system vlan settings?

Cheers,

P

[simon.wright · Accepted solution]

As you have already port it the system vlan is there to ensure access to the vlan should the vsm go down and then the esxi host is rebooted. if the system vlan was not enabled the esxi host would not be able to talk to the vsm, but this is only the case if the management port is using the Cisco VDS and not a VSS or VDS.

as I use mainly servers with only 2 10Gb ports I use system vlans for the ESXi management / storage and vMotion and if the vCenter is a VM then also the vlan that uses. all other vlans I do not class as system vlans.

I also use VSM layer3 so no need to worry about the packet and data vlans.  But I use this as I have many esxi farms in a different management subnets and the 1000v in a network management subnet.

I hope this helps.

[Paul Marks]

Thanks for that, I think that's a really useful answer.

So it really is just a case of defending core/bootstrapping VLANs?

So it has no real meaning on a vEthernet profile then?

[simon.wright]

here is an example from my configs I use.

port-profile type ethernet system-uplink-03

vmware port-group

switchport mode trunk

switchport trunk native vlan 1034

switchport trunk allowed vlan 1031-1034

channel-group auto mode on mac-pinning

no shutdown

system vlan 1031-1033

description  Development system profile for critical ports and vm traffic

state enabled

1031-1034 are vmware mgmt, ip storage and vmotion in this instance vcenter was in a different environment I have I think about 12 different system uplink port profiles

here is a port-profile:

port-profile type vethernet 03-development-vmsc

capability l3control

vmware port-group

switchport mode access

switchport access vlan 1031

no shutdown

system vlan 1031

max-ports 32

description 03 Development ESXi Management

state enabled

hope this helps.

[Paul Marks]

Many thanks!

[Robert Burns]

FYI - Vmotion should not and does not need to be a "system vlan". 

Robert

[simon.wright]

Robert can you please explain why it should not be ?  It has worked very well for me a few times there has been a problem with a host, also I have done it as I have the permission to migrate a vm but do not have the permission to change the state of the vm (power off/on)  Also I see no harm in having it as a system vlan.

Please tell me though if there is a problem I may encounter if i continue to use it as a system vlan, currently there are four system vlans per system uplink.  Is there a max number of supported system vlans, and if so can those vlans only do certain tasks ?

Many thanks and I look forward to your reply.

Simon.

[Robert Burns]

I've explained the rationale behind system vlans on dozens of posts in the correct forum for 1000v topics - [server networking]

A system VLAN has no impact on any already-created virtual interfaces.  The only benefit a system VLAN provides is to be forwarding as soon as the host boots up "before" communicating with the VSM.  In what instance would you have a host just boot up, unable to talk to your primary or secondary VSM and require a VMotion?  If you did vMotion a VM, odds are the VM's VLAN is NOT a system VLAN and wouldn't be forwarding on the destination host regardless (at least until the VEM can communicate with the VSM that is).  So would you really want to allow a VM to be able to VMotion to a host where it will have no networking connectivity? By omitting the VMotion VMK port profile from being a system VLAN the Migration Validation vCenter performs will fail and prevent you from black holing your VM's networking.

Also there's a global limitation of 16 port profiles containing system VLANs so using one up unnecessarily is not good design IMO.

Regards,

Robert

[simon.wright]

Thank you Robert I will try and find those posts.