Operating System - VMware
1771382 Members
2778 Online
109005 Solutions
New Discussion

Storage and Federation port groups Move to new switch

 
SGMacaulay
Occasional Contributor

Storage and Federation port groups Move to new switch

I am in the process of moving my hosts to a new swtich.  In my VMware configuration I have swtich0 is the one used for the VMs and switch1 is used for hte SImplivity federation adn storage port groups.  These networks are useing 192.x.x.x networks so when I moved the network connection to a new switch I lost storage HA on my VMs.  Is there recommended way of doing this migration to a new switch withour loosing Storage HA?

I have 5 hosts each with 4 10GB NICs, 2 on each vmware switch.

Thanks

5 REPLIES 5
Vinky_99
Esteemed Contributor

Re: Storage and Federation port groups Move to new switch

@SGMacaulay 

When migrating to a new switch, it is important to ensure that the network configuration is properly updated to maintain connectivity and any associated features such as Storage HA. Here are some steps you can follow to minimize downtime and ensure a smooth transition:

  1. Before starting the migration, make sure that you have a good understanding of your current network configuration, including VLANs, IP addresses, and routing.

  2. Identify the new switch ports that will be used for the storage and federation port groups. Make sure that the new switch ports are configured with the same VLAN settings and network settings as the old switch ports.

  3. Create the new port groups on the new switch using the same names and settings as the old port groups. This will ensure that when you migrate the virtual machines to the new switch, their network configurations will remain intact.

  4. Move one host at a time to the new switch. Start with one host, and migrate its VMs to the new switch. Once the VMs are moved, update the host's network configuration to use the new switch ports. Verify that the storage and federation port groups are functioning correctly on the new switch.

  5. Repeat the above process for each host, one at a time. Make sure that you verify the network configuration for each host after it is migrated to the new switch.

  6. After all hosts have been migrated to the new switch, verify that the storage and federation port groups are functioning correctly. Test Storage HA to ensure that it is working as expected.

By following these steps, you can minimize downtime and ensure that your Storage HA is not affected during the switch migration.

These are my opinions so use it at your own risk.
SGMacaulay
Occasional Contributor

Re: Storage and Federation port groups Move to new switch

Not sure that is the solution.  The issue is that my Simplivity Federation and storage port groups are on one virtual switch.  When I move the physical adapter for a host the none routable networks (federation and storage) will not see eachother across the two physically different switches.  When this happens I loose VM storage HA.  You don't move VMs from one virtual switch to another.

Vinky_99
Esteemed Contributor

Re: Storage and Federation port groups Move to new switch

@SGMacaulay 

I got it. In this case, since the storage and federation port groups are on the same virtual switch, migrating the physical adapter for a host will cause the virtual switch to lose connectivity to the storage network, resulting in a loss of Storage HA for the virtual machines.

One approach to address this issue is to use VMware's vSphere Distributed Switch (VDS). The VDS allows you to create a virtual switch that spans multiple physical switches, enabling virtual machines to maintain connectivity even when physical switches are replaced.

To migrate to VDS, follow these steps:

  1. Create a VDS on the new switch and configure the same VLAN settings and network settings as the existing virtual switch.

  2. Add the physical adapters for all hosts to the VDS.

  3. Create new port groups on the VDS for the storage and federation networks.

  4. Migrate the virtual machines to the VDS by changing their network adapter settings to use the new port groups.

  5. Verify that the virtual machines are functioning correctly on the VDS.

  6. Once all virtual machines are migrated, remove the physical adapters from the old virtual switch and remove the old virtual switch from the hosts.

By following these steps, you can migrate to a VDS and maintain Storage HA for your virtual machines during the switch migration. Note that VDS requires an Enterprise Plus license, so ensure that your VMware licensing is sufficient for this feature.

Hope this helps!

These are my opinions so use it at your own risk.
SGMacaulay
Occasional Contributor

Re: Storage and Federation port groups Move to new switch

I can see how this solution would work but I do not have enterprise plus licensing.  Any other thoughts?

Vinky_99
Esteemed Contributor

Re: Storage and Federation port groups Move to new switch

In that case, another approach to consider is to create a backup of your virtual machines and restore them to a new vSphere cluster after the switch migration is complete. Here are the steps you can follow:

  1. Create a backup of your virtual machines using a backup tool of your choice.

  2. Once the backup is complete, power off the virtual machines and remove them from the hosts.

  3. Migrate the physical adapters for all hosts to the new switch.

  4. Create a new vSphere cluster on the new switch and add the hosts to the cluster.

  5. Create new virtual switches and port groups on the new cluster with the same names and settings as the old virtual switches and port groups.

  6. Restore the virtual machines to the new cluster using the backup tool.

  7. Power on the virtual machines and verify that they are functioning correctly on the new cluster.

By following these steps, you can ensure that your virtual machines are not impacted by the switch migration and that Storage HA is maintained throughout the process. However, this approach may require significant downtime during the backup and restore process, depending on the size and number of virtual machines involved.

Best of luck!

These are my opinions so use it at your own risk.