#1107 Exception for service to be enabled by default
Closed None Opened 8 years ago by slaanesh.

= phenomenon =
There is currently a review pending for open-vm-tools, the user space tools for integrating Fedora and EPEL guests with VMWare products.

https://bugzilla.redhat.com/show_bug.cgi?id=905255

There is a service inside the package, and according to the Packaging Guidelines it is installed upon package installation and left disabled; the user has to explicitly enable it.

= background analysis =
Open VM Tools is installed only in VMWare guests, not useful at all on physical hosts or other virtualization guests and is not installed by default, only by the user.

There are '''no''' cases where a user would want to have the service installed and not enabled; the user wants the service running for sure as he/she is installing a VMWare guest.

The daemon does not open any network connection as it uses local device and services.

= implementation recommendation =
Though not strictly required, it would be beneficial to have the service start automatically at boot when the package is installed to ease administration.


Replying to [ticket:1107 slaanesh]:

There are '''no''' cases where a user would want to have the service installed and not enabled; the user wants the service running for sure as he/she is installing a VMWare guest.

One case that people sometimes fail to consider: development projects. I see from the spec file that this package produces an open-vm-tools-devel subpackage which provides shared libraries for linking against open-vm-tools. So it is conceivable that you would install the open-vm-tools package as a dependency of other packages, possibly even on systems that are NOT guests themselves.

So I have questions:
1. Does this package behave itself if installed and started on bare-metal hardware? If it's started on a non-guest, does it exit immediately with an error cleanly or does it run and consume resources?
1. Does the service need to be running in order for packages linked against the -devel package to succeed at building?
1. What local device and services does it require? UNIX sockets? Physical device access that may only be present on guests?

Replying to [comment:1 sgallagh]:

One case that people sometimes fail to consider: development projects. I see from the spec file that this package produces an open-vm-tools-devel subpackage which provides shared libraries for linking against open-vm-tools. So it is conceivable that you would install the open-vm-tools package as a dependency of other packages, possibly even on systems that are NOT guests themselves.

Good point, I think this is already a good explanation on why starting the service at boot is not a good thing.

It's started even on bare-metal, it prints an error in the journal but keeps running. Little resources are consumed, but some are; and is not required to develop for it.

Thanks,
--Simone

Replying to [comment:2 slaanesh]:

It's started even on bare-metal, it prints an error in the journal but keeps running. Little resources are consumed, but some are; and is not required to develop for it.

Does that make sense in any deployment method? Shouldn't the service just exit? (If so, preferable would be changing it upstream, but a Fedora-local patch would also be acceptable.)

Besides "it's specific to VMWare", what does the service actually ''do''? I couldn't find any documentation specific to the daemon, neither in the tarball nor at http://open-vm-tools.sourceforge.net/ .

Surely it should just have:

ConditionVirtualization=vmware

in the systemd service file?

Replying to [comment:4 notting]:

Surely it should just have:

!ConditionVirtualization=vmware

in the systemd service file?

Is that a real thing that exists and is trustworthy? Does it work with KVM too?

{{{
ConditionVirtualization= may be used to check whether the system is
executed in a virtualized environment and optionally test whether
it is a specific implementation. Takes either boolean value to
check if being executed in any virtualized environment, or one of
vm and container to test against a generic type of virtualization
solution, or one of qemu, kvm, vmware, microsoft, oracle, xen,
bochs, chroot, openvz, lxc, lxc-libvirt, systemd-nspawn to test
against a specific implementation. If multiple virtualization
technologies are nested only the innermost is considered. The test
may be negated by prepending an exclamation mark.
}}}

It's documented and in F-18, so presumably it works.

The daemon and its associated libraries allows you to do some things like:

{{{
-Passes messages from the host operating system to the guest operating system.
-Executes commands in the operating system to cleanly shut down or restart a system when you select power operations in.
-Sends a heartbeat to a VMware.
-Synchronizes the time in the guest operating system with the time in the host operating system.
-Runs scripts that help automate guest operating system operations. The scripts run when the virtual machine’s power state changes.
-Enables you to copy and paste text between the guest and host operating systems, and copy and paste files between the host operating systems and the guest operating systems.
}}}

In my VMWare infrastrcture 5 I can do most of those listed things, and the os presents itself as Fedora (woah!) instead of "Unknown Linux".

It relies on some device drivers, some of which are already in RHEL, Fedora has a few more and some more are being merged all the time, for example there are 2 more drivers being integrated in kernel 3.9.

In the bug referenced there is a discussion exactly on the drivers.

I did not know about the systemd condition "ConditionVirtualization=vmware"; it is actually pretty cool.
If I could use this it will be definitely ok.

I will make a test for it tomorrow and see if it works.

Thanks,
--Simone

Replying to [comment:7 slaanesh]:

I did not know about the systemd condition "ConditionVirtualization=vmware"; it is actually pretty cool.

This is great. I would love this condition check if it works as advertised. In fact, we do provide a binary 'vmware-checkvm' to do the same check and we do the check in the service configuration bundled inside the VMware Tools package distributed by VMware. Could someone on this bug let me know if there is similar check possible inside RPM too? May be we can disallow installation of open-vm-tools including this service if it is bare metal.

Replying to [comment:8 ravindrakumar]:

Replying to [comment:7 slaanesh]:

I did not know about the systemd condition "ConditionVirtualization=vmware"; it is actually pretty cool.

This is great. I would love this condition check if it works as advertised. In fact, we do provide a binary 'vmware-checkvm' to do the same check and we do the check in the service configuration bundled inside the VMware Tools package distributed by VMware. Could someone on this bug let me know if there is similar check possible inside RPM too? May be we can disallow installation of open-vm-tools including this service if it is bare metal.

Nack. You don't want to disallow installation of the RPM, because that would break the development scenario I described above (as well as breaking Koji when trying to build packages that rely on the -devel package).

I could be on-board with starting this service by default if-and-only-if it's running on a VMWare guest though. As long as the service isn't started by default on other platforms.

I will make a test for it tomorrow and see if it works.

@Simone I verified it. It is working as expected for Fedora 18. I'm making the change in
the service definition.

@sgallagh given the koji and mock requirements, I will leave the RPM without any such condition checks. I'm not too concerned on development use case because usually development
requires testing and testing would not be possible without installing open-vm-tools inside
a VM.

@notting thanks for the suggestion about ConditionVirtualization. This is working great.

Thanks for all the comments. Do we need to ask for something else?

By reading the package presets page [1] and the systemd scriptlets page [2] it seems that we need to add the open-vm-tools service "vmtoolsd" to the package preset for the service to start at boot.

[1] https://fedoraproject.org/wiki/Features/PackagePresets

[2] https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd

Thanks,

--Simone

I've checked systemd updates, the ConditionVirtualization tag is already included in very old systemd releases, Fedora 15 already had it.

So if it's ok to enable it in Fedora, we can enable it in 17, 18 and 19. The RHEL packages will be exempted from this, of course.

I think a formal FESCo approval is still required even in this limited configuration.

I'm +1 for starting it on VMWare only (the daemon description seems reasonable, the virt host interaction is not a security concern because the host can compromise the guest anyway).

Automatic activation on VMWare makes sense to me - +1.

+1 here as well, makes sense in this case.

That's +5, exception was approved.

Thanks very much to everybody, especially for the helpful systemd hint.

As in comment #12; to I need to ask separately for the inclusion in the presets for Fedora 18+?

Hello, sorry but I had no reply, should I file a separate bugzilla entry for updating the preset file?

http://pkgs.fedoraproject.org/cgit/systemd.git/log/90-default.preset

Thanks,
--Simone

Yes, please file a bug against systemd.

Login to comment on this ticket.

Metadata