The [Install] section is executed when the service is enabled. Enabling of the service is handled in the %post section by systemd scriptlet which checks the system presets.

Presets are maintained in fedora-release component and there are guidelines which services can be enabled [1]. As you can see in [2] the vmtoolsd.service is in the presets.

Therefore this request should be moved to fedora-release component.

[1] https://fedoraproject.org/wiki/Packaging:DefaultServices
[2] https://pagure.io/fedora-release/blob/master/f/90-default.preset#_84

Thanks Tomas. Reassigning to fedora-release. See 957135#c28 for how open-vm-tools had its daemon added to presets.

There is a question as to whether the other guest Hyper-V daemons (hypervvssd, hypervfcopyd) should also be preset to on. I don't have strong feelings on them because I don't think every Hyper-V user is necessarily using them but perhaps it makes sense to change them all in one go.

(In reply to Sitsofe Wheeler from comment #3)
> There is a question as to whether the other guest Hyper-V daemons
> (hypervvssd, hypervfcopyd) should also be preset to on. I don't have strong
> feelings on them because I don't think every Hyper-V user is necessarily
> using them but perhaps it makes sense to change them all in one go.

Sitsofe, can you please add some information about how these daemons work? Specifically, there are several sections on the https://fedoraproject.org/wiki/Packaging:DefaultServices that may apply:

1) Are these services safe to start without manual configuration?
2) Do any of these services listen on an external network port? (e.g. do they have a public configuration interface or anything like that?)
3) Are these services persistent (running all the time/socket-activated) or are they "run once to set something up and then exit until the next boot"?

Please answer these questions for all the services in question. Depending on the answers, I may be able to just enable these for you right away. Otherwise, we'll have to take it to FESCo for a decision.

> 1) Are these services safe to start without manual configuration?
> 2) Do any of these services listen on an external network port? (e.g. do
> they have a public configuration interface or anything like that?)
> 3) Are these services persistent (running all the time/socket-activated) or
> are they "run once to set something up and then exit until the next boot"?

4) do they exit cleanly and not run if the underlying hypervisor isn't hyper V so as not to consume resources unnecessarily

1) All daemons listen on either via netlink (old) or special character device (new) so they can accept/send information back to the host. If the permissions on the character devices are set correctly then non-priviledges users won't be able to access them (see bug #1241636 SELinux bug for the permissions being too tight). I suppose hypervfcopyd could be used from the host to force the guest to overwrite key files. Similarly hypervkvpd.service can be used to try and reconfigure the guest's network from the host (but if your on the host and can control the VM you can just power the VM down or rip its disks away etc).
2) No they don't listen on external ports.
3) Yes the services are persistent.
4) They only start in the first place if the hypervisor is detected as microsoft: See ConditionVirtualization in http://pkgs.fedoraproject.org/cgit/hyperv-daemons.git/tree/hypervkvpd.service as an example.

(In reply to Sitsofe Wheeler from comment #6)
> 1) All daemons listen on either via netlink (old) or special character
> device (new) so they can accept/send information back to the host. If the
> permissions on the character devices are set correctly then non-priviledges
> users won't be able to access them (see bug #1241636 SELinux bug for the
> permissions being too tight). I suppose hypervfcopyd could be used from the
> host to force the guest to overwrite key files. Similarly hypervkvpd.service
> can be used to try and reconfigure the guest's network from the host (but if
> your on the host and can control the VM you can just power the VM down or
> rip its disks away etc).


By this, I was mostly asking whether the service could always be trusted to start immediately after package installation, or if one would need to make changes manually before it would run properly. I assume that the default configuration of the character devices will be to have appropriate permissions with no non-privileged access. Important follow-up question: you mention the SELinux protection; is this additional or is it mandatory in order to restrict these character devices to the privileged user? We need to make sure that the default configuration of services is not *dependent* upon SELinux, since many users disable it.

Assuming that the default state with SELinux disabled is to allow only root services to access these character devices, I'm fine with enabling this by default in the 90-default.preset file. Confirm the above and I'll make the change.

The SELinux protection is additional, the /dev/vmbus/hv_kvp* devices have the following regular permissions:
# ls -l /dev/vmbus/hv_*
crw------- 1 root root 10, 58 Nov  9 21:43 /dev/vmbus/hv_kvp
crw------- 1 root root 10, 57 Nov  9 21:43 /dev/vmbus/hv_vss

Pull-requests issued for F23 and Rawhide:

* https://pagure.io/fedora-release/pull-request/16 (Rawhide/F24)
* https://pagure.io/fedora-release/pull-request/17 (F23)

This didn't seem to make it's way into Fedora 23 - is there something more that needed to be done?

(On a technicality the comment is above
+ # Hyper-V guest support daemons
+ # https://bugzilla.redhat.com/show_bug.cgi?id=1279322
+ enable vmtoolsd.service

vmtoolsd.service is actually the service for VMware/ESXi and is nothing to do with Hyper-V)

Yeah, but bellow that in the patch is: 

+enable hypervvssd.service
+enable hypervfcopyd.service
+enable hypervkvpd.service

I don't think there has been a fedora-release release for f23 since this was added.

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions