Re: auto-starting libvirtd on Workstation
Le mardi 16 avril 2019 à 14:57 +, Matthias Clasen a écrit : > I don't think we particularly need autostarting vms on the > workstation. It would be very nice to get libvirtd activated. I know > we've asked for this before... I have autostarted vms on my other_os workstation and it is very convenient. You set the hypervisor to save vm state on shutdown, and autorestart all the vms that were running next boot, and you don't need to bother about the hybernation vs sleep vs shutdown nonsense anymore. It just works -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: auto-starting libvirtd on Workstation
I don't think we particularly need autostarting vms on the workstation. It would be very nice to get libvirtd activated. I know we've asked for this before... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: auto-starting libvirtd on Workstation
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 (adamw...@fedoraproject.org) 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: auto-starting libvirtd on Workstation
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 (adamw...@fedoraproject.org) 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. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
