On Fri, 2019-01-25 at 12:40 +0000, Patrick O'Callaghan wrote:
> On Fri, 2019-01-25 at 20:13 +0800, Ed Greshko wrote:
> > On 1/25/19 8:06 PM, Patrick O'Callaghan wrote:
> > > On Thu, 2019-01-24 at 22:40 +0800, Ed Greshko wrote:
> > > > On 1/24/19 8:08 PM, Patrick O'Callaghan wrote:
> > > > > I updated my system this morning. Updated packages included a new
> > > > > kernel and some SElinux stuff among other things (the complete list is
> > > > > attached). I now find that neither of my QEMU/KVM guests (one Fedora,
> > > > > one Windows 10) have Internet access, though they do have access to my
> > > > > host. They were both working perfectly before the update. Nothing else
> > > > > in my system has changed (in particular, I haven't touched the Firewall
> > > > > rules and the last updates to NetworkManager or Qemu were several days
> > > > > ago).
> > > > >
> > > > > I rebooted to the previous kernel - no difference.
> > > > >
> > > > > I set SElinux to permissive and rebooted the Fedora guest - no
> > > > > difference.
> > > > >
> > > > > Before trying to downgrade the entire update, is there anything else I
> > > > > can do?
> > > > What type of network is defined for your guests? I'm using macvtap instead of NAT and all
> > > > is working fine. My host is a fully updated F29/KDE and the guest is fully updated F28/KDE.
> > > I use NAT (with virtio), as I have always done. According to the virt-
> > > manager config widget, "macvtap does not work for host->guest
> > > communication".
> >
> > Yes, it doesn't. But I don't wish to use NAT since I use IPv6 stateless mode and that
> > doesn't work with NAT
> > > The Fedora guest is F28 Server. When I reported the problem yesterday
> > > it hadn't been updated in months. I updated it last night but it still
> > > isn't working (see my reply to Kai Bojens <kb@xxxxxxxxxx> in this
> > > thread).
> > >
> >
> > I installed a F29 guest today and it works just fine for me.
> >
> > Time to breakout wireshark to see if anything is actually being sent/received?
>
> I was afraid of that. Sigh.
Nothing illuminating I'm afraid.
41 20.186144769 192.168.122.1 192.168.122.167 ICMP 98 Echo (ping) request id=0x1519, seq=1/256, ttl=64 (no response found!)
(repeated)
This is the host pinging the guest. For completeness, some of the relevant data:
On the host:
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000
link/ether d4:3d:7e:f4:1b:08 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.73/24 brd 192.168.1.255 scope global noprefixroute enp3s0
valid_lft forever preferred_lft forever
inet6 fe80::d63d:7eff:fef4:1b08/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 52:54:00:8b:88:60 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq master virbr0 state DOWN group default qlen 1000
link/ether 52:54:00:8b:88:60 brd ff:ff:ff:ff:ff:ff
5: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master virbr0 state UNKNOWN group default qlen 1000
link/ether fe:54:00:1d:55:89 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:fe1d:5589/64 scope link
valid_lft forever preferred_lft forever
6: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master virbr0 state UNKNOWN group default qlen 1000
link/ether fe:54:00:b0:20:88 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:feb0:2088/64 scope link
valid_lft forever preferred_lft forever
$ ip route
default via 192.168.1.1 dev enp3s0 proto static metric 100
192.168.1.0/24 dev enp3s0 proto kernel scope link src 192.168.1.73 metric 100
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
(The guest is on interface virbr0).
For the equivalent settings on the guest, see the attached screenshot.
Pings in both directions fail, in case that wasn't clear. BTW the
Windows guest also fails in the same way.
I'm at a loss.
poc
Attachment:
Screenshot_fedora28_2019-01-25_15:47:41.png
Description: PNG image
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
