On Thu, Jul 06, 2017 at 06:55:46PM +0200, Reindl Harald wrote: > > > Am 06.07.2017 um 18:43 schrieb Zbigniew Jędrzejewski-Szmek: > >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 > > it's the answer to "Please make sure when running on non-VirtualBox > machines" not more and not less even if by accident the unit is > enabled/installed on bare metal We want to make the default installation do the right thing, as far as possible, on any system, without any explicit configuration or admin steps. In this case it's possible: if a virtualization "channel" is configured, we should assume that the user wants the service. This means that the "guest additions" rpms should be a) installed by default, b) enabled when installed, c) work ootb when running in the right virtualization and silently do nothing otherwise. Essentially, I want to take the same image and boot it in virtualbox, kvm, on bare metal, and in a container, and have things just work. > how do you come to the conclusion that a dsiablked service is > suddenly enabled just because of that additional > ConditionVirtualization in the systemd-unit? Like I wrote above, we want it installed and enabled by default. End users on windows can be expected to be even less experienced than average, so it's important to make things as automatic and seamless as possible. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
