VirtualBox on Windows: bridged NIC naming, Wi-Fi limits, headless console typing, SSH-started VMs, leftover .sav files

Observed September to October 2026 with VirtualBox 7.2.16 to 7.2.20 on Windows 10 hosts, managing a headless Linux-based appliance VM entirely through VBoxManage over SSH (remote shell: Windows PowerShell 5.1). Network addresses and host names are omitted.

The bridged adapter name must be the InterfaceDescription

VBoxManage modifyvm <vm> --bridge-adapter1 "Ethernet" is rejected when the value is the Windows connection alias:

Interface "Ethernet" doesn't seem to exist

The value that works is the adapter's InterfaceDescription, character for character, including any numbered suffix Windows added, for example Intel(R) Ethernet Connection (7) I219-LM. The exact string is printed by VBoxManage list bridgedifs. In PowerShell the call also needs the call operator and a quoted path (& "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" ...) or the shell reports Unexpected token.

Bridging over Wi-Fi does not work, and a bridge stays on its adapter

• A bridge over a Wi-Fi adapter cannot carry guest traffic: an 802.11 access point drops frames whose source MAC is not the associated station. A session reported this as already proven on that host. A second reason given is that many USB Wi-Fi adapters refuse the promiscuous mode that bridging needs. The second point was stated as a likelihood and not tested per adapter.
• A bridge is pinned to an adapter by name. When the wired NIC lost its cable, the host stayed reachable over a USB Wi-Fi adapter, while the VM, still bridged to the wired NIC, had no network. VirtualBox still showed the cable as connected. The VM itself was healthy.
• The adapter can be switched on a running VM: VBoxManage controlvm <vm> nic1 bridged "<InterfaceDescription>".
• Measured after moving the VM back to a wired bridge: an HTTP API on the guest averaged 10 ms, against 455 ms average with peaks of 1.7 s over the USB Wi-Fi path.
• NAT with port forwards works but breaks mDNS and broadcast based discovery on the LAN, which matters for a guest that relies on discovery.

Cloned VM: the same MAC on two VMs

Copying the virtual disk and registering it as a second VM on another host kept the original MAC address (set explicitly with --macaddress1 <12 hex digits> so that a DHCP reservation carries over). While both VMs were running, they shared one MAC and one IP address for about 20 minutes. The old VM had been started again by a logon scheduled task on the previous host. The fix was to disable that task and keep the old VM powered off. The sources do not describe how the network device itself behaved under the clash beyond the shared MAC and IP.

Typing into a headless console without Guest Additions

Clipboard paste does not reach the VM console without Guest Additions, and the appliance OS has none. Input can be sent from the host instead:

VBoxManage controlvm <vm> keyboardputstring 'some command'
VBoxManage controlvm <vm> keyboardputscancode 1c 9c

The first types the text without submitting it; the scancode pair 1c 9c is Enter. controlvm <vm> screenshotpng <file> captures the console; screenshots lag, so a command can be registered while the picture still looks unchanged.

• keyboardputstring emits US-layout scancodes. Letters, digits and common punctuation worked; characters such as ~, ^, a backtick and accented letters can arrive wrong, which for a Wi-Fi passphrase shows up as a failed association with no obvious cause (stated as a risk by the session, not reproduced).
• In PowerShell, single quotes keep $ from being expanded inside the typed string.
• PSReadLine writes typed commands to ConsoleHost_history.txt in plain text, so a command that contains a secret ends up on disk. Set-PSReadLineOption -HistorySaveStyle SaveNothing in that session stops it. A passphrase typed this way was also echoed in cleartext on the VM console in one session.

startvm over SSH can die with the session

VBoxManage startvm <vm> --type headless run from an SSH session may die when the session ends (the note says "can", not "always"). The working pattern was a scheduled task with no trigger, run as the owning user with logon type S4U and highest privileges, started by Start-ScheduledTask. That runs in session 0 and survived disconnects. A boot-triggered variant of the same task, with a one-minute delay, restarted the VM unattended after a host reboot in under four minutes; it needs no stored password, unlike VBoxAutostartSvc, whose install takes a Windows password via --password-file in 7.2 (--password= is rejected).

unregistervm --delete leaves saved-state files

VBoxManage unregistervm <vm> --delete removed the registration and the VDI but left 21 .sav saved-state files, 8.4 GB in total, in the machine folder's Snapshots directory. The cleanup looked finished after freeing 10.7 GB. Removing the folder by hand freed the rest, 18.9 GB overall. Checking the folder size after unregistering is the sanity check the note recommends. Why the files were left was not investigated.