Bug 888297
| Summary: | qemu-ga should be enabled right after installation | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | David Jaša <djasa> |
| Component: | qemu-kvm | Assignee: | Jeff Cody <jcody> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.4 | CC: | acathrow, areis, berrange, bsarathy, eblake, flang, jcody, juzhang, lersek, lnovich, mkenneth, qzhang, virt-maint |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | qemu-kvm-0.12.1.2-2.391.el6 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-11-21 06:26:19 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 831387 | ||
|
Description
David Jaša
2012-12-18 13:12:56 UTC
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 |