0

I have a host machine running Debian 10 and am using QEMU to run an OpenBSD 6.7 guest (amd64). My current invocation of QEMU is as follows:

$ qemu-system-x86_64 -m 512 -drive if=virtio,file=my_image.qcow2 -enable-kvm -netdev user,id=mynet0,hostfwd=tcp:127.0.0.1:7922-:22 -device virtio-net,netdev=mynet0

On the guest machine, I can access remote Subversion servers and also the OpenBSD package repositories just fine, but whenever I try to ping a remote host, it just hangs indefinitely until I kill it:

$ ping google.com
^C
--- google.com ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss

Furthermore, I have an assignment that involves the usual C socket programming (on the guest machine). Whenever I make a call to connect, I get Network is unreachable back.

Here are my interfaces configured on the guest machine:

$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768
    index 3 priority 0 llprio 3
    groups: lo
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
    inet 127.0.0.1 netmask 0xff000000
vio0: flags=808843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF4> mtu 1500
    lladdr 52:54:00:12:34:56
    index 1 priority 0 llprio 3
    groups: egress
    media: Ethernet autoselect
    status: active
    inet 10.0.2.15 netmask 0xffffff00 broadcast 10.0.2.255
enc0: flags=0<>
    index 2 priority 0 llprio 3
    groups: enc
    status: active
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33136
    index 4 priority 0 llprio 3
    groups: pflog

and my routes (also on the guest machine):

$ route show
Routing tables

Internet:
Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
default            10.0.2.2           UGS        5        9     -     8 vio0 
base-address.mcast localhost          URS        0        0 32768     8 lo0  
10.0.2/24          10.0.2.15          UCn        2        0     -     4 vio0 
10.0.2.2           52:55:0a:00:02:02  UHLch      3        5     -     3 vio0 
10.0.2.3           52:55:0a:00:02:03  UHLc       0        8     -     3 vio0 
10.0.2.15          52:54:00:12:34:56  UHLl       0        8     -     1 vio0 
10.0.2.255         10.0.2.15          UHb        0        0     -     1 vio0 
127/8              localhost          UGRS       0        0 32768     8 lo0  
localhost          localhost          UHhl       1        2 32768     1 lo0  

Internet6:
Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
::/96              localhost          UGRS       0        0 32768     8 lo0  
localhost          localhost          UHhl      10       20 32768     1 lo0  
::ffff:0.0.0.0/96  localhost          UGRS       0        0 32768     8 lo0  
2002::/24          localhost          UGRS       0        0 32768     8 lo0  
2002:7f00::/24     localhost          UGRS       0        0 32768     8 lo0  
2002:e000::/20     localhost          UGRS       0        0 32768     8 lo0  
2002:ff00::/24     localhost          UGRS       0        0 32768     8 lo0  
fe80::/10          localhost          UGRS       0        0 32768     8 lo0  
fec0::/10          localhost          UGRS       0        0 32768     8 lo0  
fe80::1%lo0        fe80::1%lo0        UHl        0        0 32768     1 lo0  
ff01::/16          localhost          UGRS       1        1 32768     8 lo0  
ff01::%lo0/32      fe80::1%lo0        Um         0        1 32768     4 lo0  
ff02::/16          localhost          UGRS       1        1 32768     8 lo0  
ff02::%lo0/32      fe80::1%lo0        Um         0        1 32768     4 lo0

This leads me to believe that my QEMU setup is somehow misconfigured.

How can I fix the network configuration to allow the guest machine to talk (properly) to the outside world?

0

I'm guessing -netdev user works fine with TCP and UDP but not ICMP. Try running tcpdump on the host machine's interface(s) to see if the ICMP packets are being properly forwarded and/or translated.

I'm not sure on how -netdev user works on the host machine, but if you want your guest machine to behave more like a proper member of your network perhaps creating a tap interface on the host machine, bridging it with the host's physical interface (both require root access), and then using -netdev tap would be a better alternative.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.