Bug 21927 - gnome-boxes guest operating system is not able to connect to internet
Summary: gnome-boxes guest operating system is not able to connect to internet
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal major
Target Milestone: Mageia 8
Assignee: GNOME maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 27258
Blocks:
  Show dependency treegraph
 
Reported: 2017-10-24 17:43 CEST by Cyril Levet
Modified: 2020-09-08 00:32 CEST (History)
2 users (show)

See Also:
Source RPM: gnome-boxes-3.24.0-1.mga6.src.rpm
CVE:
Status comment:


Attachments
Troubleshooting Log of Mageia 7 guest (22.80 KB, text/plain)
2019-09-15 11:49 CEST, Cyril Levet
Details

Description Cyril Levet 2017-10-24 17:43:45 CEST
Description of problem:

Mageia 6 guest operating system is not able to connect to internet. The host operating system is Mageia 6. Gnome network manager and MCC indicate that the guest is connected but it is impossible to connect to internet or to download updates (urpmi or MCC). When deactivate the Mageia 6 host firewall, sometimes the guest connexion works. However, often, deactivate the host firewall has no effect.
Same problem is noted with Fedora 26 guest.


Version-Release number of selected component : gnome-boxes-3.24.0-1.mga6


How reproducible: always with host firewall is activated, often when host firewall is off.


Steps to Reproduce:
1. Create a Mageia 6 guest on gnome-boxes
2. Try to open a wab-site or download mirrorlist with MCC
Marja Van Waes 2017-10-25 09:50:36 CEST

Assignee: bugsquad => gnome
CC: (none) => marja11

Comment 1 Marja Van Waes 2017-10-27 19:58:56 CEST
Mass-change status to NEW for all bugs that were filed as UNCONFIRMED between October 9 and now, and that still have that status now.

From now on all newly filed bugs will have the NEW status again, like before, regardless of who files the report.

Status: UNCONFIRMED => NEW
Ever confirmed: 0 => 1

Comment 2 Cyril Levet 2018-07-01 16:15:55 CEST
I don't know why but this bug seems to happen less often than before with Mageia 6 host and Mageia Cauldron guest. But it still happen sometimes.
Comment 3 Cyril Levet 2019-09-15 11:47:52 CEST
The bug is still present in Mageia 7 with boxes 3.32.1-stable. 
I have uninstalled gnome-boxes, deleted all orphans and reinstalled Boxes. 
I have created a Mageia 7 guest machine and a Fedora 30 Workstation (which is one of the default choice in Boxes). Connection to network does not work. I join the internal log of the VM.
Comment 4 Cyril Levet 2019-09-15 11:49:59 CEST
Created attachment 11281 [details]
Troubleshooting Log of Mageia 7 guest
Cyril Levet 2019-11-04 23:49:29 CET

Version: 6 => 7

Aurelien Oudelet 2020-09-04 23:13:39 CEST

Target Milestone: --- => Mageia 8

Aurelien Oudelet 2020-09-04 23:14:14 CEST

Keywords: (none) => NEEDTEST

Comment 5 Martin Whitaker 2020-09-04 23:32:20 CEST
Try restarting the libvirtd service on the host machine before starting the guest.

CC: (none) => mageia

Comment 6 Cyril Levet 2020-09-05 13:53:40 CEST
(In reply to Martin Whitaker from comment #5)
> Try restarting the libvirtd service on the host machine before starting the
> guest.

Restarting libvirtd service does not fix the problem.

I have this behaviour on two different computers with Mageia 7. One is an upgrade from Mageia 6, the other is a fresh install of Mageia 7. Both using only Gnome since installation. They have different processors, different motherboard and different graphic cards so it seems not be material related.

After restarted libvritd the log is :

● libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2020-09-05 13:47:00 CEST; 2s ago
     Docs: man:libvirtd(8)
           https://libvirt.org
 Main PID: 15970 (libvirtd)
    Tasks: 19 (limit: 32768)
   Memory: 132.8M
   CGroup: /system.slice/libvirtd.service
           ├─ 1609 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper
           ├─ 1610 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper
           └─15970 /usr/sbin/libvirtd

sept. 05 13:47:00 mageia systemd[1]: Starting Virtualization daemon...
sept. 05 13:47:00 mageia libvirtd[15970]: libvirt version: 5.5.0
sept. 05 13:47:00 mageia libvirtd[15970]: hostname: mageia
sept. 05 13:47:00 mageia libvirtd[15970]: Libvirt doesn't support VirtualBox API version 6000024
sept. 05 13:47:00 mageia systemd[1]: Started Virtualization daemon.
sept. 05 13:47:00 mageia dnsmasq[1609]: read /etc/hosts - 2 addresses
sept. 05 13:47:00 mageia dnsmasq[1609]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
sept. 05 13:47:00 mageia dnsmasq-dhcp[1609]: read /var/lib/libvirt/dnsmasq/default.hostsfile
sept. 05 13:47:00 mageia libvirtd[15970]: cannot open directory '/home/cyril/Logiciels/Mageia-6-x86_64-DVD': Aucun fichier ou dossier de ce type
sept. 05 13:47:00 mageia libvirtd[15970]: internal error: Failed to autostart storage pool 'Mageia-6-x86_64-DVD': cannot open directory '/home/cyril/Logiciels/Mageia-6-x86_64-DVD': Aucun fichier ou dossier de ce type

The two errors are related with non existent files and VM. It is not important.

Running Fedora 30 server in gnome-boxes has no internet connection. Status of libvirtd after closing gnome-boxes is :

systemctl status libvirtd.service
● libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2020-09-05 13:47:00 CEST; 3min 9s ago
     Docs: man:libvirtd(8)
           https://libvirt.org
 Main PID: 15970 (libvirtd)
    Tasks: 19 (limit: 32768)
   Memory: 132.9M
   CGroup: /system.slice/libvirtd.service
           ├─ 1609 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper
           ├─ 1610 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper
           └─15970 /usr/sbin/libvirtd

sept. 05 13:49:29 mageia dnsmasq[1609]: failed to send packet: Operation not permitted
sept. 05 13:49:34 mageia dnsmasq[1609]: failed to send packet: Operation not permitted
sept. 05 13:49:34 mageia dnsmasq[1609]: failed to send packet: Operation not permitted
sept. 05 13:49:34 mageia dnsmasq[1609]: failed to send packet: Operation not permitted
sept. 05 13:49:34 mageia dnsmasq[1609]: failed to send packet: Operation not permitted
sept. 05 13:49:39 mageia dnsmasq[1609]: failed to send packet: Operation not permitted
sept. 05 13:49:39 mageia dnsmasq[1609]: failed to send packet: Operation not permitted
sept. 05 13:49:44 mageia dnsmasq[1609]: failed to send packet: Operation not permitted
sept. 05 13:49:44 mageia dnsmasq[1609]: failed to send packet: Operation not permitted
sept. 05 13:50:05 mageia libvirtd[15970]: End of file while reading data: Erreur d'entrée/sortie
Comment 7 Martin Whitaker 2020-09-05 22:34:34 CEST
With the guest running, what is the output from the following commands, run as root on the Mageia 7 host?

  virsh net-list --all
  brctl show
  iptables -S | grep LIBVIRT
  iptables -S | grep virbr
Comment 8 Cyril Levet 2020-09-06 01:41:27 CEST
virsh net-list --all
 Name      State    Autostart   Persistent
--------------------------------------------
 default   active   yes         yes

brctl show
bridge name	bridge id		STP enabled	interfaces
virbr0		8000.525400e47d2b	yes		tap0
							virbr0-nic

iptables -S | grep LIBVIRT
-N LIBVIRT_FWI
-N LIBVIRT_FWO
-N LIBVIRT_FWX
-N LIBVIRT_INP
-N LIBVIRT_OUT
-A INPUT -j LIBVIRT_INP
-A FORWARD -j LIBVIRT_FWX
-A FORWARD -j LIBVIRT_FWI
-A FORWARD -j LIBVIRT_FWO
-A OUTPUT -j LIBVIRT_OUT
-A LIBVIRT_FWI -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A LIBVIRT_FWI -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A LIBVIRT_FWO -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A LIBVIRT_FWO -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A LIBVIRT_FWX -i virbr0 -o virbr0 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT

iptables -S | grep virbr
-A LIBVIRT_FWI -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A LIBVIRT_FWI -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A LIBVIRT_FWO -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A LIBVIRT_FWO -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A LIBVIRT_FWX -i virbr0 -o virbr0 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT
Comment 9 Martin Whitaker 2020-09-06 11:52:49 CEST
You need to reconfigure the host firewall to include the virbr0 interface. Once you have done that (and any subsequent time you run drakfirewall) you will need to restart the libvirtd service (because the firewall rules it added will have been removed).
Comment 10 Cyril Levet 2020-09-06 12:36:54 CEST
Thank you it's work.

However I don't understand. Is it a bug because firewall and libvirtd.service are not properly configured when installing gnome-boxes ? Or did I make a mistake ?

Is it possible to force libvirtd restarting after using drakfirewall in order to avoid manual operation ?
Comment 11 Martin Whitaker 2020-09-07 21:45:20 CEST
Not really a bug, more a lack of integration. shorewall expects to be in sole control of the iptables rules, and doesn't allow for them being changed behind its back. And from what I can find on the web, it seems the developers of libvirt use firewalld, not shorewall.

You could try putting in an enhancement request to make drakfirewall aware of libvirt, but I don't know that it would get any attention.

I did find this:

  https://wiki.mageia.org/en/Virt-Manager

which suggests a way of manually configuring shorewall to handle the libvirtd connections, but haven't tried it, and don't know if drakfirewall would recognise and retain those settings.

Keywords: NEEDTEST => (none)

Comment 12 Cyril Levet 2020-09-08 00:09:26 CEST
Thanks. I will create the enhancement request for reference even if it will never get attention.

I try the manual configuration. Restarted shorewall works. But when I run drakfirewall after that, I always need to restart libvirtd.
Cyril Levet 2020-09-08 00:32:37 CEST

Depends on: (none) => 27258


Note You need to log in before you can comment on or make changes to this bug.