FS#50693 - [libvirt] recreation of virbr0 and autostart on update

Attached to Project: Community Packages
Opened by Curtis Lee Bolin (curtisleebolin) - Wednesday, 07 September 2016, 14:05 GMT
Last edited by Sergej Pupykin (sergej) - Tuesday, 28 February 2017, 17:59 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sergej Pupykin (sergej)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:
libvirt creates and autostarts network devices virbr0.

I remove the device with:
# virsh net-destroy default
# virsh net-undefine default
# systemctl restart libvirtd.service

Each time libvirt is updated, virbr0 is recreated and autostarts.

damjan pointed to file /etc/libvirt/qemu/networks/autostart/default.xml in the forum[1].
It is symbolic linked to /etc/libvirt/qemu/networks/default.xml.

I found in PKGBUILD that default.xml (and the symbolic link in autostart for some weird reason since it can't be backed up) are being backed up for replacement. I don't think the symbolic link to default should be in the autostart directory. It can be enabled by a user wanting it with:

# virsh net-autostart default

Which can be documented on the wiki page[2] and/or in the post_install().

It is annoying that it starts the first time, but even more of a headache each time the package is updated.

[1]https://bbs.archlinux.org/viewtopic.php?pid=1652510#p1652510
[2]https://wiki.archlinux.org/index.php/Libvirt


Steps to reproduce:
Install or update libvirt and start virtlogd and libvirtd.

This task depends upon

Closed by  Sergej Pupykin (sergej)
Tuesday, 28 February 2017, 17:59 GMT
Reason for closing:  Fixed
Additional comments about closing:  I removed symlink from autostart
Comment by Aleksei (nesk_bugs) - Sunday, 25 September 2016, 09:27 GMT
Having a default autostarted network on virbr0 with sane network settings is pretty useful. That's the reason I keep system libvirtd enabled, so my VMs can tap into already existing bridge without me having to configure it. It's a good default.
Comment by Curtis Lee Bolin (curtisleebolin) - Monday, 26 September 2016, 18:28 GMT
Aleksei (nesk_bugs), with this removed from autostart in the package, it would only be a one line command to add it to your autostart, and you would never have to touch it again. The current problem with the package is that people with a more complex setup are stuck with this default network being added to autostart every time the packages is updated. Updating packages should not tamper with my setup.
Comment by Aleksei (nesk_bugs) - Monday, 26 September 2016, 18:50 GMT
My point (which I didn't make very clearly) is that it's a good default for fresh installations of libvirt. Disabling it is also one line command.
I agree that on updates it should honor the user's choice and not recreate the symbolic link in autostart.
Comment by Curtis Lee Bolin (curtisleebolin) - Tuesday, 27 September 2016, 18:23 GMT
Aleksei (nesk_bugs), with this removed from autostart in the package, it would only be a one line command to add it to your autostart, and you would never have to touch it again. The current problem with the package is that people with a more complex setup are stuck with this default network being added to autostart every time the packages is updated. Updating packages should not tamper with my setup.
Comment by Curtis Lee Bolin (curtisleebolin) - Tuesday, 27 September 2016, 18:58 GMT
Aleksei (nesk_bugs), it is not a single command to remove what the autostart causes. There are 3 commands including restarting libvirtd.

Users that do want to use the default network are probably using the virt-manager gui, and can easily start it in the gui.
Or
Run a single command: # virsh net-autostart default

Removing the symbolic link in autostart is the simplest solution to keep the package from interfering on updates. The default network will still be available to the user.

Asking an Arch Linux user to opt-in for the default network one single time seems much more reasonable then asking users to opt-out every time the package is updated. Honestly, it seems like the Arch Linux way.
Comment by LightDot (lightdot) - Wednesday, 28 September 2016, 23:06 GMT
IMHO, having a default network predefined is fine, having it started automatically seems wrong even on the first install, let alone on updates, as Curtis said.

There is also a security angle on this. It is my opinion that an act of installing a package should not cause any new services to be automatically enabled or started (unless absolutely necessary for basic OS operation).

Services state should change only after an explicit user command and preferably after the user has had an ample opportunity to configure the newly installed software. This caveat also applies to starting networks, opening ports, etc.. Basically, the user should be explicit about what he or she wants to be running on their computer, to avoid potential security risks.
Comment by Ryan Nabinger (rnabinger) - Thursday, 23 February 2017, 07:20 GMT
The behavior of this package is anti-Archlinux!
If I wanted packages to gratuitously create interfaces, bridges, routes, and iptables rules (filter and mangle tables) then I would be running Ubuntu. Please make it so this package does not do any of the things I just mentioned. In Archlinux, users configure packages rather than fight off overzealous package managers.

If you cannot figure out how to autostart an interface in libvirt then RTFM or GTFO!

As mentioned, this is also a minor security risk and wish there was an appropriate way to flag it as such.
Comment by Ryan Nabinger (rnabinger) - Thursday, 23 February 2017, 16:57 GMT
Sorry for double-posting, but I wanted to attach a little summary of the side-effects of the autostarted default interface. Keep in mind I have no VMs running right now, this is with everything down (but with libvirtd running obviously). Also note that I already do everything libvirt tries to, then every upgrade it recreates all these things and I have to fixup. I understand I could block this from happening in various ways, but no one should have to continually fight off a package.

Also, we just discovered that this default network errors out if you do not have the `ebtables` optional dependency.

EDIT: I sent a patch to the maintainer. I've attached libvirt.diff

Loading...