On Thu, Jul 06, 2017 at 06:17:53PM +0200, Reindl Harald wrote: > > > Am 06.07.2017 um 17:18 schrieb Zbigniew Jędrzejewski-Szmek: > >On Thu, Jul 06, 2017 at 04:10:29PM +0200, Jaroslav Reznik wrote: > >>= Proposed Self Contained Change: VirtualBox Guest Integration = > >>https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration > >> > >>Change owner(s): > >>* Hans de Goede <hdegoede@xxxxxxxxxx> > >> > >>VirtualBox is popular, easy to use virtual-machine software. The > >>purpose of this change is to ship the VirtualBox guest-drivers and > >>-tools by default in the Fedora workstation product. > > > >Please make sure when running on non-VirtualBox machines the > >drivers and services are not loaded and there are no warnings emitted. > >(I know we've had similar problems before — e.g. > >https://bugzilla.redhat.com/show_bug.cgi?id=999804, and some other > >bugs I cannot find now, so I'm just saying that this is something > >worth checking for from the start.) > >Probably the right solution is to use a udev rule to trigger starting > >of various services only if the "devices" are found. Something like > >/usr/lib/udev/rules.d/70-spice-vdagentd.rules in spice-vdagent.rpm > > this needs to be done like for VMware and if systemd don't detect > vbox systemd needs to be fixed instead dirty udev workarounds > > [Unit] > Description=VMware Tools > ConditionVirtualization=vmware I don't know how exactly how VirtualBox (or VMWare) implement guest additions, but using an udev rule in general is a better solution: 1. Using ConditionVirtualization=xxx assumes that the guest additions are *always* enabled when ConditionVirtualization=xxx is true. From what I have seen, that's generally not true, and you need to configure a specific "channel" in virtualization configuration. That means that ConditionVirtualization is just not specific enough. 2. Using ConditionVirtualization means that the service start is always enqueued (and skipped on the majority of systems). This appears in the logs, and it's just nicer not to have that. 3. If the "channel" is "hot pluggable", the device can appear any time after bootup. With the udev rule, that'll just work. ConditionVirtualization would only be checked once at bootup. The way that the configuration for spice-vdagent.service is done is pretty nice: 1. /usr/lib/udev/rules.d/70-spice-vdagentd.rules contains the rule that pulls in spice-vdagentd.target 2. spice-vdagentd.service has [Install] WantedBy=spice-vdagentd.target 3. /usr/lib/systemd/system-preset/90-default.preset has "enable spice-vdagentd.service" 4. spice-vdagent.rpm has "systemctl preset spice-vdagentd.service" This means that things work out of the box, are completely silent if not virtualized or the channel is not configured, and the admin can enable/disable the service at will, and it's possible to configure different or additional stuff to start if the channel is available. Flexible, but without any hacks. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
