http://bugzilla.opensuse.org/show_bug.cgi?id=1123699 http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c1 James Fehlig <jfehlig@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |agraul@suse.com, | |jfehlig@suse.com Assignee|virt-bugs@suse.de |jfehlig@suse.com Flags| |needinfo?(agraul@suse.com) --- Comment #1 from James Fehlig <jfehlig@suse.com> --- (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'.

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#c3 --- Comment #3 from Alexander Graul <agraul@suse.com> --- (In reply to James Fehlig from comment #1)

(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 http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c4 James Fehlig <jfehlig@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |carnold@suse.com --- Comment #4 from James Fehlig <jfehlig@suse.com> --- (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. -- 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 <okurz@suse.com> --- (In reply to Charles Arnold from comment #5)

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#c9 --- Comment #9 from James Fehlig <jfehlig@suse.com> --- (In reply to Joachim Werner from comment #8)

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#c13 Michael Pujos <pujos.michael@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pujos.michael@gmail.com --- Comment #13 from Michael Pujos <pujos.michael@gmail.com> --- I'm noticing the same issue. I have a 'default' network config marked as autostart in virt-manager, Confirmed with: bobbie@p72:~> sudo virsh net-list --all Name State Autostart Persistent ---------------------------------------------- default inactive yes yes There is no issue enabling the network manually in virt-manager There's that dnsmasq error in the journal (see below), likely the cause of this issue. No idea why it mentions /etc/resolv.conf being a directory. resolv.conf is a file and a symbolic link (as expected). bobbie@p72:~> sudo journalctl -u libvirtd -- Logs begin at Sat 2019-03-09 16:31:52 CET, end at Sat 2019-03-09 18:30:46 CET. -- Mar 09 16:32:08 p72 systemd[1]: Starting Virtualization daemon... Mar 09 16:32:08 p72 libvirtd[1978]: libvirt version: 5.0.0 Mar 09 16:32:08 p72 libvirtd[1978]: hostname: p72 Mar 09 16:32:08 p72 libvirtd[1978]: Failed to intialize libnetcontrol. Management of interface devices is disabled Mar 09 16:32:09 p72 systemd[1]: Started Virtualization daemon. Mar 09 16:32:09 p72 libvirtd[1978]: internal error: Unknown PCI header type '127' Mar 09 16:32:09 p72 libvirtd[1978]: internal error: Unknown PCI header type '127' Mar 09 16:32:09 p72 dnsmasq[2362]: directory /etc/resolv.conf for resolv-file is missing, cannot poll Mar 09 16:32:09 p72 dnsmasq[2362]: FAILED to start up Mar 09 16:32:09 p72 libvirtd[1978]: internal error: Child process (VIR_BRIDGE_NAME=virbr0 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/us> dnsmasq: directory /etc/resolv.conf for resolv-file is missing, cannot poll -- 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#c15 James Fehlig <jfehlig@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbosdonnat@suse.com, | |max@suse.com Flags| |needinfo?(max@suse.com) --- Comment #15 from James Fehlig <jfehlig@suse.com> --- (In reply to Michael Pujos from comment #14)

Apparently dnsmasq fails if /etc/resolv.conf points to a non-existing file, which happens at startup:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798586

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#c17 --- Comment #17 from James Fehlig <jfehlig@suse.com> --- (In reply to Michael Pujos from comment #16)

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#c30 James Fehlig <jfehlig@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(mt@suse.com) --- Comment #30 from James Fehlig <jfehlig@suse.com> --- (In reply to Marius Tomaschewski from comment #24)

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#c34 Reinhard Max <max@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(mt@suse.com) --- Comment #34 from Reinhard Max <max@suse.com> --- @James, I was rather thinking of putting nss-lookup.target as a synchronisation point between wicked creating the resolv.conf file and dnsmasq consuming it, but that might lead to a hen and egg problem, because dnsmasq itself might be considered a service that has to be up before nss-lookup.target can be reached. But I think I've found a different solution for the dnsmasq part of the problem: It is not the lack of the resolv.conf file itself that causes dnsmasq to fail on startup, it's the lack of the directory containing that file. So, /etc/resolv.conf is a symlink to /var/run/netconfig/resolv.conf, but /var/run/netconfig does not exist when dnsmasq is being started and so it has no place to put an inotify on to get triggered when the resolv.conf file appears. So, if we manage to create /var/run/netconfig early enough in the boot process (maybe through systemd's tmpfile mechanism) dnsmasq should start successfully even if resolv.conf does not yet exist. @Marius, other packages/subsystems are already using the tmpfiles mechanism to create their respective subdirs under /run, so what would you think of also adding this for /var/run/netconfig to either wicked or sysconfig and see if it happens early enough for dnsmasq to succeed? For a quick test without touching any packages: echo "d /run/netconfig 0755 root root -" > /etc/tmpfiles.d/netconfig.conf When packaging this the file should of course go to /usr/lib/tmpfiles.d/ rather than /etc/tmpfiles.d/ . -- 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 <jfehlig@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mrostecki@suse.com --- Comment #36 from James Fehlig <jfehlig@suse.com> --- *** Bug 1137883 has been marked as a duplicate of this bug. *** -- 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#c39 Reinhard Max <max@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |coolo@suse.com --- Comment #39 from Reinhard Max <max@suse.com> --- *** Bug 1135150 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1123699 Ludwig Nussel <lnussel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P2 - High -- 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 <lnussel@suse.com> --- already is %ghost there. but also also %config(noreplace), that's why there is a conflict. -- You are receiving this mail because: You are on the CC list for the bug.