Solution

My VMs stopped talking to each other after I messed with the virtual switch settings, Is this the application virtual switch causing it?

Short answer: no, it’s almost certainly not an “application virtual switch.” That term belongs to Cisco’s ACI gear — it’s a specific branded component for their datacenter fabric, not anything you’ll find in Hyper-V Manager, VMware Workstation, ESXi, or Proxmox. If you’re running a home lab or a local hypervisor and your VMs suddenly can’t see each other, what you touched was a regular virtual switch, and the fix is usually a 10-minute config check, not a reinstall.

If you don’t manage Cisco ACI hardware at work, forget the “application” part entirely. Just think of it as “the virtual switch settings,” and work through the list below in order.

Check the switch type first

This is the number one cause, and it’s an easy one to trip over without realizing it. Hyper-V has three switch types, and each behaves completely differently:

  • External — bound to a physical NIC, lets VMs talk to each other, the host, and the outside network
  • Internal — VMs can talk to each other and to the host, but not to the outside world
  • Private — VMs can only talk to each other. Not even the host can see this traffic

If you were “messing with the virtual switch” and accidentally changed the type — say, from External to Private, or created a brand new switch instead of editing the existing one — every VM attached to it loses whatever connectivity that type doesn’t support. Open Hyper-V Manager → Virtual Switch Manager and confirm the type is actually what you think it is.

Get-VMSwitch | Format-Table Name, SwitchType

VLAN ID mismatch (the sneaky one)

This trips up more people than switch type does, mainly because it’s invisible unless you go looking for it. If you enabled “Enable virtual LAN identification” on the switch or on an individual VM’s network adapter — even by accident, even just clicking through a settings dialog — that VM now only talks to other devices tagged with the exact same VLAN ID. Two VMs on the identical switch but different VLAN IDs simply won’t see each other’s traffic at all. No error, no warning, just silence.

Check each VM’s adapter settings individually:

Get-VMNetworkAdapterVlan -VMName "VM1"
Get-VMNetworkAdapterVlan -VMName "VM2"

If they don’t match (or one has tagging enabled and the other doesn’t), that’s your problem. To reset a VM back to untagged:

Set-VMNetworkAdapterVlan -VMName "VM1" -Untagged

Confirm both VMs are actually on the same switch

Sounds obvious, but if you were reconfiguring things, it’s easy to reattach one VM to a newly created switch while the other stays on the old one. They’ll look connected in Device Manager inside the guest OS, but they’re on two separate isolated networks that never touch.

Get-VMNetworkAdapter -VMName "VM1" | Select VMName, SwitchName
Get-VMNetworkAdapter -VMName "VM2" | Select VMName, SwitchName

Windows Firewall on the VMs is blocking ICMP

If ping is your test and everything above checks out, the guest OS firewall is next. By default, Windows blocks inbound ICMPv4 echo requests unless you’ve enabled “File and Printer Sharing” or added a specific rule. This one bites people constantly because it has nothing to do with the switch at all — it just happens to surface at the same time you’re troubleshooting switch settings.

New-NetFirewallRule -DisplayName "Allow ICMPv4" -Protocol ICMPv4 -IcmpType 8 -Enabled True -Action Allow

The switch got corrupted after a host reboot

Less common, but worth knowing: some Hyper-V hosts develop a genuinely corrupted virtual switch port after a Windows Update reboot. Symptoms are odd — internet works, but internal traffic between VMs (or specific apps like AD replication or file shares) silently breaks. If nothing else on this list fixes it, the workaround is to move the VMs off the switch, delete and recreate the switch port, then reattach them.

  1. Note the switch name and settings in Virtual Switch Manager before touching anything
  2. Move all affected VMs to a temporary switch (or disconnect their adapters)
  3. Delete the problematic virtual switch
  4. Recreate it with the same name and settings
  5. Reattach the VMs and test connectivity again

If you’re on VMware instead of Hyper-V

Same troubleshooting order applies, just different menus: check the vSwitch’s port group VLAN ID, confirm both VMs are on the same port group (not just the same vSwitch — port groups matter), and check the guest firewall the same way. The “External/Internal/Private” concept maps loosely to whether the vSwitch has an uplink adapter attached at all.

More Help