The spice-vdagentd service needs to be started by default if running inside a VM, otherwise spice will not work as well as it could. This used to happen by default in F17 i belive, but seems to not happen in F18 (nightly from yesterday).
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.