<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>grimsrue Tracker</title>
    <link>https://communities.vmware.com/wbsdv95928/tracker</link>
    <description>grimsrue Tracker</description>
    <pubDate>Wed, 15 Nov 2023 12:20:33 GMT</pubDate>
    <dc:date>2023-11-15T12:20:33Z</dc:date>
    <item>
      <title>Re: Export the network configure (Not use Distributed Switches)</title>
      <link>https://communities.vmware.com/t5/vSphere-vNetwork-Discussions/Export-the-network-configure-Not-use-Distributed-Switches/m-p/2994731#M14790</link>
      <description>&lt;P&gt;"rvtools" might be able to get what you need in a pinch. (&lt;A href="https://www.robware.net/rvtools/download/" target="_blank"&gt;https://www.robware.net/rvtools/download/&lt;/A&gt;)&lt;/P&gt;&lt;P&gt;Ultimately the best thing is a script. VMWare has powershell modules you can pull down off of Git hub. If you search in VMWare communities you will find scripts that people have already created and shared out. I know not everyone is scripting savvy, but its your greatest tool when pulling data from vCenters, ESXi host, etc.&lt;/P&gt;</description>
      <pubDate>Wed, 08 Nov 2023 16:11:40 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/vSphere-vNetwork-Discussions/Export-the-network-configure-Not-use-Distributed-Switches/m-p/2994731#M14790</guid>
      <dc:creator>grimsrue</dc:creator>
      <dc:date>2023-11-08T16:11:40Z</dc:date>
    </item>
    <item>
      <title>NSX-T 4.1.1.0 IPv4 'Pool Identifier is null' issue</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-T-4-1-1-0-IPv4-Pool-Identifier-is-null-issue/m-p/2983339#M16817</link>
      <description>&lt;P&gt;Hello All,&lt;/P&gt;&lt;P&gt;I did a recent upgrade of one of my lab NSX-T environment to 4.1.1.0. After the upgrade I am now getting odd error with my current Transport Node config using my current IP Pools that are IPv4 only.&lt;/P&gt;&lt;P&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;Error: Static IP Pool ************ of type null should not be provided for IP assignment type STATIC_IP_POOL in Host Switch **************. Please provide IP pool of type IPV4. (Error code: 9884)&lt;BR /&gt;&lt;BR /&gt;When&amp;nbsp; I look at all of my IP Pools they are all showing a status error of "Pool identifier is null&lt;SPAN&gt;.&lt;/SPAN&gt;"&lt;BR /&gt;&lt;BR /&gt;I decide to build a new Test IP Pool from scratch and it goes right to the same error of "Pool identifier is null"&lt;BR /&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;Anyone have any ideas of what is going on here?&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="grimsrue_0-1692638573773.png" style="width: 400px;"&gt;&lt;img src="https://communities.vmware.com/t5/image/serverpage/image-id/103142i6D2320A53E7EDB0B/image-size/medium/is-moderation-mode/true?v=v2&amp;amp;px=400" role="button" title="grimsrue_0-1692638573773.png" alt="grimsrue_0-1692638573773.png" /&gt;&lt;/span&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="grimsrue_1-1692638702298.png" style="width: 400px;"&gt;&lt;img src="https://communities.vmware.com/t5/image/serverpage/image-id/103143iF08AD8DED0BF2E5F/image-size/medium/is-moderation-mode/true?v=v2&amp;amp;px=400" role="button" title="grimsrue_1-1692638702298.png" alt="grimsrue_1-1692638702298.png" /&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="grimsrue_2-1692638806722.png" style="width: 400px;"&gt;&lt;img src="https://communities.vmware.com/t5/image/serverpage/image-id/103144i61FD020ECB30F5CA/image-size/medium/is-moderation-mode/true?v=v2&amp;amp;px=400" role="button" title="grimsrue_2-1692638806722.png" alt="grimsrue_2-1692638806722.png" /&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 23 Aug 2023 16:53:48 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-T-4-1-1-0-IPv4-Pool-Identifier-is-null-issue/m-p/2983339#M16817</guid>
      <dc:creator>grimsrue</dc:creator>
      <dc:date>2023-08-23T16:53:48Z</dc:date>
    </item>
    <item>
      <title>Re: vMotion stack questions - 1st time poster</title>
      <link>https://communities.vmware.com/t5/vMotion-Resource-Management/vMotion-stack-questions-1st-time-poster/m-p/2959785#M4839</link>
      <description>&lt;P&gt;Good to know that each ESXi host is connected to a central switch.&lt;/P&gt;&lt;P&gt;Now you have one of three ways making use of vMotion. (You have to use a vCenter for vMotion)&lt;BR /&gt;You can use the primary network connection for each host (VMK0) as your vMotion connection. Its just a matter of editing "VMK0" and checking the box for "vMotion" on each server.&lt;/P&gt;&lt;P&gt;The second way of making use of vMotion is to create a separate VLAN for vMotion, create a portgroup in the vSS/vDS, assign the VLAN to the portgroup, create a new VMK, assign an IP (No GW) to the new VMK for each host and attached that VMK to your new portgroup. You can then modify the new VMK to do vMotion only.&lt;/P&gt;&lt;P&gt;The third way is same as the second way above but you are assigning the vMotion portgroup and VMK to the vMotion IP stack and you will then assign a GW to that VMK.&lt;BR /&gt;&lt;BR /&gt;You can use a host to host connection for two hosts, but when you get to three you have to use a switch. You could probably experiment and try connecting a second cable each of the two host to the third host, but I don't think that will really work.&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;I would keep in simple and just use the Host VMK0 as your vMotion connection. You have a small enough setup that it will not hurt anything to run your Host connectivity and vMotion over the same VMK and IP address.&lt;/P&gt;&lt;P&gt;The next part is your Hardware CPU models and Storage.&lt;BR /&gt;EVC mode will be needed if you are running different CPU Generations between servers. You will create a cluster, add the hosts, go to the "Configuration" tab on the cluster and you will see VMWare EVC. That is where you will set the Intel or AMD generation for the whole cluster. Same thing for individual VMs. Click on the VM, go to the configuration tab, VMWare EVC.&lt;BR /&gt;Whole cluster means all VMs need to be shut down first&lt;BR /&gt;Individual VMs need to be shut down first&lt;BR /&gt;ESXi/vCenter 6.7 or later for Individual VMs&lt;BR /&gt;&lt;BR /&gt;Storage has to be share for fast vMotion. If you do not have shared storage you will be essentially coping the files that make up the whole VM to different storage when you migrate the VMs to a different server. Based on the size of the VM depends on how long it will take to copy to the storage on another server. ( min vs hours)&lt;/P&gt;&lt;P&gt;The subnet the VMs run on needs to be available to each of the three servers. So you will need to make sure the VLANs are trunked to the switch interfaces for each servers primary network connections.&lt;BR /&gt;If you are running on "Virtual Standard Switches" (vSS) then the Portroup Name must be the same as well and Standard Switch names across all three hosts.&lt;BR /&gt;A Virtual Distributed Switch (vDS) is shared across all three hosts. You just attach your hosts to it.&lt;BR /&gt;A vSS is attached to each host&lt;BR /&gt;Each host is attached to a vDS&lt;BR /&gt;&lt;BR /&gt;Let me know if this make sense to you. I can try and break it down a bit more, but once you have vCenter up and a cluster created then some of this will make a bit more sense.&lt;/P&gt;</description>
      <pubDate>Fri, 17 Mar 2023 20:16:51 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/vMotion-Resource-Management/vMotion-stack-questions-1st-time-poster/m-p/2959785#M4839</guid>
      <dc:creator>grimsrue</dc:creator>
      <dc:date>2023-03-17T20:16:51Z</dc:date>
    </item>
    <item>
      <title>Re: vMotion stack questions - 1st time poster</title>
      <link>https://communities.vmware.com/t5/vMotion-Resource-Management/vMotion-stack-questions-1st-time-poster/m-p/2959764#M4837</link>
      <description>&lt;P&gt;Okay. So. There is a lot to unpack here.&lt;BR /&gt;&lt;BR /&gt;Based on what I read it seems to me you have two servers that are connected to each other using 10GB NICs and what I assume is cross-over cables? The servers are not or will not be connected to any type of routed network? How do you access your VMs remotely? The current ESXi servers are running VMs that I assume interact with Radio Network in some way, so are these servers cabled to the Radio Network and do you access your VMs through that Radio Network?&lt;/P&gt;&lt;P&gt;Based on how you answer the questions above I can give you a better idea of what you need. That being said....generally vMotion needs some type of network connectivity for heartbeat. I personally do not think you could use vMotion by just interconnecting 10GB NICs to each other across servers, at least I have never tried it. You would need at least a small network switch that is capable of 10GB to make vMotion function correctly.&lt;/P&gt;&lt;P&gt;Also, to simplify things you do not have to run a separate VMK for vMotion, You can use the VMK0, that your host runs on, to do vMotion, BUT all three host have to be connected to the same switch or have to be using subnets that are rout-able to each other in some way. If the Radio network has the ability to allow your servers to talk to each other then you can use that network for vMotion. If not then you will want to have a separate switch to cable a spare NIC to from each server. You can then use a private subnet (192.168.0.0) to run your vMotions over.&lt;/P&gt;&lt;P&gt;Something else you need to consider. The three servers need to be running the same CPU Model. If not then you are going to have to enable EVC mode for vMotion to function. Both EVC and vMotion are features of vCenter. EVC mode level sets your CPU instruction set across all the servers. If one server is a higher CPU then the other, then your vMotion will fail. This failure will happen because the VMs that are running on the newer CPU will be running instructions sets that the older CPU on another server does not have. You will have to either migrate the VMs off a server to turn EVC mode on or at least power them down. vCenter/vSphere 6.7 introduced the ability to turn EVC mode on for individual VMs, but you will have to shut down the VM first to enable it.&lt;BR /&gt;&lt;BR /&gt;One last thing. All three servers need to share the same Datastore/s for fast vMotion. If all three servers have their own separate datastores then your vMotions will have to be "Storage / Server" vMotions and that will take significantly longer to do a vMotion. Seconds can become mins or hours.&lt;/P&gt;</description>
      <pubDate>Fri, 17 Mar 2023 17:44:07 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/vMotion-Resource-Management/vMotion-stack-questions-1st-time-poster/m-p/2959764#M4837</guid>
      <dc:creator>grimsrue</dc:creator>
      <dc:date>2023-03-17T17:44:07Z</dc:date>
    </item>
    <item>
      <title>Re: VLAN based DHCP on NSX-T</title>
      <link>https://communities.vmware.com/t5/Networking-Members/VLAN-based-DHCP-on-NSX-T/m-p/2943336#M250</link>
      <description>&lt;P&gt;Take a look at this community post. It might be the answer to the issue you are having&lt;/P&gt;&lt;P&gt;&lt;A href="https://communities.vmware.com/t5/VMware-NSX-Discussions/DHCP-with-NSX-T/td-p/529812" target="_blank"&gt;https://communities.vmware.com/t5/VMware-NSX-Discussions/DHCP-with-NSX-T/td-p/529812&lt;/A&gt;&lt;/P&gt;</description>
      <pubDate>Mon, 12 Dec 2022 04:46:31 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Networking-Members/VLAN-based-DHCP-on-NSX-T/m-p/2943336#M250</guid>
      <dc:creator>grimsrue</dc:creator>
      <dc:date>2022-12-12T04:46:31Z</dc:date>
    </item>
    <item>
      <title>Demote Global Manager from Active???</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/Demote-Global-Manager-from-Active/m-p/2938271#M15680</link>
      <description>&lt;P&gt;Anyone know how to demote a Global manager out of "Active" mode? The option to remove it is greyed out. Would like to demote it and use it as a standby location. I hope I dont have to redeploy the Global Managers from scratch.&lt;/P&gt;</description>
      <pubDate>Tue, 15 Nov 2022 00:36:04 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/Demote-Global-Manager-from-Active/m-p/2938271#M15680</guid>
      <dc:creator>grimsrue</dc:creator>
      <dc:date>2022-11-15T00:36:04Z</dc:date>
    </item>
    <item>
      <title>Re: NSX-T 4.0.1.1 - Tier-1 HA Mode "Distributed only"????</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-T-4-0-1-1-Tier-1-HA-Mode-quot-Distributed-only-quot/m-p/2937906#M15673</link>
      <description>&lt;P&gt;I eventually answered my own question after some testing.&lt;BR /&gt;&lt;BR /&gt;Tier-1 HA Mode&lt;BR /&gt;&lt;BR /&gt;Active/Standby - T1 GW connected to Edge Cluster for all "Services" (LB, NAT, VPN, DFW, etc.)&lt;/P&gt;&lt;P&gt;Active/Active - T1 GW connected to Edge Cluster for select services (NAT, L2/L7 Gateway FW, URL, etc)&lt;/P&gt;&lt;P&gt;Distributed Only - T1 GW NO edge cluster connectivity. Straight connectivity to T0. No Services on T1&lt;/P&gt;</description>
      <pubDate>Sat, 12 Nov 2022 00:04:46 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-T-4-0-1-1-Tier-1-HA-Mode-quot-Distributed-only-quot/m-p/2937906#M15673</guid>
      <dc:creator>grimsrue</dc:creator>
      <dc:date>2022-11-12T00:04:46Z</dc:date>
    </item>
    <item>
      <title>NSX-T 4.0.1.1 - Tier-1 HA Mode "Distributed only"????</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-T-4-0-1-1-Tier-1-HA-Mode-quot-Distributed-only-quot/m-p/2937883#M15672</link>
      <description>&lt;P&gt;Probably a dumb question, but here it goes.&lt;/P&gt;&lt;P&gt;I have NSX-T 4.0.1.1 loaded up in a lab. Tier 1 Gateway HA Mode. I understand Active/Standby and I understand the NEW Active/Active, but the "Distributed Only" option I don't understand.&lt;BR /&gt;&lt;BR /&gt;What is that for? I have google the heck out of it and cant find any info other than possibly a feature used for Federating edge nodes between two sites. If that is the case then great, but if not than what am I missing?&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;</description>
      <pubDate>Fri, 11 Nov 2022 19:16:31 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-T-4-0-1-1-Tier-1-HA-Mode-quot-Distributed-only-quot/m-p/2937883#M15672</guid>
      <dc:creator>grimsrue</dc:creator>
      <dc:date>2022-11-11T19:16:31Z</dc:date>
    </item>
    <item>
      <title>Re: Local Network</title>
      <link>https://communities.vmware.com/t5/VMware-Workstation-Player/Local-Network/m-p/2930601#M39664</link>
      <description>&lt;P&gt;I don't work with VMWare Workstation that often. I am more familiar with ESXi. Others in the community might have a better way that I am not thinking about.&lt;/P&gt;&lt;P&gt;Knowing that you are using a laptop and I can now say it would be best to use the laptop Windows firewall or the VMs Windows firewall to block internet access since your laptop can travel around and will potentially connect to different networks.&lt;/P&gt;</description>
      <pubDate>Mon, 26 Sep 2022 16:15:03 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-Workstation-Player/Local-Network/m-p/2930601#M39664</guid>
      <dc:creator>grimsrue</dc:creator>
      <dc:date>2022-09-26T16:15:03Z</dc:date>
    </item>
    <item>
      <title>Re: Local Network</title>
      <link>https://communities.vmware.com/t5/VMware-Workstation-Player/Local-Network/m-p/2930313#M39662</link>
      <description>&lt;P&gt;Simple answer.....Firewall&lt;/P&gt;&lt;P&gt;Since we don't know much about your network or what type of laptop or desktop you are running VMware Workstation on, then that's the best answer I can give.&lt;/P&gt;&lt;P&gt;Are you running VMware Workstation on a Home desktop/laptop or Work desktop/laptop?&lt;BR /&gt;&lt;BR /&gt;What OS is your Desktop/laptop running?&lt;BR /&gt;&lt;BR /&gt;What type of internet connection is being used? ISP for home, corporate internet, or small business internet/ISP?&lt;BR /&gt;&lt;BR /&gt;Is your VM using IPs from a different subnet or from the same subnet that your laptop/desktop is using?&lt;BR /&gt;&lt;BR /&gt;What is assigning those IPs? ISP Modem, company DHCP, or do you have a separate ASUS/Netgear router handling IP assignments.&lt;BR /&gt;&lt;BR /&gt;Based on your answers to any of the above questions there are multiple different ways you can block you VMs IP from accessing the internet and all of them will be the firewall in some form or another.&lt;/P&gt;</description>
      <pubDate>Fri, 23 Sep 2022 17:30:20 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-Workstation-Player/Local-Network/m-p/2930313#M39662</guid>
      <dc:creator>grimsrue</dc:creator>
      <dc:date>2022-09-23T17:30:20Z</dc:date>
    </item>
    <item>
      <title>Re: Cross Communication testing between 2 VMs</title>
      <link>https://communities.vmware.com/t5/Networking-Members/Cross-Communication-testing-between-2-VMs/m-p/2928456#M233</link>
      <description>&lt;P&gt;Your first statement throws off the rest of your post. I had to read your post multiple times to sort of figure out what you are saying. Again you left out a large amount of info in your original post. I did asked multiple times for the info you gave in this last post. If you had give a description of how VCF-A and VCF-B environments were connected on the network then we could have answered your question more specifically. Diagrams help as well.&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;&lt;P&gt;In your first sentence you state "&lt;FONT color="#0000FF"&gt;&lt;EM&gt;Since NSX is a stub and won't transit any traffic most customer push a default route down to NSX that will &lt;STRONG&gt;&lt;U&gt;pull&lt;/U&gt;&lt;/STRONG&gt; all traffic up to the physical network.&lt;/EM&gt;&lt;/FONT&gt;"??????&lt;/P&gt;&lt;P&gt;In your last sentence you state "&lt;FONT color="#0000FF"&gt;&lt;EM&gt;We send all of our routes up, they just send a default down to us.&lt;/EM&gt;&lt;/FONT&gt;"&lt;/P&gt;&lt;P&gt;To me, your first sentence in the post does not make sense with the rest of what you said in your post. First of all I assume you are using the word "Stub" to refer to the NSX instances connecting to a single physical router and not multiple routers? When I read "Stub" I think of a network that does not route anywhere. Also, a physical router pushing its routes down to NSX will not "&lt;FONT color="#0000FF"&gt;&lt;EM&gt;&lt;FONT color="#FF0000"&gt;&lt;U&gt;&lt;STRONG&gt;pull&lt;/STRONG&gt;&lt;/U&gt;&lt;/FONT&gt; all traffic up to the physical network&lt;/EM&gt;&lt;/FONT&gt;". Traffic Routes OUT or Routes IN. There is no pull, but there is push.&lt;BR /&gt;&lt;BR /&gt;Now that I read through you last post multiple times I agree with you that your VCF-A and VCF-B NSX instance would not have each other routes in their routing tables. That is because there is usually a physical router between them and that physical router will have the two NSX-T instances routes stored in its routing table. In some cases you might be able to establish a OSPF router adjacency between NSX-V and NSX-T as long as they were both sitting on the same switch with no router between them. Then NSX-V and NSX-T will have routes for each other in their routing table.&lt;/P&gt;&lt;P&gt;All that being said.......&lt;/P&gt;&lt;P&gt;Your original post was asking if you could migrate your VMs with or without stretching the network through HCX. Now that I have more info I can more specifically answer your question.&lt;BR /&gt;You have to stretch/extend your NSX-V segments to NSX-T or the VMs will lose network connectivity once they fully land in NSX-T, unless you are planning on changing those VMs IP addresses once they get to NSX-T. NSX-V and NSX-T are separate network domains and can not attach each other subnets. HCX will create a tunnel between "V" and "T". Then HCX extension process will create a segment on NSX-T and then hair pin the network back to the NSX-V segment. Once all VMs (Sitting on the NSX-V network segment) are migrated to NSX-T then you can swing the Subnet off of NSX-V over to NSX-T (Swap the segment Gateways, shut down the NSX-V segment, advertise NSX-T segment to physical network). At that time you can remove the NSX-V segment extension in HCX.&lt;BR /&gt;&lt;BR /&gt;The other way to do it is to extend the NSX-V network segment to NSX-T. Give the NSX-T segment its own gateway address. Migrate the VMs over to NSX-T and then change the VMs gateway to the NSX-T segment's gateway. You will still have to migrate all the VMs off the NSX-V segment first before you can take down the HCX extension. The NSX-V segment still has to be shut down before you can advertise the NSX-T segment to the physical network.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 12 Sep 2022 17:29:50 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Networking-Members/Cross-Communication-testing-between-2-VMs/m-p/2928456#M233</guid>
      <dc:creator>grimsrue</dc:creator>
      <dc:date>2022-09-12T17:29:50Z</dc:date>
    </item>
    <item>
      <title>Re: Cross Communication testing between 2 VMs</title>
      <link>https://communities.vmware.com/t5/Networking-Members/Cross-Communication-testing-between-2-VMs/m-p/2927733#M230</link>
      <description>&lt;P&gt;&lt;a href="https://communities.vmware.com/t5/user/viewprofilepage/user-id/1156929"&gt;@MrVmware9423&lt;/a&gt;,&lt;/P&gt;&lt;P&gt;Your steps all look correct except for "Unextend the Network using HCX" in both your scenarios. I am not sure what you mean by "Disconnect VM1 logical switch from DLR"? I am also assuming your are using NSX-T DFW?&lt;/P&gt;&lt;P&gt;I am still not sure if your VCF3.x and VCF4.x environments are in the same network domain or if they are in separate network domains. Are you expecting to move the VMs from NSX Souce to NSX-T/Overlay on the destination side or are you going to move the VMs from physical source to the physical network on the destination side? HCX network extension is for allowing VMs to be migrated to different networking environment without changing the VMs network config (i.e. IPs, DNS, firewall, NAS, etc.). HCX network extension just "hairpins" the network traffic back to the source environment. It is essentially a VPN.&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;&lt;P&gt;You have to do one of two things before you can unextend the network. Expectation is VCF3.x is a separate Source network 'domain' &amp;amp; VCF4.x is separate destination network 'domain')&lt;/P&gt;&lt;P&gt;1. You would need to reIP the VMs to use a new IP from a subnet on the destination side (physical or NSX-T Overlay), then you can remove the network extension.&lt;/P&gt;&lt;P&gt;OR&lt;/P&gt;&lt;P&gt;2. You will have to migrate ALL VMs sitting on the source side subnet to the destination side, then swing the source side Subnet to the destination side (Datacenter. External Cloud, NSX-T, etc).&amp;nbsp; You can then remove the network extension.&lt;BR /&gt;NOTE: This step is a bit more involved based on where the subnet is being swung over to.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;If VCF3.x and VCF4.x environments are sitting in the same network domain and will NOT be using the NSX-T overlay then there is no reason to use HCX network extension services, because you can just make use of 802.1q VLAN trunking to make sure both environments can see the same subnet. You can then use HCX to migrate the VMs between the environments and your VMs will not lose network connectivity.&lt;/P&gt;</description>
      <pubDate>Wed, 07 Sep 2022 15:56:32 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Networking-Members/Cross-Communication-testing-between-2-VMs/m-p/2927733#M230</guid>
      <dc:creator>grimsrue</dc:creator>
      <dc:date>2022-09-07T15:56:32Z</dc:date>
    </item>
    <item>
      <title>Re: Cross Communication testing between 2 VMs</title>
      <link>https://communities.vmware.com/t5/Networking-Members/Cross-Communication-testing-between-2-VMs/m-p/2927566#M228</link>
      <description>&lt;P&gt;&lt;a href="https://communities.vmware.com/t5/user/viewprofilepage/user-id/1156929"&gt;@MrVmware9423&lt;/a&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;To answer your question it will depend on if your two environments are in two separate network domains or not.&lt;/P&gt;&lt;P&gt;If both environments are in the same domain then the destination side should have the VLAN/Subnet trunked down the the ESXi hosts. You will create a portgroup on the vDS for the VLAN/Subnet and attach your VM to it when you migrate it.&lt;/P&gt;&lt;P&gt;If both environments are in different Network domains or your network is not using 802.1q Trunking then you will have to extend/stretch your Portgroup over to the destination before you migrate your VMs&lt;/P&gt;&lt;P&gt;The only other way is to change the IP address of the Web VM after you migrate it then update the DNS so it can be resolved by the App/DB VMs. Might have to make some web, app, or DB changes as well depending how the Web, App or DB is setup on the VMs if you use this method.&lt;/P&gt;</description>
      <pubDate>Tue, 06 Sep 2022 20:33:58 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Networking-Members/Cross-Communication-testing-between-2-VMs/m-p/2927566#M228</guid>
      <dc:creator>grimsrue</dc:creator>
      <dc:date>2022-09-06T20:33:58Z</dc:date>
    </item>
    <item>
      <title>Re: poor performance using private network between VMs</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/poor-performance-using-private-network-between-VMs/m-p/2926307#M283537</link>
      <description>&lt;P&gt;We all need more info than what you have provided.&lt;BR /&gt;&lt;BR /&gt;Are the VMs on a single physical host or multiple physical hosts in a cluster?&lt;/P&gt;&lt;P&gt;What type of storage are the VMs sitting on? Is it external Tier 1 or 2 storage or internal SSD or NVMe disk?&lt;/P&gt;&lt;P&gt;What is the MTU of the NIC/s in the OS and/or physical switch interfaces?&lt;/P&gt;&lt;P&gt;What vNIC driver are you using? vmxnet3 or e1000?&lt;/P&gt;&lt;P&gt;What are your TCP/IP settings? LRO, TSO, LSO, Ring Buffer size, etc. You could be dropping receive/transmit packets in/out of the OS. Your ring buffers probably need to be increased to 4096 if you are trying to move a large amount of data.&lt;/P&gt;</description>
      <pubDate>Mon, 29 Aug 2022 16:53:21 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/poor-performance-using-private-network-between-VMs/m-p/2926307#M283537</guid>
      <dc:creator>grimsrue</dc:creator>
      <dc:date>2022-08-29T16:53:21Z</dc:date>
    </item>
    <item>
      <title>Re: ESXi Networking vSwitch networking issue</title>
      <link>https://communities.vmware.com/t5/vSphere-vNetwork-Discussions/ESXi-Networking-vSwitch-networking-issue/m-p/2922530#M14568</link>
      <description>&lt;P&gt;Hello Zeiktuvai,&lt;/P&gt;&lt;P&gt;You have one of these issues going on.&lt;/P&gt;&lt;P&gt;1. You may have a dup IP address issue happening. Just to make sure, I would change the IP address of the VM with connectivity issues to rule that possibility out.&lt;/P&gt;&lt;P&gt;2. Some switch interfaces do not like seeing multiple MACs which happens with multiple VMs talking out the same physical interfaces. Not sure what type of switch your ESXi host is connected to but you might need to look at STP and see if Spanning-Tree portfast is enabled at the interfaces.&lt;/P&gt;&lt;P&gt;3. check to make sure the Portgroup your VMs are using has the Forged Transmits and MAC Learning, under Security, is set to "Accept"&lt;/P&gt;&lt;P&gt;4. Your "Ring Buffers" may be running out of space on your VMs. You can check ring buffers by running the below commands from the ESXi CLi.&lt;/P&gt;&lt;P&gt;esxcli network vm list (to get WID)&lt;/P&gt;&lt;P&gt;esxcli network vm port list -w (to get "port ID")&lt;/P&gt;&lt;P&gt;vsish -e get /net/portsets/vswitch0/ports/"port ID"/vmxnet3/rxSummary&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; (Change "Port ID" with port number)&lt;/P&gt;</description>
      <pubDate>Fri, 05 Aug 2022 20:38:27 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/vSphere-vNetwork-Discussions/ESXi-Networking-vSwitch-networking-issue/m-p/2922530#M14568</guid>
      <dc:creator>grimsrue</dc:creator>
      <dc:date>2022-08-05T20:38:27Z</dc:date>
    </item>
    <item>
      <title>Re: NSX-T L2 Bridging with two different profiles</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-T-L2-Bridging-with-two-different-profiles/m-p/2920256#M15029</link>
      <description>&lt;P&gt;Sorry for the late Response sa2057.&lt;BR /&gt;&lt;BR /&gt;Not sure if you figured this out or not, If so than ignore.&lt;/P&gt;&lt;P&gt;Promiscuous Mode and Forged Transmits should be turned on for the NSX-T Bridge.&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;Are you bridging NSX-V and NSX-T to the same VLAN?&lt;/P&gt;&lt;P&gt;Dont forget that you have to run the below command on the ESXi hosts that your Edge Nodes are running on&lt;BR /&gt;&lt;BR /&gt;"esxcli system settings advanced set -o /Net/ReversePathFwdCheckPromisc -i 1"&lt;/P&gt;</description>
      <pubDate>Sun, 24 Jul 2022 15:42:11 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-T-L2-Bridging-with-two-different-profiles/m-p/2920256#M15029</guid>
      <dc:creator>grimsrue</dc:creator>
      <dc:date>2022-07-24T15:42:11Z</dc:date>
    </item>
    <item>
      <title>Re: adding a second network adapter</title>
      <link>https://communities.vmware.com/t5/Networking-Members/adding-a-second-network-adapter/m-p/2920194#M212</link>
      <description>&lt;P&gt;My bad, I copy/pasted the wrong command in my last post.&lt;/P&gt;&lt;P&gt;This is the one you run below. replace offlinebundlefile.zip with the full file name you downloaded and copied to /tmp&lt;/P&gt;&lt;P&gt;esxcli software vib install -d /tmp/offlinebundlefile.zip&lt;/P&gt;</description>
      <pubDate>Sat, 23 Jul 2022 20:33:53 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Networking-Members/adding-a-second-network-adapter/m-p/2920194#M212</guid>
      <dc:creator>grimsrue</dc:creator>
      <dc:date>2022-07-23T20:33:53Z</dc:date>
    </item>
    <item>
      <title>Re: adding a second network adapter</title>
      <link>https://communities.vmware.com/t5/Networking-Members/adding-a-second-network-adapter/m-p/2920181#M209</link>
      <description>&lt;P&gt;What version of the ESXi OS are you running? You can type "vmware -v" (without the quotes) to get version.&lt;BR /&gt;&lt;BR /&gt;The Fling web site has a down arrow that lets you select from multiple .zip versions. The error you are seeing is due to you trying to install a version that is not compliant to the version of your ESXi OS.&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="grimsrue_0-1658603941421.png" style="width: 400px;"&gt;&lt;img src="https://communities.vmware.com/t5/image/serverpage/image-id/96364i3576F3904A470A75/image-size/medium/is-moderation-mode/true?v=v2&amp;amp;px=400" role="button" title="grimsrue_0-1658603941421.png" alt="grimsrue_0-1658603941421.png" /&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;If you are going to copy the ".zip" file to /tmp then change your path when running the esxcli vib software command&lt;BR /&gt;&lt;BR /&gt;esxcli software component apply -d /tmp/offlinebundlefile.zip&lt;/P&gt;</description>
      <pubDate>Sat, 23 Jul 2022 19:21:25 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Networking-Members/adding-a-second-network-adapter/m-p/2920181#M209</guid>
      <dc:creator>grimsrue</dc:creator>
      <dc:date>2022-07-23T19:21:25Z</dc:date>
    </item>
    <item>
      <title>Re: adding a second network adapter</title>
      <link>https://communities.vmware.com/t5/Networking-Members/adding-a-second-network-adapter/m-p/2920174#M205</link>
      <description>&lt;P&gt;Did you copy the file over to the root of the "Datastore" or the root of the "ESXi Hypervisor"&lt;BR /&gt;&lt;BR /&gt;Datastore root is /vmfs/volumes/"datastore"/file.vib (esxcli software vib install -d /vmfs/volumes/"datastore"/offlinebundlefile.zip)&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;ESXi Hypervisor is /file.vib (esxcli software vib install -d /offlinebundlefile.zip)&lt;/P&gt;&lt;P&gt;As a_p_ stated you must install the the driver.zip that corresponds the the version of the ESXi OS you have installed on the server&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Also, this might seem ridiculous, but make sure your USB ports are enabled in the bios. Some servers have those turned off by default.&lt;BR /&gt;&lt;BR /&gt;NOTE: It seems to me that you might not know what a "datastore" is. That is a disk that VMs are created and run on. If you have a datastore then you probably gave the datastore a name when you created it. Use that name in place of "datastore" or "datastore1".&lt;/P&gt;</description>
      <pubDate>Sat, 23 Jul 2022 19:05:14 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Networking-Members/adding-a-second-network-adapter/m-p/2920174#M205</guid>
      <dc:creator>grimsrue</dc:creator>
      <dc:date>2022-07-23T19:05:14Z</dc:date>
    </item>
    <item>
      <title>Re: EdgeBridge get connection</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/EdgeBridge-get-connection/m-p/2915721#M14874</link>
      <description>&lt;P&gt;Hello Techzenit,&lt;/P&gt;&lt;P&gt;That question is very very broad.&lt;BR /&gt;Are you trying to determine what the vCenter portgroup is allowing/trunked through to NSX-T?&lt;/P&gt;&lt;P&gt;or&lt;/P&gt;&lt;P&gt;Are you wanting to know what segments are being bridge to what VLANs?&lt;/P&gt;&lt;P&gt;or&lt;/P&gt;&lt;P&gt;Are you looking to generate a report using an API to determine what is in use and what is not in use?&lt;BR /&gt;&lt;BR /&gt;The vCenter portgroup being used for bridging can allow ALL VLANs through 0-4096, or selective VLANs through, or a single VLAN through. It just depends on how the portgroup is configured.&lt;BR /&gt;&lt;BR /&gt;What is being allowed through is different that what is actually being used. You can allow all VLANs through, but only have a couple of NSX-T Segments bridging over to 3 or 4 VLANs.&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;&lt;P&gt;If that does not answer your question then more elaboration is needed on your main question&lt;/P&gt;</description>
      <pubDate>Fri, 24 Jun 2022 04:28:10 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/EdgeBridge-get-connection/m-p/2915721#M14874</guid>
      <dc:creator>grimsrue</dc:creator>
      <dc:date>2022-06-24T04:28:10Z</dc:date>
    </item>
  </channel>
</rss>

