Qemu/KVM bridge network with Virt-manager

Hello !

Host: Leap 15.1
Guest: Leap 15.2 server
Platform: Qemu/KVM managed by Virt-manager

Goal: guest connected to host in the same Lan and is pingable from Host machine.

Results: Guest can connect to internet but Host pinging shows target unreachable.

I had researched it for hours and couldn’t get it to work. While with Virtualbox, it was literally a pull down option to choose bridge/NAT. I don’t know if I had missed something following all kinds of info on the internet.

What are the basic steps to do it with opensuse? If it’s very very complicated maybe I should give up.

This should explain: https://wiki.libvirt.org/page/VirtualNetworking#NAT_mode

I give up and go back to virtualbox.

unreachable means firewall blocking icmp or unix based traceroute or dhcpv6-client is disabled. check your firewall for ipv6/icmp settings. enable firewall-cmd log-denied and see whats showing

For me, that just works.

Results: Guest can connect to internet but Host pinging shows target unreachable.

I never had that happen.

I’ll note that I install KVM via the Yast virtualization options. And when I do it that way, Yast sets up the needed bridging.

I seem to recall that with Leap 15.1, I could not find those options. So I went looking in Yast Software Management and installed some stuff. That added the Yast virtualization options, but they did not do anything. So I unistalled something (I don’t remember which), and tried again. This time, Yast offered to install KVM and did setup the network bridge.

For me, the lesson is to only install the Yast virtualization component, and then use that to install everything else.

virt-manager is the best virtualization host for linux! virtualbox, vmware… are slower than virt-manager. and yes i agree with @nrickert, on opensuse when you are installing virt-manager do it thru yast, cause unlike ubuntu or centos you can miss some pkgs.

Unreachable means that the needed network space is not configured and available.
If you were actually being blocked, you would see a message saying more or less that is the problem.


If you use the YaST virtualization install module,
You’ll be presented with an offer to install a br0 device which is a bridge in bridging mode… ie Your Guest with br0 configured for networking will appear and function like any other physical host on your network and can self-configure if you have a DHCP server if available.

Do not install QEMU, KVM or Xen by pattern or by installing those packages… Use the YaST module to be set up as quickly as possible with a working configuration.
If you’re experienced and expert, you can avoid using the YaST module.


Technically, to keep your terminology clean you should refer to virt-manager as an application or virtualization tool or user-mode tools or something similar.
Generally speaking, the word “host” should be used only when referring to a machine on the network, whether physical or virtual.


unreachable is the packet you are receiving back from host, as notification. this means that icmp or unix style traceroute requests are silently blocked by host. all depends how firewall configured. if you dont want to get unreachable you must allow unix style traceroute, ipv6 and unreachable!

using yast module will install complex pkgs if not you must install every pkg manually via zypper -> libvirt pkgs not a single pkg and only installing virt-manager will not give a expected result, all this on opensuse of course.

If such a thing would commonly happen, I haven’t seen it.
ICMP packets appear universally the same no matter to all OS because it’s rare when a firewall looks deeper than the packet headers…
If ICMP packets were to be filtered by the application sending/receiving ICMP packets, you’d have to be running a filtering app capable of deep packet inspection, ie not just filtering by the packet headers but willing to tear apart each packet and inspect and evaluate the payload… generally functionality available only by running a proxy server

But more basically, troubleshooting anything depends largely on the specific error thrown, and know if it makes a difference.
And, this is the case because if you recognize the special meaning of “network unavailable” because it means that packets aren’t being blocked anywhere. The error is telling you that when your system tries to initiate a network connection, that’s not possible because of a misconfiguration… which means that you can ignore any possibilities that might come after that (You have to establish a network connection before you can send a packet and you can’t get a “blocked” or “no response” error if no connection was ever made).


in this case the issue is “unreachable” not “network unavailable”. guest cant ping host but has inet conn.