Red Hat Bugzilla – Bug 888297
qemu-ga should be enabled right after installation
Last modified: 2013-11-21 01:26:19 EST
Description of problem: qemu-ga should be enabled and started right after installation as any other guest agent. Version-Release number of selected component (if applicable): qemu-guest-agent-0.12.1.2-2.346.el6.x86_64 How reproducible: Steps to Reproduce: 1. install qemu-guest-agent package 2. invoke "service qemu-ga status" 3. invoke "ckconfig qemu-ga --list" Actual results: "service qemu-ga status" says that qemu-ga is stopped "chkconfig qemu-ga --list" reports qemu-ga "off" in all runlevels Expected results: "service qemu-ga status" should report qemu-ga as running "chkconfig qemu-ga --list" should report "on" for runlevels 2-5 Additional info:
From an IRC conversation: danpb eblake: we install a udev rule too danpb SUBSYSTEM=="virtio-ports", ATTR{name}=="org.qemu.guest_agent.0", \ danpb TAG+="systemd" ENV{SYSTEMD_WANTS}="qemu-guest-agent.service" danpb that udev rule says that when the virtio channel org.qemu.guest_agent.0 is found, tell systemd to activate qemu-guest-agent.service eblake oh, so if the device exists (which is only possible in a VM), then the service is autostarted even without being enabled? danpb eblake: if you had used the [Install] section in the unit file, it would have been run even on bare metal danpb eblake: yep, because systemd creates a virtual unit for each device danpb eblake: and the SYSTEMD_WANTS sets up a dependancy Other bugs related to getting guest-agent cleanly working through the entire stack by default: bug 887415 - libvirt should make adding guest-agent channel to guest XML easier bug 886705 - guest-agent should be part of base install for live images
The above is how it is done in Fedora - we should do something similar for RHEL, sans systemd of course.
Test this bug as follow version: Host: # uname -r 2.6.32-348.el6.x86_64 # rpm -q qemu-kvm qemu-kvm-0.12.1.2-2.348.el6.x86_64 Guest: # uname -r 2.6.32-343.el6.x86_64 qemu-guest-agent-0.12.1.2-2.348.el6.x86_64.rpm Steps: 1.Boot guest with ...-chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtio-serial -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0... 2.In Guest #rpm -ivh qemu-guest-agent-0.12.1.2-2.348.el6.x86_64.rpm Results: # service qemu-ga status qemu-ga is stopped # chkconfig qemu-ga --list qemu-ga 0:off 1:off 2:off 3:off 4:off 5:off 6:off
Can anaconda enable qemu-ga by invoking chkconfig during installation? IMO that would be the cleanest. Is it customary for other daemons *in RHEL-6* to be auto-enabled after installing the RPM? (What RHEL-7 does with systemd shouldn't matter.)
(In reply to Laszlo Ersek from comment #9) > Can anaconda enable qemu-ga by invoking chkconfig during installation? IMO > that would be the cleanest. Is it customary for other daemons *in RHEL-6* to > be auto-enabled after installing the RPM? (What RHEL-7 does with systemd > shouldn't matter.) Auto-starting the agent doesn't necessarily require systemd. in RHEL-6 (and older) you could probably do it with a udev rule which matches on the virtio port name.
Oh, and alternatively you can make the RPM %post script run 'chkconfig' unconditionally to set the init script to run on boot, then simply make sure the init script does an immediate 'exit 0' if the virtio device doesn't exist at boot. That way it wouldn't impact non-virt hosts, even if enabled by default
That's my point exactly -- I used to think that RHEL-6 doesn't start *any* service automatically right after installing the package(s) providing the service. Ie. that it's always a separate admin step to call "service start" and/or "chkconfig". Wouldn't the proposal diverge from this? (I could easily be confused!)
You can't directly start the service from the %post script (ie not allowed todo 'service foo start', but you can mark it to be automatically started upon boot-up (ie chkconfig foo on). The latter would be sufficient for qemu ga's needs.
I certainly agree with that, thanks!
Reproduce the bug on qemu-guest-agent-0.12.1.2-2.390.el6.x86_64. [root@localhost ~]# rpm -ivh qemu-guest-agent-0.12.1.2-2.390.el6.x86_64.rpm Preparing... ########################################### [100%] 1:qemu-guest-agent ########################################### [100%] [root@localhost ~]# [root@localhost ~]# chkconfig qemu-ga --list qemu-ga 0:off 1:off 2:off 3:off 4:off 5:off 6:off [root@localhost ~]# service qemu-ga status qemu-ga is stopped Reboot guest, the "qemu-ga" status is still stopped. Verified the bug on qemu-kvm-0.12.1.2-2.398.el6. [root@localhost ~]# rpm -e qemu-guest-agent [root@localhost ~]# [root@localhost ~]# rpm -ivh qemu-guest-agent-0.12.1.2-2.398.el6.x86_64.rpm Preparing... ########################################### [100%] 1:qemu-guest-agent ########################################### [100%] [root@localhost ~]# [root@localhost ~]# chkconfig qemu-ga --list qemu-ga 0:off 1:off 2:on 3:on 4:on 5:on 6:off [root@localhost ~]# [root@localhost ~]# service qemu-ga status qemu-ga is stopped [root@localhost ~]# reboot After reboot guest, the "qemu-ga" status is started. [root@localhost ~]# service qemu-ga status qemu-ga (pid 1744) is running... Hi, Laszlo If I understand correctly, this is the expected result, right? The qemu-ga service will not be started automatically after installation. But "chkconfig qemu-ga --list" should report "on" for runlevels 2-5, then the "qemu-ga" service will be started at next time guest boot up. Is it right? Thanks, Qunfang
Yes, this is the correct result (see comment 13). Thanks.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-1553.html