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
Assignee: bugsquad => gnomeCC: (none) => marja11
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 => NEWEver confirmed: 0 => 1
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.
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.
Created attachment 11281 [details] Troubleshooting Log of Mageia 7 guest
Version: 6 => 7
Target Milestone: --- => Mageia 8
Keywords: (none) => NEEDTEST
Try restarting the libvirtd service on the host machine before starting the guest.
CC: (none) => mageia
(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
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
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
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).
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 ?
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)
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.
Depends on: (none) => 27258
Mageia 7 is EOL since July 1st 2021. There will not have any further bugfix for this release. You are encouraged to upgrade to Mageia 8 as soon as possible. @reporter, if this bug still apply with Mageia 8, please let us know it. @packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead. This bug report will be closed OLD if there is no further notice within 1st September 2021.
Reported on IRC that it is still valid under Mageia 8.
CC: (none) => ouaurelienVersion: 7 => 8
I have just tested. Internet connection works on Mageia 8.
Status: NEW => RESOLVEDResolution: (none) => FIXED
This bug should proably be preopened as it occurs for me with freshly installed Mageia 8/gnome installation. Only configuration I have made to host computer is to update all mageia 8 rpm's to latest one with urpmi and then install gnome-boxes also with urpmi. When I use gnome-boxes to create the Mageia 8 virtual machine from iso image, the client virtual machine fails to connect to internet. I believe this happens because gnome-bboxes host has created virbr0 to be used for the network communication with the vm-client but the shorewall is blocking the virbr0. One possible fix would be to make gnome-boxes and virt-manager to add the virbr0 to /etc/shorewall/interfaces but maybe some better method wouyld also exist by creating some kind of file like /usr/share/shorewall/macro.QEMU
CC: (none) => lamikrEver confirmed: 1 => 0Status: RESOLVED => UNCONFIRMEDResolution: FIXED => (none)
Here is some info gathered from my system: 1) dmesg is full of these 30744.798232] OUTPUT REJECT IN= OUT=virbr0 SRC=192.168.122.1 DST=192.168.122.140 LEN=122 TOS=0x00 PREC=0x00 TTL=64 ID=56846 DF PROTO=UDP SPT=53 DPT=34632 LEN=102 [30744.798303] OUTPUT REJECT IN= OUT=virbr0 SRC=192.168.122.1 DST=192.168.122.140 LEN=58 TOS=0x00 PREC=0x00 TTL=64 ID=56847 DF PROTO=UDP SPT=53 DPT=34632 LEN=38 2) virsh net-list --all Name State Autostart Persistent -------------------------------------------- default active yes yes 3) brctl show bridge name bridge id STP enabled interfaces virbr0 8000.5254005091cc yes tap0 4) 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 53 -j ACCEPT -A LIBVIRT_OUT -o virbr0 -p tcp -m tcp --dport 53 -j ACCEPT -A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT -A LIBVIRT_OUT -o virbr0 -p tcp -m tcp --dport 68 -j ACCEPT
Execution of following commands on virtual machine host system fixes the problem and Mageia running on virtual machine quest that has been created by gnome-boxes can access the internet. # echo "net virbr0 detect" | tee -a /etc/shorewall/interfaces # echo "net virbr0 detect" | tee -a /etc/shorewall6/interfaces # systemctl restart shorewall.service # systemctl restart shorewall6.service # systemctl restart libvirtd.service
CC: (none) => epp
We stopped supporting Mageia 8 almost 8 months ago https://blog.mageia.org/en/2023/12/30/mageia-8-end-of-life/ That means we also stopped fixing Mageia 8 bugs and that this bug report needs to be closed, regardless of whether it was fixed for Mageia 8 or not. If this particular bug did not get fixed for Mageia 8, then we do regret that. If this issue is still present in Mageia 9 or cauldron, then please reopen this report, write a comment and adjust the "Version:" field. If you are not yet a member of one or our teams, then please consider becoming one. https://wiki.mageia.org/en/Contributing Mageia is a community project, meaning that we, the users, make Mageia together. The more active contributors we have, the more bug reports will get fixed. Besides, being active in a team can be very rewarding. It was and is certainly rewarding to me :-D
Status: UNCONFIRMED => RESOLVEDResolution: (none) => OLD