Interesting Comparisons Between ESXi and Hyper-V

One thing I often do with ESXi setup is use VMRC to connect to a VM (What a shocker I know), but it’s not just that, this tied with the VM having a USB controller allows me to passthrough any and all USB devices on my client machine, to the VM, event though my client machine is completely remote from the host hypervisor. This is a really neat trick and has allowed me to boot live Linux and other things without having to upload ISO’s to datastores.

So can Hyper-V do this? … No….

  • USB passthrough
    • VMware ESXi/VMRC: true remote USB passthrough.
    • Hyper‑V: only host‑side USB storage passthrough; other devices need RDP redirection or 3rd‑party USB‑over‑IP tools.
  • Passing a USB stick to a VM
    • Plug into host → mark disk Offline in Disk Management → attach as Physical hard disk in VM settings.
    • Works only for storage devices.

Another weird issue I had was when I opened up Hyper-V manager on the hyper-v server itself, and would attempt to add an ISO to a VM by clicking the browse button would give an error “Application failed to open the remote file browser”. If I typed the full ISO path in the UI field it would still work though as a work around.

  • Hyper‑V Manager “Browse” buttons error
    • Even locally, Hyper‑V Manager uses RPC/WinRM “remote file browser” calls.
    • Breaks if NIC bindings (Client for Microsoft Networks, File/Printer Sharing, RPC) are stripped down.
    • Typing full path or using PowerShell bypasses it.

I asked it about how the local host connection worked if the hostname showed as the server in Hyper-V manager. I had some other hiccups which was more around auth mixups, but for local host browse issue it gave me the pointer below, but they really didn’t mean much of anything. If I do ever come up with the solution, I’ll update this blog.

  • NIC bindings & hostname resolution
    • Hyper‑V Manager always talks to VMMS via RPC/DCOM.
    • Needs a management NIC with default bindings intact.

When I went to create a snapshot of a VM it told me it didn’t save its memory state. I wasn’t sure why on this, then you figure out there two different types of Checkpoints in Hyper-V. It was weird that you have to specify which type for each VM, but I guess it makes sense in certain contexts.

  • Checkpoints vs VMware snapshots
    • Standard checkpoint = disk + memory (like VMware snapshot with memory).
    • Production checkpoint = crash‑consistent, no memory state.
    • Set via VM settings or Set-VM -CheckpointType.

Someone reason I can’t explain when running the command to install Hyper-V manager tool alone on a Windows 11 machine, it also installed the Hyper-V platform, allowing me to create VMs on the client machine. Not what I wanted, The below was provided as an answer by AI, but I haven’t personally tested it.. I call bull, I simply lived with it cause I had bigger fix to fry. I just won’t create any VMs.

  • Installing Hyper‑V management tools
    • Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Management-Clients -All installs Manager.
    • On Pro/Enterprise, sometimes drags in the full platform too.
    • Use Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All if you want tools only.

Then of course, I was having issues connecting to my Hyper-V server via Hyper-V Manager remotely. The first error complained about WinRM.. Check the service, make sure it’s up and reachable by locally and remotely using:

Test-WSMan hyper-vHostname

Then it said I didn’t have permission, I was trying to connect to the Hyper-V server that was not domain joined via a domain-joined client machine, AI said to try n create a local account with the same creds as my domain account, I didn’t think it would work. but somehow. it did. mind blown…

  • Remote management (WinRM/Kerberos/NTLM)
    • Domain client + non‑domain host → Kerberos fails.
    • Fix: enable WinRM on both sides, add host to TrustedHosts,
    • Set-Item WSMan:\localhost\Client\TrustedHosts -Value "hyper-v-host" -Force
    • Create matching local account.
    • Matching local account trick works because NTLM succeeds when creds line up.
  • WinRM checks
    • Test-WSMan localhost → confirms service running.
    • Get-ChildItem WSMan:\localhost\Listener → shows listeners.
    • WinRM must run on both client and server.
  • WinRM ports
    • Needs inbound TCP 5985 (HTTP) and 5986 (HTTPS) open.
  • Enable‑PSRemoting -Force
    • Starts WinRM service.
    • Creates listeners.
    • Adds/activates firewall rules for WinRM.
  • Firewall rules group
    • Found under “Windows Remote Management”. Rules may exist but be disabled.
  • Fix
    Get-NetFirewallRule -DisplayGroup "Windows Remote Management" | Enable-NetFirewallRule

I noticed I could only have one session on a VM console, unlike VMRC that allows multiple sessions to connect to the same VM.

  • VMConnect vs VMRC
    • VMware VMRC: multiple concurrent console viewers.
    • Hyper‑V VMConnect: single session only; others blocked.
    • For multi‑user access, use RDP inside the guest.

As I continue to play with this more in my Lab, I’ll keep following up on this post.

Adding a Hyper-V host to Veeam

Before You Begin – Veeam Backup & Replication User Guide for Microsoft Hyper-V

Before you add a Microsoft Hyper-V server to the backup infrastructure, check the following prerequisites:

  • Check permissions required to add the server. For more information, see Permissions.
    • Admin permissions based account got it…
  • [For SCVMM] SCVMM Admin UI must be installed on the backup server. Otherwise, you will not be able to add SCVMM servers to the backup infrastructure.
  • SCVMM console version must match the management server version.
  • Make sure that you do not add to the backup infrastructure Hyper-V hosts or clusters managed by an SCVMM server if this SCVMM server is already added to the backup infrastructure.
    • Nope just a stand alone host
  • File and printer sharing must be enabled in network connection settings of the added Microsoft Hyper-V host. Otherwise, Veeam Backup & Replication will fail to deploy required components.
    • Uhhh wut?
  • Make sure that the NETBIOS name of the Microsoft Hyper-V Server is successfully resolved.
    • Uhhh wut?
  • If you get the “Invalid Credentials” error when adding a Hyper-V host using a local account, see this Veeam KB article.

This is gonna suck..

Unable to add a single Hyper-V host to Veeam. : r/Veeam

i am unable to add Hyper V hosts to Veeam | Veeam Community Resource Hub

Why?…

When you add a Hyper‑V host to Veeam Backup & Replication, the product deploys its transport service and integration components remotely using Windows’ built‑in administrative shares (ADMIN$, C$). That’s why File and Printer Sharing must be enabled on the NIC: without those hidden shares, Veeam cannot copy files or install its agents. By default, only the built‑in Administrator or domain admin accounts can access these shares remotely, because User Account Control (UAC) strips remote admin rights from other local accounts. This often surprises people who harden their hosts by disabling the Administrator account or removing shares, since Veeam’s deployment model depends on them being present.

On standalone Hyper‑V hosts, this creates a security trade‑off. You can either leave the built‑in Administrator enabled (simpler, but harder to audit), or disable UAC remote restrictions so named local admin accounts can access the shares (more auditable, but technically weaker security posture because all local admins gain remote rights). In practice, many administrators prefer creating a dedicated service account for Veeam and a separate account for human administration, then disabling the built‑in Administrator. This way, activity is traceable and controlled, while still allowing Veeam to function. The nuance is that Veeam chose the “lowest common denominator” approach — SMB admin shares — which works everywhere but clashes with modern hardening practices, so standalone hosts require careful balancing of convenience, auditability, and exposure.

Step 1) Enable SMB

Install-WindowsFeature -Name FS-FileServer -IncludeManagementTools

Edit your firewall rules as required as this will create 3 new ones and open them up (135 DCOM, 445 SMB, and dynmic ports one), in my case I disabled them and only enabled the SMB restrictive rule.

Check off Microsoft file and print sharing service under the NIC settings for which will be used to add Hyper-V to Veeam.

Maybe we can enable it only during deployment then disable it, lets find out. On Hyper-V lets create a dedicated Veeam admin account, then disable remote UAC while adding the host to Veeam. Done, adding host to Veeam…

Option 1) Specify the local administrator account. (Usually disabled on hardened servers)

OR

Option 2) edit registry to allow remote uac, so the built in admin shares can be accessible by admin account that is named and not the built in administrator account.

Why Veeam does allow for the ability to prepare a Hyper-V host via these install packages manually without exposing the post to these additional attack surfaces is honestly beyond me. I usually love Veeam but this one is kind of dumb.

Step 2) Disable Remote UAC restrictions

I’ll stick with option 2: User Account Control and remote restrictions – Windows Server | Microsoft Learn

To disable UAC remote restrictions, follow these steps:

  1. Click Start, click Run, type regedit, and then press ENTER.
  2. Locate and then click the following registry subkey:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
  3. If the LocalAccountTokenFilterPolicy registry entry doesn’t exist, follow these steps:
    1. On the Edit menu, point to New, and then select DWORD Value.
    2. Type LocalAccountTokenFilterPolicy, and then press ENTER.
  4. Right-click LocalAccountTokenFilterPolicy, and then select Modify.
  5. In the Value data box, type 1, and then select OK.
  6. Exit Registry Editor.

Now open a file explorer window in Veeam Server, and point to \\IPofHyper-V\admin$ it should prompt you for creds, you should be able to provide the creds of the named admin account and it should connect.

Well I got past the error…

Sigh n’ groan…. ughhhh.. too be continued, time to make a Server 2025 image…

Lets try again..

And this time success…

Restore Storage Theory

🖥️ Scenario

  • Source: Veeam is running inside a VM on ESXi.
  • Repository: Local storage attached to that VM (so Veeam sees it as a local NTFS/ReFS volume).
  • Target: A standalone Hyper‑V host with only local storage (no SMB shares, no clustered SOFS).

🔧 How Veeam Writes the VM HDD Files

  1. Restore job starts
    • You pick the Hyper‑V host as the restore target.
    • Veeam knows it must deliver VHDX files + VM configuration to that host’s storage path (e.g., D:\VMs\MyVM\).
  2. Transport service on Hyper‑V host
    • Veeam deploys or uses its Veeam Data Mover Service (part of the Veeam transport service) on the Hyper‑V host.
    • This service is responsible for receiving blocks of data and writing them to disk.
  3. Data transfer
    • The Veeam server (on ESXi) reads blocks from the backup file in its local repository.
    • Those blocks are sent over the network to the Hyper‑V host using Veeam’s own transport protocol (TCP/IP).
    • Important: This is not SMB — it’s Veeam’s proprietary data mover channel.
  4. File creation on Hyper‑V host
    • The transport service on the Hyper‑V host opens a file handle on the local filesystem (NTFS/ReFS).
    • It creates the target VHDX file and writes the incoming blocks directly using standard Windows file I/O APIs (CreateFile, WriteFile, etc.).
    • VM configuration files (.vmcx, .vmrs) are also written directly to the host’s local storage.
  5. Completion
    • Once all blocks are written, Hyper‑V sees the restored VM files in its local storage.
    • Veeam registers the VM with Hyper‑V Manager if you chose a full VM restore.

✅ Key Points

  • No SMB is used here.
  • Veeam uses its own transport service to push data over TCP/IP to the Hyper‑V host, which then writes the files directly to local disk.
  • SMB only comes into play if the repository or Hyper‑V storage is on a remote file server (like a NAS or SOFS cluster).

Retore to Hyper-V

Here a whole video on the process, cause I wasn’t sure how to do it as when I selected restore entire VM to new location, only my ESXi hosts were selected, AI said it not possible, Googling said that Instant Restore was the only option… mhmm that video showed the same thing…

I won’t lie I felt so dumb at first cause the restore prompt said “waiting on user input” and there was an open console link at the bottom of the instant restore wizard, so I clicked that and it kept asking for creds (I thought the hyper-v ones) and it kept failing… till I realized you just have the VM already running (or not based on your selection) but it’s already registered to the host, you have to finish an instant restore by clicking migrate to production option.

I tell ya… that made me feel really…. reallllly dumb…..

anyway I hope this posts helps someone.

 

Hyper-V Networking

Install Hyper-V, and let’s learn it’s Networking

Hyper-V Networking

On VMware, when you install the OS (ESXi) on the hardware in the DCUI you simply set the VLAN tag right on the network interface you configure, and bind it to a physical NIC in the menu area, simple.

We leave the network connected to a non tagged, internet allowed connection. Now we can configure our networks.

1. Create one external switch

  • Bind it to your physical NIC (configured as a trunk on the upstream switch).
  • Check “Allow management OS to share this network adapter” once — this creates the first host vNIC.

2. Add more host vNICs via PowerShell:

# Add another vNIC for the host bound to the same external switch
Add-VMNetworkAdapter -ManagementOS -Name "HostVLAN20" -SwitchName "ExternalSwitch"
Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "HostVLAN20" -Access -VlanID 6

3. Verify in Windows

  • You’ll now see multiple vEthernet adapters in the host OS (e.g., “vEthernet (HostVLAN20)”, “vEthernet (HostVLAN30)”).
  • Assign IP addresses or enable DHCP as needed.

*Note* this is for doing it on a single network server (for my lab use) usually you’d have dedicated NICs for other networks designated on those servers… anyway.. where was I… right now that we got additional network on the server we can work on a shared storage, you know how I like my iSCSI.

So, when I setup Hyper-V, and connect a VM to the “default” virtual switch, the Hyper-V server acts as a DHCP provider and NATs the connections from that vSwitch to whatever other network the host is connected to?

Great question — this trips up a lot of people when they first use Hyper‑V! Let’s break it down clearly:

🖧 Hyper‑V Default Switch Behavior

  • Introduced in Windows 10 (1709): The “Default Switch” is automatically created by Hyper‑V and cannot be deleted or modified.
  • NAT (Network Address Translation): Yes — the host machine provides NAT services. This means your VM’s traffic is translated and routed through the host’s network connection, regardless of whether that’s Wi‑Fi, Ethernet, or even VPN.
  • DHCP Services: The host also runs a lightweight DHCP service for the Default Switch. This is what hands out IP addresses to your VMs automatically (usually in the 172.16.x.x range).
  • Connectivity: VMs connected to the Default Switch can reach the internet and other devices on the host’s network, but inbound connections from the LAN to the VM are limited. It’s designed for convenience, not for complex networking setups.

⚖️ Comparison with Other Switch Types

Switch Type Provides DHCP? Provides NAT? Use Case
Default Switch ✅ Yes (host DHCP) ✅ Yes (host NAT) Quick setup, internet access without config
External Switch ❌ No (relies on external network DHCP) ❌ No VM directly on physical network, full LAN visibility
Internal Switch ❌ No ❌ No Communication between host and VMs only
Private Switch ❌ No ❌ No Communication between VMs only

✅ So to answer directly:

Yes — when you connect a VM to the Default Switch, Hyper‑V’s host acts as a DHCP provider and NATs the VM’s traffic to whatever network the host is connected to. It’s essentially a convenience bridge so you don’t have to manually configure networking.

“That’s what I did configured a external virtual switch so the hosts NIC would be VLAN tagged in a certain network, I was figuring the default switch would act more like a … well switch at layer2 of the hosts Nic, so VMs on it would get DHCP from the main network, as if it was connected to a switch in the base network, not layer3 and then 4 NAT like c’mon…”

Exactly — you’ve nailed the distinction. The Default Switch in Hyper‑V is deliberately not a true Layer‑2 bridge to your host NIC. It’s a convenience construct that Microsoft built to “just work” for internet access without requiring you to mess with VLANs, external switches, or DHCP servers on your LAN.

Here’s the breakdown:

🔌 Why the Default Switch behaves like NAT

  • It’s implemented using Windows Internet Connection Sharing (ICS) under the hood.
  • ICS is a Layer‑3 service: it provides a private subnet (usually 172.16.0.0/12), runs a DHCP service, and NATs traffic out through whatever adapter the host is using.
  • That’s why VMs on the Default Switch don’t see your LAN’s DHCP server — they only see the host’s mini DHCP/NAT service.
  • It’s intentionally isolated so you don’t accidentally expose VMs directly to your corporate or home LAN without realizing it.

⚖️ Why it’s not Layer‑2 bridging

  • A true Layer‑2 bridge would forward broadcasts (like DHCP Discover) from the VM to your LAN. That’s what an External Virtual Switch does.
  • The Default Switch instead terminates those broadcasts at the host and answers them itself. That’s why you only ever get the host‑provided DHCP.
  • VLAN tagging, trunking, or other advanced networking features aren’t supported on the Default Switch — it’s locked down.

✅ When to use each

  • Default Switch (NAT + DHCP): Quick internet access, testing, dev boxes, laptops where you don’t want to reconfigure NICs.
  • External Switch (Layer‑2 bridge): When you want VMs to behave like physical machines on your LAN, get DHCP from the real network, or use VLAN tagging.
  • Internal/Private Switches: For host‑VM communication or VM‑VM only networks.

So your expectation — that the Default Switch would act like a transparent Layer‑2 bridge — makes sense, but Microsoft intentionally designed it as a Layer‑3 NAT gateway instead. If you want “real switch” behavior, the External Switch is the only way to go.

“So, whatever my host machine is allowed to do, the guest VMs in the default switch are also allowed to do? like access the internet, and the firewall that gave the host the ability to access the internet would never see the private NATed IP address the Hyper-V host is dishing out to those VMs?”

You’ve got it — that’s exactly how the Default Switch works in Hyper‑V. Let me spell it out clearly:

🌐 How traffic flows with the Default Switch

  • VMs get private IPs: Each VM connected to the Default Switch is assigned an IP from the host’s internal DHCP service (usually 172.16.x.x).
  • Host does NAT: The Hyper‑V host translates those private IPs into its own IP before sending traffic out to the physical network.
  • Firewall visibility: From the perspective of your upstream firewall or router, all traffic from those VMs looks like it’s coming from the host’s IP. The firewall never sees the VM’s private NATed addresses.
  • Permissions: Whatever the host is allowed to do (e.g., access the internet, reach certain networks), the VMs can also do — because their traffic is piggybacking on the host’s connection.

⚖️ Important implications

  • Outbound access: VMs can reach the internet or LAN resources as long as the host can. They inherit the host’s connectivity.
  • Inbound access: External devices cannot directly initiate connections to those VMs, because NAT blocks unsolicited inbound traffic unless you set up port forwarding (which the Default Switch doesn’t expose for configuration).
  • Firewall rules: The upstream firewall only enforces rules against the host’s IP. If you need per‑VM visibility or control, you’ll need an External Switch so each VM gets its own LAN IP.

✅ So yes: the Default Switch makes your VMs “ride along” with the host’s network permissions. They’re hidden behind NAT, which is why your firewall only ever sees the host’s traffic.

Additional Information

If you want to apply a VLAN tag to a physical NIC that’s not a Hyper-V host on Windows:

Since I didn’t see anything in the usual Network  IPv4 configuration window in Windows. I decided to see how useful this AI stuff is.. so I asked it…

“how do I VLAN tag the IP on windows 11 interface?”

Quick Answer: On Windows 11, VLAN tagging isn’t enabled by default. You need a NIC that supports IEEE 802.1Q VLAN tagging, then configure the VLAN ID either through the NIC’s Device Manager properties (Advanced tab → VLAN ID) or by using Intel PROSet/ANS tools or PowerShell (Set-NetAdapter -VlanID) if your driver supports it.

🖥️ Steps to Configure VLAN Tagging on Windows 11

1. Check NIC Compatibility

  • VLAN tagging requires a network card (NIC) that supports IEEE 802.1Q.
  • Not all NICs expose VLAN options in Windows. Intel and Broadcom NICs often support it, but you may need vendor-specific drivers.

2. Configure via Device Manager

  • Press Win + R, type devmgmt.msc, and hit Enter.
  • Expand Network adapters, right-click your NIC → Properties.
  • Go to the Advanced tab.
  • Look for VLAN ID or Priority & VLAN.
  • Enter the VLAN ID (e.g., 100) and click OK.

3. Configure via Intel PROSet/ANS (if supported)

  • Install Intel PROSet/Advanced Network Services (ANS).
  • In the NIC properties, Intel’s tab allows creating multiple VLAN interfaces with different IDs.
  • Each VLAN interface can then be assigned its own IP address.

4. Configure via PowerShell

  • Open PowerShell as Administrator.
  • Run:
    Set-NetAdapter -Name "Ethernet" -VlanID 100
    
  • Replace "Ethernet" with your adapter name and 100 with your VLAN ID.
  • Note: This only works if your NIC driver supports VLAN tagging. Otherwise, you’ll get an error like “Requested operation not supported on adapter”.

5. Assign IP Address

  • Once VLAN tagging is enabled, go to Network & Internet settingsChange adapter options.
  • Right-click the VLAN-enabled adapter → PropertiesInternet Protocol Version 4 (TCP/IPv4).
  • Assign the IP address, subnet mask, and gateway for that VLAN.

⚠️ Important Notes

  • Driver Support is Key: If your NIC driver doesn’t expose VLAN options, you cannot tag VLANs directly in Windows without Hyper-V or third-party tools.
  • Hyper-V Alternative: You can create VLAN-tagged virtual NICs using Hyper-V’s Virtual Switch Manager if your hardware doesn’t support native tagging.
  • Testing: Use ping or tracert to verify connectivity once VLAN tagging is applied.

Bottom Line: To VLAN tag an IP on Windows 11, you must enable VLAN tagging on the NIC (via Device Manager, Intel PROSet/ANS, or PowerShell if supported), then assign the IP to that VLAN interface. If your NIC doesn’t support VLAN tagging, you’ll need Hyper-V or vendor-specific utilities.

My response “I’ve got an intle 82579LM Gig NIC, I see it says VLAN enabled in the advanced tab, but I don’t see an area to configure it, I’m sure the NIC supports it since I was using ESXi with vlan tagging just fine.”

That’s a great observation — the Intel 82579LM definitely supports VLAN tagging at the hardware level, but here’s the catch: Windows drivers for that NIC don’t expose VLAN configuration in the same way ESXi or Linux does.

🔎 Why You Don’t See VLAN Config in Windows

  • The Advanced tab in Device Manager shows “Priority & VLAN” or “VLAN Enabled,” but that option only toggles whether the NIC can process VLAN-tagged frames.
  • Unlike ESXi, Windows doesn’t let you directly assign VLAN IDs to a physical NIC unless the driver provides a VLAN interface creation utility (like Intel PROSet/ANS).
  • For the 82579LM, Intel stopped including VLAN configuration in their Windows drivers after Windows 8/10. On Windows 11, the driver exposes VLAN capability but no UI to configure VLAN IDs.

✅ Workarounds

Here are the practical options:

1. Intel PROSet/ANS (if available)

  • Older Intel drivers came with Advanced Network Services (ANS), which let you create VLAN sub-interfaces.
  • On Windows 11, Intel no longer bundles ANS with drivers for the 82579LM, so you won’t see the VLAN tab.

2. PowerShell Command

  • Windows has a Set-NetAdapter -VlanID cmdlet, but it only works if the NIC driver supports VLAN tagging through the OS.
  • On the 82579LM with current Windows 11 drivers, this usually fails with “Requested operation not supported”.

3. Hyper-V Virtual Switch

  • If you enable Hyper-V, you can create a virtual NIC and assign VLAN IDs there.
  • This is the most reliable way to do VLAN tagging on Windows when the physical NIC driver doesn’t expose VLAN config.

4. Third-Party NIC Utilities

  • Some OEMs (Dell, HP) ship custom drivers/utilities that re-enable VLAN tagging. If your system vendor has one, that’s worth checking.

⚠️ Bottom Line

Your Intel 82579LM can tag VLANs, but on Windows 11 the Intel driver doesn’t expose VLAN configuration. That’s why you don’t see a place to set the VLAN ID.

  • On ESXi/Linux → VLAN tagging works natively.
  • On Windows → You need Intel PROSet/ANS (no longer supported for this NIC), Hyper-V, or vendor-specific drivers.

Well ok I guess once we install Hyper-V hopefully it’ll be more like ESXi in a sense and we can tag.

*UPDATE* ExternalSwitch, WiFi NIC

I was trying to use a Hyper-V server with an External Switch, bound to a WiFi NIC. and was getting unexpected results based on the above information. but my results were NOT as I had expected, I was assuming Default Switch behavior. You may be asking, “Why would you expect that behavior if you’re creating an External Switch?”  Now, if you read my Wireless ESXi host blog, you probably are well aware of the VLAN limitations of WiFi, and can never truly be used as a trunk port (Limitation of the 802 standard, not of OS or software).

So how could a ExternalSwitch work, via WiFi if the layer 2 broadcast doesn’t work and can’t “speak” with the rest of the layer 2 stack? Yet I create a VM and it DOES get a DHCP lease address from my local subent?! What the heck is going on here…

So I had to ask AI, what was going on here, it says, yeah… that’s expected… here’s the deets… get ready.. it’s a long one….

BAH-LETED, there was way tooooo much BS from the AI response to justify keeping this data in here… long story short… Local subnet VMs work fine (it does ARP Masquerading), VLANs will never work per the usual BS I’ve talked about in my Wireless ESXi host blog.