VMware Cloud Community
timjwatts
Enthusiast
Enthusiast

dvSwitch - convert uplinks from untagged to tagged VLAN (native to trunk)

Hi,

I have a nice stable ESXi 4.1 system with 3 bonded uplinks to the Internet (public network CISCO).

The uplink ports are set at the CISCO end for untagged (native) VLAN on one subnet as that was the scope of the system when I designed it.

Annoyingly, due a meger of departments, I have to make a second VLAN/subnet availble to the ESX VMs.

Question:

How easy is it to, on a running system to switch this over?

My dvSwitch uplinks are in Trunk mode (I don't think there is any other option) and the portgroup used by all the VMs is in VLAN-None mode.

I assume what I need to aim for is to simply switch the portgroup to VLAN=<my vlan ID> and get the CISCO switch switched from native to tagged/trunk mode on those ports? Then I can add a second portgroup for the other subnet.

Is it possible to do this on a host by host basis, in maint mode, without breaking the linkage between portgroup and VMs, so that I can still vMotion VMs back onto that host after the change? Then deal with host 2, rinse-repeat and fix host 3...

If I use the normal dvSwitch editing tools, it seems I am liable to reconfigure all 3 hosts at once which I don't want to do as it will break everything...

Many thanks for any ideas Smiley Happy

Cheers

Tim

Reply
0 Kudos
6 Replies
peetz
Leadership
Leadership

Hi Tim,

rather than doing the change host by host, you should do it uplink by uplink. That means

- Remove the first physical uplink from the dvSwitch

- Re-configure the associated Cisco switch port

- Add the uplink back to the dvSwitch

Once you have done that for all uplinks, go and create the additional port group on the dvSwitch. You can do that without interruption to the networking of VMs already running on the dvSwitch.

For information on how to configure the Cisco switch ports you can refer to http://kb.vmware.com/kb/1006628.

- Andreas

Twitter: @VFrontDe, @ESXiPatches | https://esxi-patches.v-front.de | https://vibsdepot.v-front.de
Reply
0 Kudos
timjwatts
Enthusiast
Enthusiast

Hi Andreas,

I follow the logic - but I cannot see how to do this.

I have one dvUplinks set with the 3 links - but the VLAN setting *seems* to apply to the dvUplinks group and not to the NIC.

How would I add back VLAN-tagged uplinks?

Sorry if I've missed something obvious. I thought about creating a new dvUplinks set but I think it is limited to one only?

Cheers

Tim

Reply
0 Kudos
peetz
Leadership
Leadership

I am assuming that you keep your existing VLAN as the native VLAN when adding the second one in trunk mode.

The native VLAN of a trunk carries untagged traffic (just like now without the trunk), and that means that you do not need to change any settings for the existing VMs and the existing dvSwitch portgroup that these VMs connect to.

So after having reconfigured all uplinks you just need to add a second portgroup to the exisiting dvSwitch and assign the new VLAN ID to it.

Anyway I recommend using the procedure of temporarily removing each uplink from the dvSwitch while its Cisco port is reconfigured (see my first post), because the link will go down for a short time when being reconfigured, and if you want to rule out any network interruption it's best to not use this uplink during that time.

I read your original post now again, and I'm not so sure anymore if I correctly understand your setup. You have multiple hosts in a a cluster, right? They all share the same dvSwitch, and each of them has three uplinks to one or more Cisco switches, right?

- Andreas

Twitter: @VFrontDe, @ESXiPatches | https://esxi-patches.v-front.de | https://vibsdepot.v-front.de
Reply
0 Kudos
timjwatts
Enthusiast
Enthusiast

Hi Andreas,

You understand my physical layout correctly. 3 hosts, each with 3 bonded uplinks to the CICSO, one dvSwitch using those uplinks.

Ideally I would prefer to convert the trunk to fully tagged operation just for neatness. But I take your point that running current VLAN native and adding the new one as tagged would possibly be the easiest solution.

If running like that, I presume ESX will filter out tagged packets from the "VLAN=none" portgroup? Then I add a new portgroup with a VLAN=whatever-ID fo rthe new subnet...

It's not totally upto me - I don't control that network - have to meet with the networks manager, though he will generally be happy with anything reasonable.

Cheers,

Tim

Reply
0 Kudos
peetz
Leadership
Leadership

Tim,

if you cannot keep the native VLAN then it is still feasible but more complicated:

1. Create a new dvSwitch and move one uplink of each host from the old to the new dvSwitch.

2. Create two portgroups on the new dvSwitch and assign the needed VLAN IDs to them (the existing one and the new one)

3. Re-configure the Cisco ports of the three uplinks of the new dvSwitch to carry the two VLANs in trunk mode.

4. Now use the "Migrate Virtual Machine Networking ..." wizard (available in the conext menu of each dvSwitch in the Inventory/Networking view of the vSphere client) to move your existing VMs from the old dvSwitch portgroup to the correct portgroup of the new dvSwitch. Try this with a test VM first to check if everything is configured correctly.

5. After you have migrated all your existing VMs: Re-configure the Cisco ports of all the remaining uplinks of the old dvSwitch.

6. Move all uplinks to the new dvSwitch now and destroy the old dvSwitch.

The migration wizard will just change the network connection of the selected VMs from the old to new dvSwitch while they are running (you could also do this manually by adding the VMs' properties). This happens without a network interruption for the VM. You should notice none or only a single ping drop.

- Andreas

Twitter: @VFrontDe, @ESXiPatches | https://esxi-patches.v-front.de | https://vibsdepot.v-front.de
timjwatts
Enthusiast
Enthusiast

Hi Andreas,

Sir, you are a genius.

That migrate option was not obvious until I went looking for it... This seems like a most reasonable approach and does not scare me in the slightest.

Excellent - I can now present a couple of workable options to the company network-meister. I do not see any problems with either, but a choice is nice and neither will actually cause him much work. I'll be next to him with my laptop onto ESX (I have a backup route in to ESX so am not dependent on these links running for management purposes) so we can do the reconfig together (and back out sharpish if something goes bang).

Many many thanks,

Tim

Reply
0 Kudos