Bug 876237
Summary: | Enable spice-vdagentd by default in a VM | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Alexander Larsson <alexl> |
Component: | systemd | Assignee: | systemd-maint |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 18 | CC: | berrange, crobinso, hdegoede, johannbg, lnykryn, marcandre.lureau, metherid, msekleta, notting, plautrba, sandmann, systemd-maint, virt-maint, vpavlin |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-11-23 07:39:09 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: |
Description
Alexander Larsson
2012-11-13 15:55:51 UTC
This is caused by the move to a systemd service + the new way services get enabled/disabled by default, which is controlled through a distro-wide policy file now, which AFAIK is part of systemd -> moving to systemd. systemd maintainers, note that the new spice-vdagent systemd service file (and friends) uses hardware activation, so it can safely be enabled by default without impacting non spice vms. What's the precise service name I shell add to the default-to-enable list? (In reply to comment #2) > What's the precise service name I shell add to the default-to-enable list? The service file is: /lib/systemd/system/spice-vdagentd.service Thanks, Hans Doesn't this udev rule handle things? $ cat /lib/udev/rules.d/70-spice-vdagentd.rules ACTION=="add", SUBSYSTEM=="virtio-ports", ENV{DEVLINKS}=="/dev/virtio-ports/com.redhat.spice.0", ENV{SYSTEMD_WANTS}="spice-vdagentd.target" For the QEMU guest agent the rule was slightly different to that: SUBSYSTEM=="virtio-ports", ATTR{name}=="org.qemu.guest_agent.0", \ TAG+="systemd" ENV{SYSTEMD_WANTS}="qemu-guest-agent.service" (In reply to comment #4) > Doesn't this udev rule handle things? > > $ cat /lib/udev/rules.d/70-spice-vdagentd.rules > ACTION=="add", SUBSYSTEM=="virtio-ports", > ENV{DEVLINKS}=="/dev/virtio-ports/com.redhat.spice.0", > ENV{SYSTEMD_WANTS}="spice-vdagentd.target" No, using hardware activation still requires the service to be explicitly enabled, it just means that even when enabled the service won't start if the hardware is not there. This was done (AFAIK) so that people who have ie bluetooth in their laptop, but never use it and don't want bluez to be running can disable it, etc. See: http://0pointer.de/blog/projects/socket-activation2.html And then the last line of the "Hardware Activation in Detail" paragraph. (In reply to comment #5) > For the QEMU guest agent the rule was slightly different to that: > > SUBSYSTEM=="virtio-ports", ATTR{name}=="org.qemu.guest_agent.0", \ > TAG+="systemd" ENV{SYSTEMD_WANTS}="qemu-guest-agent.service" Note that if you want to qemu guest agent to be started by default when installed, it needs to be added to systemd's default-to-enable list too, see my previous comment for rationale. systemd-195-9.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/systemd-195-9.fc18 Package systemd-195-9.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-195-9.fc18' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-18708/systemd-195-9.fc18 then log in and leave karma (feedback). systemd-195-8.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. |