fbpx
elephant

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:

  1. 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!).
  2. We created a new port-group for the VM’s – this time tagged with the VLAN ID.
  3. 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.
  4. For all vmkernel ports except the management one, we then deleted them and recreated them on the second switch – with vlan tagging.
  5. For the management vmkernel port:
    1. 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.
    2. 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.
    3. 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.
    4. 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.
    5. 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.

We know technology can be a bother, and that’s why we are here to help with all your IT needs, no matter how big or small.

Our goal is to make sure that your business has a reliable infrastructure in place so you can focus on what matters most – running your company! 

So if you need any help at all, book a 15 minute discovery call with one of our experts today. We’ll be happy to lend a hand! 

Select Service

Discovery Call 15 minutes
Free

Select time

Select a service and date to see available times.

Tell us who we are meeting

Can we have a heads up on roughly what you want to talk about please?

Initial consult

Duration: 1 hour
Not sure what you need? Grab 60 minutes with us and we will work with you to understand your goals, and to develop a proposal and price estimate.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.