Networking

A Kyvenza VM connects to the network in one of two ways. The choice comes down to a single question: does anything outside this Mac need to reach the VM?

	Shared (NAT)	Bridged
Guest reaches the internet	Yes	Yes
Guest gets its own LAN address	No, it sits behind this Mac	Yes, from your router
Other devices can reach the guest	No	Yes
Works over Wi-Fi	Yes	Usually not, see below
Available in the Mac App Store version	Yes	No, that version is NAT-only

Shared (NAT) is the default for every new VM, and it is the right choice for most work. Switch to bridged only when you need inbound access.

When you need bridged

Reach for bridged networking when something outside the Mac has to start the connection:

• A service running in the guest that others use. A dev server, database, or build agent inside the VM is not addressable from a colleague's machine, a physical iPhone on the same Wi-Fi, or another host while the VM is behind NAT.
• Software that has to be a real host on the segment. Anything depending on the site DHCP server, mDNS and Bonjour discovery, PXE boot, or peer discovery between VMs running on different Macs.
• ssh from elsewhere on the LAN, at an address your router assigned, with no port mapping in between.

If the guest only needs to download packages and browse, NAT is simpler and has none of the caveats below.

Switching a VM to bridged

The VM must be stopped. Open its configuration, find Network, set the mode to Bridged, and pick the host interface to bridge onto. Start the VM and it will request an address from your router like any other machine on the network.

Kyvenza stores the interface by its BSD name (en0, en5), which is stable across reboots and language settings. If that interface is missing later, because a dock was unplugged or the VM was restored on a different Mac, Kyvenza says so and refuses to start rather than quietly moving the VM onto a different network.

Bridged networking needs a wired interface

Bridging over Wi-Fi usually does not work. The guest sends out its DHCP request and nothing ever answers, so it never gets an address.

This is not a Kyvenza limitation and not something to troubleshoot on your machine. A bridged VM puts a second hardware address behind one network port, and 802.11 access points generally will not carry traffic for it. The same VM bridged onto an Ethernet interface gets an address immediately.

Kyvenza warns you when you select a wireless interface, but it does not stop you, because a few access points are configured to allow it. If you select Wi-Fi and the guest never gets an address, that is why.

Practical options on a Mac with no Ethernet port:

• Use a USB-C or Thunderbolt Ethernet adapter, then bridge onto that interface.
• Stay on shared (NAT) and reach the service another way, for example an ssh tunnel or a reverse proxy you already run.

Finding the guest IP address

The VM detail page shows the current network mode and the guest's address, with one-click copy for the address itself or a ready-made ssh command.

An address may not appear immediately, and what that means depends on the mode:

• Shared (NAT): the VM is probably still booting. It will appear shortly.
• Bridged over a wired interface: the guest shows up once it has actually used the network. This is normal; send some traffic from inside the guest if you want it to appear sooner.
• Bridged over Wi-Fi: it will not appear at all. See the section above.

Kyvenza resolves the address by matching the guest's hardware address against the host's live network state, so it keeps up with guests that change address shortly after boot. Some Linux distributions do exactly that, requesting a fresh lease once the full network stack starts.

The Mac App Store version is NAT-only

Bridged networking requires a restricted entitlement that does not apply to App Store distribution, so the Mac App Store build offers shared (NAT) only and does not show the Network options. If you need bridged networking, use the version downloaded from kyvenza.com. VMs move between the two versions unchanged; a VM configured for bridging simply will not start on the App Store build until you switch it back to NAT.

Related

• Managing VMs for the lifecycle actions and configuration rules
• Diagnostics & Troubleshooting when a VM will not start