= 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]:
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]:
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]:
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?
!ConditionVirtualization=vmware
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.
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.
@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).
+1 from me as well
I agree, +1.
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
Yes, please file a bug against systemd.
Login to comment on this ticket.