[Solved] How To Expose Virtual Machines to local Network

What I am trying to do is simple as hell on vmware but no so straight forward (that I can find) to do with kvm on CentOS 8 via Cockpit.

When I create a virtual machine I want that vm to appear in the same subnet as the host. I want it to look like a regular device on my network.

What must I do to accomplish this?

From what I read online I think I have to use/setup a new bridge interface but I was unable to get this working due to a lack of understanding, created a loopback broadcast, fucked up my network temporarily and then had to roll it back.

If someone could provide an example of a working XML I would be very grateful.

1 Like

Use macvtap devices in bridged mode.

    <interface type='direct'>
      <mac address='52:54:00:72:a5:28'/>
      <source dev='enp37s0' mode='bridge'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>

Adjust for MAC addresses and interfaces.

In virt-manager, this is just selecting an option from a dropdown.


Thank you very much for this reply @imhigh.today.

I am doing this on a server and I have no GUI its just via CLI so I do not think I can use virt-manager.

I will look into the information you provided for further reading.

1 Like

Can confirm, it now works.

Holy damn you are a legend.


@imhigh.today thanks a ton bud. Have a badge, and perma Regular status. This place is what is it because of awesome people like you.

1 Like

That bit which says “in most configurations, does not work for host to guest communications” does that mean Windows does not play well with others?

Or does it mean your guest has to use the interface to go out to a switch, to send packets back down the same pipe back to the interface for the host?

From what I can see it sends all traffic from the nic I defined it to listen on. This will be very useful should I seek to setup a failover lagg in the future.

1 Like

Aha… I found this a pain in the balls as well. I simply set up a pfsense box with a dedicated physical NIC and set up an internal only subnet behind it, and routed that :smiley:

Will need to set things up this way at home, where I don’t have multiple NICs :slight_smile:


Glad I wasn’t the only one having this problem (sort of).

I thought to myself:

“Man, I can’t be the only guy on the planet trying to do this what am I not getting?”


Yeah, VMware makes this super easy. As does virtualbox…

Yeah IK literally like 3 clicks.

  • cockpit doesn’t even have this functionality yet (it is on roadmap though)
  • documentation and posts about this suck
1 Like

doing this on a server and I have no GUI its just via CLI so I do not think I can use virt-manager.

Actually, you can. :slight_smile: Most of the boxes I manage are headless.

virt-manager is a libvirt API frontend. It can connect to remote libvirtd instances and exchange information over SSH via the API.

Any Libvirt API clients can be used at the same time. Changes made in Cockpit reflect in virt-manager and vice versa, since both are just changing the state of the libvirtd on the system running the virtual machines.

You just configure the client on your local workstation or laptop with multiple destinations and initiate connections to them as needed. You can see multiple remote vmhosts configured in this setup.

1 Like

Nope, has nothing to do with Windows. This method should work just fine for Windows VM’s as well, and since Windows doesn’t run libvirt natively, you can’t run into host-guest communication issues due to this.

What that warning refers to is host-guest communication. When you start up a virtual machine in NAT mode, a routing rule is put into place that allows you to access it via standard TCP/IP connections. Once your machine is running, you can open a terminal on your local machine and SSH into it’s NAT-based IP address.

When you use a macvtap device, that routing rule isn’t put into place, so attempting to SSH into the virtual machine fails with “No route to host”.

But that’s not a big deal because the workaround is easy enough. If you want access via your local machine and via the bridged mode setup, you can just add a second virtual NIC. One using bridged macvtap, and one using NAT.

1 Like

Thanks for that dude

Update: as of today with the release of CentOS 8.2 it is now possible to configure this way of networking through the Cockpit web GUI as the base Cockpit version has now been updated but let this thread stand as a reference in case any poor soul needs to configure it manually.

1 Like

@imhigh.today is there a way for vm guests to talk to each other?

I did some further reading and it looks like this is by design.

I have now run into a situation where I would like vm-1 to be able to send frames to vm-2.

I forgot about this.
I never had any luck vis a vis guest to host.
All the nic options in virtual-manager were macvtap , all with “bridge” mode default, no “Nat” available. There was an option to pass through nics, but the problem was not reaching the internet, it was reaching the host, so I didn’t bother. :frowning:

It wasn’t till I checked the networking page in cockpit that I saw an easy one click “make bridge” button.

Then choosing the bridge interface allows my guests to talk to the host And the network.

I guess I should have created a bridge earlier, through ip or whatever, but all the listed nic’s in the virtual-manager interface had bridge mode as default.
Not sure why I was getting this on Ubuntu, but one click in cockpit seems all I needed.

Sorry, forgot to mention multiple vm’s/guests sharing the same bridge0 are able to communicate to each other, the host, or the internet.
Using that one click bridge mode on cockpit.

macvlan in bridge mode with an ip <— for host and use to conatct VMs (and outside world for that matter)

macvtap1 in bridge mode (ip in guest vm1) <— for VM-1
macvtap2 in bridge mode (ip in guest vm2) <— for VM-2

Now you can crosstalk everywhere. Simpler than bridging and tun/tap combo.