[Bug 802612] New: Libvirtd does not start automatically after kvm is installed via "yast install Hypervisor and tools"
https://bugzilla.novell.com/show_bug.cgi?id=802612 https://bugzilla.novell.com/show_bug.cgi?id=802612#c0 Summary: Libvirtd does not start automatically after kvm is installed via "yast install Hypervisor and tools" Classification: openSUSE Product: openSUSE 12.3 Version: RC 1 Platform: x86-64 OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: KVM AssignedTo: kvm-bugs@forge.provo.novell.com ReportedBy: mpluskal@suse.com QAContact: jdouglas@suse.com Found By: --- Blocker: --- Steps to reproduce: 1) Install kvm, libvirt and related package via yast, "Install Hypervisor and Tools", install kvm. 2) Restart computer 3) Libirtd is not running by default (regression when compared to SLES and imho usability issue - when I install Hypervisor ... I kinda expect it to work without further setup needed). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=802612 https://bugzilla.novell.com/show_bug.cgi?id=802612#c Bruce Rogers <brogers@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |brogers@suse.com AssignedTo|kvm-bugs@forge.provo.novell |jfehlig@suse.com |.com | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=802612 https://bugzilla.novell.com/show_bug.cgi?id=802612#c1 James Fehlig <jfehlig@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO CC| |carnold@suse.com InfoProvider| |meissner@suse.com --- Comment #1 from James Fehlig <jfehlig@suse.com> 2013-02-07 22:15:07 UTC --- One could argue that 'zypper in -t pattern {kvm,xen}_server' should behave the same, in which case it seems libvirtd should always be started in %post when installing libvirt. But I received a bug on that long ago https://bugzilla.novell.com/show_bug.cgi?id=496838 "Install Hypervisor and Tools" (or zypper in case the pattern is installed??) could call something like "systemctl enable libvirtd.service", but this seems like a gray area to me. Perhaps we can get some advise from the security folks? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=802612 https://bugzilla.novell.com/show_bug.cgi?id=802612#c2 Marcus Meissner <meissner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW CC| |meissner@suse.com, | |thomas@suse.com InfoProvider|meissner@suse.com | --- Comment #2 from Marcus Meissner <meissner@suse.com> 2013-02-08 08:31:04 UTC --- We usually see this as a two-step approach. Just installing a package should not enable its service by default as it might pulled in by dependencies etc.all. This should be done by the configuration or perhaps other indirect triggers. That people install this pattern does not mean that they want libvirtd. So no, it should not be enabled by default. What would the user usually do to then use libvirtd? Can this indirect usage somehow influence starting libvirtd? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=802612 https://bugzilla.novell.com/show_bug.cgi?id=802612#c3 --- Comment #3 from Martin Pluskal <mpluskal@suse.com> 2013-02-08 09:47:58 UTC --- If I understand correctly libvirt.spec: %post ... %if 0%{?sles_version} %{fillup_and_insserv -y -n libvirtd libvirtd} %else # ! sles %{fillup_only -n libvirtd} %endif %{fillup_only -n virtlockd} %endif insserv is used only on SLES Currently when you installs this pattern via yast virtulization, you are notified that you need to reboot for all drivers to load correctly, after you reboot and run virt-manager, you are informed that virt-manager could not connect to libvirtd. I think that this is sort of confusing behaviour/usability issue. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=802612 https://bugzilla.novell.com/show_bug.cgi?id=802612#c4 James Fehlig <jfehlig@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|carnold@suse.com |jfehlig@suse.com AssignedTo|jfehlig@suse.com |carnold@suse.com --- Comment #4 from James Fehlig <jfehlig@suse.com> 2013-02-08 16:38:20 UTC --- (In reply to comment #2)
What would the user usually do to then use libvirtd?
Use vm-install, virt-manager, virt-viewer, etc. But I don't think we want to hack all of these tools to start libvirtd. But I think it is reasonable to have libvirtd started when user runs "Install Hypervisor and Tools". They are explicitly installing the hypervisor *and* tools, so I think there is some expectation that the tools should actually work :). Charles, can you look at adding this to the yast module? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=802612 https://bugzilla.novell.com/show_bug.cgi?id=802612#c5 Charles Arnold <carnold@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |FIXED --- Comment #5 from Charles Arnold <carnold@suse.com> 2013-02-11 14:52:51 UTC --- (In reply to comment #4)
(In reply to comment #2)
What would the user usually do to then use libvirtd?
Use vm-install, virt-manager, virt-viewer, etc. But I don't think we want to hack all of these tools to start libvirtd.
But I think it is reasonable to have libvirtd started when user runs "Install Hypervisor and Tools". They are explicitly installing the hypervisor *and* tools, so I think there is some expectation that the tools should actually work :).
Charles, can you look at adding this to the yast module?
This is done. See the yast2-vm package from Factory, version 2.22.4 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=802612 https://bugzilla.novell.com/show_bug.cgi?id=802612#c6 Anton Samsonov <avsco@mail.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |avsco@mail.ru --- Comment #6 from Anton Samsonov <avsco@mail.ru> 2013-04-20 14:19:08 UTC --- (In reply to comment #5)
This is done. See the yast2-vm package from Factory, version 2.22.4.
The version 2.22.4-1.1.1 is already present in stable OpenSUSE 12.3, but libvirtd is still not enabled by default, and I'm pretty sure there was no need to enable it manually in previous versions of OpenSUSE (11.2-12.2). Why those regressions? First the GRUB disruption (bug 774666, bug 791337), then this one. Things should get simplified over time, not complicated, imho. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=802612 https://bugzilla.novell.com/show_bug.cgi?id=802612#c7 --- Comment #7 from Charles Arnold <carnold@suse.com> 2013-04-20 18:34:25 UTC --- (In reply to comment #6)
(In reply to comment #5)
This is done. See the yast2-vm package from Factory, version 2.22.4.
The version 2.22.4-1.1.1 is already present in stable OpenSUSE 12.3, but libvirtd is still not enabled by default, and I'm pretty sure there was no need to enable it manually in previous versions of OpenSUSE (11.2-12.2).
If you select the Xen pattern or the KVM package at host install time it does not enable libvirtd by default for security policy reasons (which I understand you don't agree with). This has been the case for many openSUSE releases and is not changing. If you install Xen or KVM as a post install operation using this latest version of yast2-vm it runs 'systemctl enable libvirtd.service'. If this is not working for you then let me know. It is not clear to me which of these you are doing.
Why those regressions? First the GRUB disruption (bug 774666, bug 791337), then this one. Things should get simplified over time, not complicated, imho.
In this case, Xen is a victim of changes to grub2 and hopefully others are working to resolve the problems. The openSUSE releases move fast (hence the frequency of releases) and they sometimes include packages that haven't had time to run under all use cases. It is good that we have community support from people like yourself to help with this. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=802612 https://bugzilla.novell.com/show_bug.cgi?id=802612#c8 --- Comment #8 from Anton Samsonov <avsco@mail.ru> 2013-04-21 18:27:04 UTC --- (In reply to comment #7)
If you select patterns at host install time, it does not enable libvirtd by default for security policy reasons; this has been the case for many openSUSE releases and is not changing.
Perhaps, this policy was not enforced previously, or libvirtd was not needed. Because I almost always selected the Xen host pattern at installation time (with only two exceptions, one of which was my very first OpenSUSE familiarization) and never had to deal with service management.
Sometimes they include packages that haven't had time to run under all use cases.
As far as I understand, both regressions are deliberate rather than accidental: in the GRUB topic, there was a word about “being bootloader-agnostic”, while with libvirtd we now have “security policy compliance”. This raises two questions. 1) How did it work without manual intervention in previous versions, and everyone was happy? If there were unhappy people, then were they more numerous than those unhappy with recent changes? 2) When taking this “agnosticism, abstraction and isolation” approach way further, how quickly we come to the idea of system from scratch? I. e. when everyone manually configures and complies every bit of software for his/her exact purpose (starting with kernel and bootloader, and up to userspace applications), writing startup scripts, and so on. Well, let's just hope that OpenSUSE never turns into Gentoo. :-) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com