[Bug 1123699] New: libvirt does not start default network automatically
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699 Bug ID: 1123699 Summary: libvirt does not start default network automatically Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Virtualization:Other Assignee: virt-bugs@suse.de Reporter: agraul@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Created attachment 795623 --> http://bugzilla.opensuse.org/attachment.cgi?id=795623&action=edit libvirt network default not enabled On a recent TW installation (Snapshot 20190125) that uses wicked (server role), the default network was not started automatically. Reproduction: 1. Install yast2-vm 2. Using yast2 virtualization: Install virtualization stack (xen server + tools, kvm server + tools, libvirt-lxc) and enable the virtualization bridge as the yast popup proposes 3. Start the libvirtd systemd service via `systemctl start libvirtd.service` 4. `virsh net-info default` shows that the 'default' network is not active. Expected result: The default network is started when libvirtd is started via systemctl, which allows commands like `virt-install` to succeed. See additional discussion: https://progress.opensuse.org/issues/41093 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
Alexander Graul
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c1
James Fehlig
On a recent TW installation (Snapshot 20190125) that uses wicked (server role), the default network was not started automatically.
Why do you expect the 'default' network to be automatically started by default? If you want that behavior then set it to autostart yourself. E.g. 'virsh net-autostart default'.
Reproduction: 1. Install yast2-vm 2. Using yast2 virtualization: Install virtualization stack (xen server + tools, kvm server + tools, libvirt-lxc) and enable the virtualization bridge as the yast popup proposes
FYI, this bridge has nothing to do with libvirt but is certainly usable via virt-install.
3. Start the libvirtd systemd service via `systemctl start libvirtd.service` 4. `virsh net-info default` shows that the 'default' network is not active.
Expected result: The default network is started when libvirtd is started via systemctl, which allows commands like `virt-install` to succeed.
virt-install is not dependent on the default network. It can just as easily use bridges configured with yast, NM, ip command, etc. E.g. 'virt-install ... --network bridge=br0,mac=...'
See additional discussion: https://progress.opensuse.org/issues/41093
That thread has some incorrect information. E.g. libvirt-daemon-config-network has no relationship with and is not affected by NM or wicked. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c2
Alexander Graul
(In reply to Alexander Graul from comment #0)
On a recent TW installation (Snapshot 20190125) that uses wicked (server role), the default network was not started automatically.
Why do you expect the 'default' network to be automatically started by default? If you want that behavior then set it to autostart yourself. E.g. 'virsh net-autostart default'.
I'd like to forward this question to the maintainer of the openQA test that fails due to not meeting this expectation (https://openqa.opensuse.org/tests/841756/modules/yast_virtualization/steps/1... and https://openqa.opensuse.org/tests/841756/modules/virt_install/steps/1/src). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c3
--- Comment #3 from Alexander Graul
(In reply to Alexander Graul from comment #0)
2. Using yast2 virtualization: Install virtualization stack (xen server + tools, kvm server + tools, libvirt-lxc) and enable the virtualization bridge as the yast popup proposes
FYI, this bridge has nothing to do with libvirt but is certainly usable via virt-install.
3. Start the libvirtd systemd service via `systemctl start libvirtd.service` 4. `virsh net-info default` shows that the 'default' network is not active.
Expected result: The default network is started when libvirtd is started via systemctl, which allows commands like `virt-install` to succeed.
virt-install is not dependent on the default network. It can just as easily use bridges configured with yast, NM, ip command, etc. E.g. 'virt-install ... --network bridge=br0,mac=...'
See additional discussion: https://progress.opensuse.org/issues/41093
That thread has some incorrect information. E.g. libvirt-daemon-config-network has no relationship with and is not affected by NM or wicked.
Thanks for the clarification. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
Oliver Kurz
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c4
James Fehlig
I'd like to forward this question to the maintainer of the openQA test that fails due to not meeting this expectation (https://openqa.opensuse.org/tests/841756/modules/yast_virtualization/steps/ 1/src
It looks like this script configures a bridge with yast.
https://openqa.opensuse.org/tests/841756/modules/virt_install/steps/1/src).
And this script doesn't explicitly specify a '--network' option, which according to the virt-install man page gives you: "If this option is omitted a single NIC will be created in the guest. If there is a bridge device in the host with a physical interface enslaved, that will be used for connectivity. Failing that, the virtual network called "default" will be used. This option can be specified multiple times to setup more than one NIC." So it seems virt-install should find the bridge created by yast and use it. Apparently that is not the case since it instead uses the inactive default network. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c5
--- Comment #5 from Charles Arnold
(In reply to Alexander Graul from comment #2)
I'd like to forward this question to the maintainer of the openQA test that fails due to not meeting this expectation (https://openqa.opensuse.org/tests/841756/modules/yast_virtualization/steps/ 1/src
It looks like this script configures a bridge with yast.
https://openqa.opensuse.org/tests/841756/modules/virt_install/steps/1/src).
And this script doesn't explicitly specify a '--network' option, which according to the virt-install man page gives you:
"If this option is omitted a single NIC will be created in the guest. If there is a bridge device in the host with a physical interface enslaved, that will be used for connectivity. Failing that, the virtual network called "default" will be used. This option can be specified multiple times to setup more than one NIC."
So it seems virt-install should find the bridge created by yast and use it. Apparently that is not the case since it instead uses the inactive default network.
I think it is possible that 'yast2 virtualization' (yast2-vm) is failing to create a bridge. If so, the problem is likely in the yast2-network code because the yast2-vm code is very simple and just calls into yast2-network to do the bridge creation. A simple 'ip addr' on the host would confirm if a bridge is present. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c6
--- Comment #6 from Oliver Kurz
I think it is possible that 'yast2 virtualization' (yast2-vm) is failing to create a bridge. If so, the problem is likely in the yast2-network code because the yast2-vm code is very simple and just calls into yast2-network to do the bridge creation.
A simple 'ip addr' on the host would confirm if a bridge is present.
Could you please state what your plans are regarding this? It should not be hard to reproduce the issue as it is reproducible every time. Also running openQA tests yourself or investigating interactively should not be too hard. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c8
Joachim Werner
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c9
--- Comment #9 from James Fehlig
Since a week or two ago, the default network on an frequently updated Tumbleweed I'm running is not automatically coming up any more. Would this be a separate bug report (because it can't be related _only_ to the YaST problem) or do you think it has the same root cause?
IMO the yast part of the bug should be a separate report. It has nothing to do with libvirt's default network.
In my case, the default network exists from the original installation and can be started manually. It just doesn't auto-start at boot time any more.
Is it still marked autostart? Check output of 'virsh net-list --all' command. If already set to autostart, are there any errors related to starting the default network in the output of 'journalctl -u libvirtd'? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c10
James Fehlig
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c13
Michael Pujos
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c14
--- Comment #14 from Michael Pujos
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c15
James Fehlig
Apparently dnsmasq fails if /etc/resolv.conf points to a non-existing file, which happens at startup:
That is an old bug, but the dnsmasq failure noted in #13 does sound similar. Perhaps a regression in dnsmasq? Let's see if one of the dnsmasq maintainers has any suggestions? BTW, it is odd that I cannot reproduce the bug. I tried on a fresh install of TW in a VM and also on my laptop, which has been rolling with TW for a few years now. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c16
--- Comment #16 from Michael Pujos
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c17
--- Comment #17 from James Fehlig
Could this be due to my particular network setup ?
I doubt it since you are able to start the default network after boot. Can anyone experiencing this bug pinpoint when it started occurring? Was there a particular package update that caused the problem? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c29
--- Comment #29 from Michael Pujos
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c30
James Fehlig
This happens while a "netconfig update" executed by ("netconfig modify" inside) wicked or NM while apply of the 1st lease. The wicked or NM service is started in network.target. The network-online.target is pulled & signals that they finished to setup the network.
Should the link exist once network.target is reached? The libvirtd service currently has 'After=network.target'. Does it need to wait for another network service to ensure /etc/resolv.conf exists? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c31
--- Comment #31 from Reinhard Max
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c32
James Fehlig
Looking at systemd.special(7), I think nss-lookup.target would be a more appropriate synchronisation point for this.
Thanks for the pointer! And I agree with your suggestion. If anyone listening can reliably reproduce the bug and is willing to test, package are available in my home project https://download.opensuse.org/repositories/home:/jfehlig:/branches:/Virtuali... Or if you want to quickly hack your existing setup diff -u /usr/lib/systemd/system/libvirtd.service.orig /usr/lib/systemd/system/libvirtd.service --- /usr/lib/systemd/system/libvirtd.service.orig 2019-06-03 16:39:20.076428868 -0600 +++ /usr/lib/systemd/system/libvirtd.service 2019-06-03 16:39:59.324788043 -0600 @@ -10,6 +10,7 @@ Wants=systemd-machined.service Before=libvirt-guests.service After=network.target +After=nss-lookup.target After=dbus.service After=iscsid.service After=apparmor.service -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c33
--- Comment #33 from Oliver Kurz
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c34
Reinhard Max
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c35
--- Comment #35 from James Fehlig
Hi, I could not find any packages in https://download.opensuse.org/repositories/home:/jfehlig:/branches:/ Virtualization/openSUSE_Factory/. https://build.opensuse.org/project/show/home:jfehlig:branches:Virtualization shows one package for x86_64 "blocked", another "broken".
Only x86_64 is set to publish and it is blocked on a massive rebuild of dependencies. Packages will appear in time.
Another option: You should be able to easily use openQA yourself to test it, either by just cloning the failing job
Thanks for the info. Probably no need to test the libvirt packages ATM since it seems the synchronization point will be placed elsewhere. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c36
James Fehlig
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c38
Cédric Bosdonnat
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c39
Reinhard Max
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c51
Ludwig Nussel
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
Ludwig Nussel
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c52
Reinhard Max
This change causes a half valid file conflict:
https://build.opensuse.org/package/view_file/home:repo-checker/reports/ openSUSE:Leap:15.2:Staging:A
yp.conf tmpfiles config file should be in ypbind, no?
Dunno, Marius asked me to add it to sysconfig along with resolv.conf. Maybe yp.conf should be removed from ypbind or turned into a %ghost? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c53
--- Comment #53 from Ludwig Nussel
http://bugzilla.opensuse.org/show_bug.cgi?id=1123699
Oliver Kurz
participants (1)
-
bugzilla_noreply@novell.com