There was recently a scenario we had whilst working with a client, where we had an ESXi host running version 5.5 using a single VLAN. All of the Virtual Machines were in a single port-group, and they were untagged, sending traffic to a neighbouring Cisco switch where the port was configured as an access port. There were a couple of vmkernel ports on the vswitch too.
A requirement came up to have multiple VLANs on the ESX host, to provide some separation and security. At the same time, we wanted to avoid downtime to the existing VM's, and as we were accessing this environment remotely, we couldn't afford to lose the management interface. For the monitoring, management and logging services, we also didn't want to change the IP address of the vmkernel ports.
So...this is what we did:
- First, we created a second vswitch. We associated this with a spare NIC on the server, and configured the Cisco end as a trunk port (luckily for us it was pre-cabled!).
- We created a new port-group for the VM's - this time tagged with the VLAN ID.
- One by one, the VM's were moved into the new port-group by editing the VM settings and selecting the new port-group for the NIC. This does cause a very slight network disruption, but so slight we didn't even lose a ping for half the VM's - and for the other half it was just a single ping loss.
- For all vmkernel ports except the management one, we then deleted them and recreated them on the second switch - with vlan tagging.
- For the management vmkernel port:
- First, a second vmkernel port was created on the second switch. This was temporarily given another IP from the same subnet. Management access was tested to this port.
- Next, while connected to the management via the new vmkernel port IP, the original vmkernel port was moved to a another temporary IP in the VLAN, freeing up the original address.
- While connected to the original vmkernel port on it's temporary IP, we then re-IP'd the new vmkernel port to the original IP, so we now had a vmkernel port on the second switch with the original management IP of the ESXi host.
- Logging in via the old IP (and the new vmkernel on the second switch), we then deleted the original vmkernel port, and also the original switch.
- At this point we lost access to the management port. This was unexpected, to say the least. We had to use ILO to access the DCUI and restart management services. Not sure why, it seems like it got confused and the service died or something. No "production" (i.e. VM) traffic was impacted, we only lost management. We didn't actually have to reconfigure anything via the DCUI, just select "Restart Management Services". Make sure you don't have strict lockdown mode enabled before doing this!
This method worked for us for migrating the vmkernel port to a second standard vswitch, allowing us to reconfigure the uplinks to allow tagged VLANs. Our client is now free to create as many VLANs and port-groups as they like.