On Tue, Apr 09, 2019 at 09:14:18PM -0600, Orion Poplawski wrote: > On 4/9/19 1:00 PM, Cole Robinson wrote: > > On 4/9/19 2:20 PM, Lennart Poettering wrote: > > > On Di, 09.04.19 10:11, Adam Williamson (adamwill@xxxxxxxxxxxxxxxxx) wrote: > > > > > > > Basically, anything that's part of the install environment is going to > > > > be present after a live install. That accounts for both of the above: > > > > the installer supports multipath and dmraid storage devices, so the > > > > relevant packages are part of the install environment, so they're part > > > > of the lives, so they're installed by a live install. > > > > > > Hmm, but the installed OS is not 100% the same as the livesys, or is > > > it? If not, it should be possible to add a "systemctl disable > > > dmraid.service --root=/path/to/os" somewhere, no? > > > > > > > To be specific here, 'at' is part of the @standard group. 'chrony' > > > > is > > > > > > Yupp, it's very confusing that we have chrony and cronie in our OS > > > and both are installed by default... ;-) > > > > > > > > I don't know on this. I remember something about containers and flatpaks > > > > > but .. I don't know. > > > > > > > > Boxes is a key component of Workstation, and it relies on libvirt. It's > > > > in the 'Core Applications' definition of the Workstation tech spec: > > > > > > Hmm, but boxes supposedly uses the user session version of libvirt, > > > no? it doesn't actually use the system service? > > > > > > > You're right it does not explicitly talk to the system libvirtd > > instance. But boxes implicitly depends on system libvirtd to autostart > > the 'default' virtual network, which is the preferred networking method. > > boxes VMs then essentially use a small setuid helper shipped with qemu > > to use the default virbr0 for unprivileged VMs. > > > > Thanks, > > Cole > > I've long thought that the virtual network should be its own service: > https://bugzilla.redhat.com/show_bug.cgi?id=1597326#c5 > > but of course I don't have the time to do the work so that doesn't count for > much. But this possibly points to another reason to do so. I'm working on an upstream libvirt re-architecture that will make it into its own daemon. In fact libvirtd will be split into many smaller daemons each specific responsibilities. This won't let us use systemd activation though. Libvirtd can't use activation right now because it needs to be able to auto-start VMs and networks at system boot up. This functionality pre-dates systemd so is handled by libvirtd itself. Eventually it would be ideal if libvirtd can dynamically create systemd units for its resources which need start-on-boot functionality, but that's some significant work to do still. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
