Skip to main content

vSphere Distributed Switch Part 9 – Migrate Virtual Machine network from Standard Switch to Distributed Switch without downtime

Migrating the virtual Machine network from standard switch to distributed switch is one of interesting task in dvswitch administration. This is one of the task that VMware admin should be aware about. This post i am going to explain the step by step procedure to migrate your virtual machines from the standard switch to distributed switch.
In this post, I am going to migrate few of the virtual machines from the portgroup (VM_PROD_VLAN17) on my standard switch ( vSwitch0) to dvportgroup (DVPG_VM_PROD_VLAN17) on my distributed switch (DSwitch-Production)
Prerequisites for the Migration without downtime
1. Ensure that your ESXi host has been added to dvswitch before initiating this migration. (My ESXi host called 192.168.0.125″ is already added to dvswitch)
2.Ensure that you have network connectivity of your distributed switch uplink is having same or relevant VLANs trunked as same as your standard switch uplink. Compare the configuration of your destination dvswitch uplink with your existing uplink of standard switch and also ensure that they are configured identically on the physical switch also. (My dvswitch uplink vmnic1 and vmnic 3 is having same network connectivity as my standard switch uplink vmnic0)

Procedure

Login to your vCenter Server using vSphere Web client. Select your Distributed switch and click on Actions. Select Add and Manage Hosts option
Select Manage Host Networking option and click on Next
Select the Hosts from the list and click on Next.
Select the checkbox Migrate Virtual machine networking task and click on Next. This task allows you to migrate VM network adapters by assigning them to distributed port groups on the distributed switch.
Select the Virtual machines or network adapters from the below list to migrate to the distributed switch and click on Assign Port Group
Select the  destination dvportgroup from the list for the virtual machines to migrate to and click on Ok.  I have selected DVPG_VM_PROD_VLAN17
Review the Destination Port Group information of the virtual machines and click on Next.
Review your settings selected and click on Finish.
Once the Migration is Completed, My 2 VM’s (Prod-WebServer and Prod-Fileserver) is moved to my dvport group (DVPG_VM_PROD_VLAN17)
The above procedure is more suitable to perform migration of group of virtual machines networking. If you have one or few VM network need to migrated to dvswitch then, you can manually edit the virtual machine settings and Assign the portgroup from list in Network adapter settings to migrate it to dvswitch.
I hope this is informative for you. Thanks for Reading!!!. Be Social and share it in social media if you feel worth sharing it.

Comments

Popular posts from this blog

Step-by-Step Explanation of Ballooning, Compression & Swapping in VMware

 🔹 Step-by-Step Explanation of Ballooning, Compression & Swapping in VMware ⸻ 1️⃣ Memory Ballooning (vmmemctl) Ballooning is the first memory reclamation technique used when ESXi detects memory pressure. ➤ Step-by-Step: How Ballooning Works  1. VMware Tools installs the balloon driver (vmmemctl) inside the guest OS.  2. ESXi detects low free memory on the host.  3. ESXi inflates the balloon in selected VMs.  4. Balloon driver occupies guest memory, making the OS think RAM is full.  5. Guest OS frees idle / unused pages (because it believes memory is needed).  6. ESXi reclaims those freed pages and makes them available to other VMs. Why Ballooning Happens?  • Host free memory is very low.  • ESXi wants the VM to release unused pages before resorting to swapping. Example  • Host memory: 64 GB  • VMs used: 62 GB  • Free: 2 GB → ESXi triggers ballooning  • VM1 (8 GB RAM): Balloon inflates to 2 GB → OS frees 2 GB → ESXi re...

Quick Guide to VCF Automation for VCD Administrators

  Quick Guide to VCF Automation for VCD Administrators VMware Cloud Foundation 9 (VCF 9) has been  released  and with it comes brand new Cloud Management Platform –  VCF Automation (VCFA)  which supercedes both Aria Automation and VMware Cloud Director (VCD). This blog post is intended for those people that know VCD quite well and want to understand how is VCFA similar or different to help them quickly orient in the new direction. It should be emphasized that VCFA is a new solution and not just rebranding of an old one. However it reuses a lot of components from its predecessors. The provider part of VCFA called Tenenat Manager is based on VCD code and the UI and APIs will be familiar to VCD admins, while the tenant part inherist a lot from Aria Automation and especially for VCD end-users will look brand new. Deployment and Architecture VCFA is generaly deployed from VCF Operations Fleet Management (former Aria Suite LCM embeded in VCF Ops. Fleet Management...

ESXi Host Troubleshooting Checklist

  🛠️ ESXi Host Troubleshooting Checklist (With Complete Log Locations) ✅ 1. Host Status & Connectivity Check host state in vCenter (Connected / Not Responding / Disconnected) Review CPU, RAM, and datastore usage Validate HA/DRS recommendations ✅ 2. Hardware Health Monitor hardware sensors (CPU, DIMMs, fans, PSU, RAID) Check RAID controller logs via vendor tools View hardware status in: vCenter → Monitor → Hardware Health DCUI → Hardware Status ✅ 3. Network Validation Verify vSwitches, Port Groups, NIC teaming, VLAN tagging Check vmkernel ports (mgmt, vMotion, iSCSI, vSAN) Test reachability using: Shell vmkping < IP > Show more lines Validate physical NIC status and link speed ✅ 4. Storage & Datastore Checks Confirm datastore accessibility Rescan storage adapters (iSCSI/FC/NFS) Validate multipathing (Round Robin / Fixed / MRU) Check datastore latency with esxtop ✅ **5. Critical Logs & Their Locations (Full List) Here are key ESXi log files that every VMware adm...