was -> wasn't Re: [VirtualBox] Use systemd-detect-virt to detect if we can install

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 30 November 2016 at 22:10, Sérgio Basto wrote:
> On Qua, 2016-11-30 at 21:22 +0100, Nicolas Chauvet wrote:
> > 2016-11-30 18:07 GMT+01:00 Sérgio Basto <sergio at serjux.com>:
> > ....
> > > 
> > > The only problem is "We should avoid installation of VirtualBox-
> > > guest-
> > > additions on bare metal", have you any suggestion that can improve
> > > this
> > > solution ?
> 
> > You have wrong premise. You want to avoid the "installation" to avoid
> > the conflict where you only need to avoid the "activation" of the
> > guest additions, when relevant.
> > So at the end it should be possible to even install the
> > VirtualBox-guest-additon on bare hardware, or hypervisor or kvm
> > guest,
> > etc.
> 
> No, Conflicts in rpm packages was artificial, to avoid installation
> of VirtualBox-guest-additions on bare metal and that was the only
> propose of conflicts. 

We know that. That was not the point.

> Again, VirtualBox-guest-additions should not be installed in bare metal
> or in any other place that isn't a VirtualBox vm.  Package have kernel
> modules, udev rules, xinit autostart, desktop autostart, services that
> try synchronize time, share clipboard, usb proxies etc , that we should
> avoid install on bare metal.

No. You don't understand. Installation does not have to equal activation
or loading of the modules/rules/services etc. Nicolas and I are trying
to explain to you that it's most likely possible to adapt the package so
that it can be installed on bare metal without any adverse effects.

> > Also I don't understand why you mix kvm and oracle, the action of the
> > virtualbox-guest-addion is "not" relevant on kvm guest, not at all.
> 
> Systemd of RHEL7 says that Virtualization is kvm instead oracle, to
> guest-additions work on EPEL7, we need add kvm rule.

Then do that only on EPEL7 and add a comment to the SPEC file.

> > For example, if you add ConditionVirtualization=|oracle to
> > vboxservice.service, you can probably add multiple ExecStartPre lines
> > that have the list of modules only needed by the guest.
> > Then you can drop /usr/lib/modules-load.d/VirtualBox-guest.conf.
> > 
> > In, fedora you are probably using modesettiing driver by default as
> > Xorg driver, but you can probably use something like in nvidia
> > /usr/share/X11/xorg.conf.d/vboxvideo.conf
> > Section "OutputClass"
> >     Identifier "vboxvideo"
> >     MatchDriver "vboxvideo"
> >     Driver "vboxvideo"
> > EndSection
> 
> No, to load of vboxvideo doesn't need that lines , that why guest-
> additions breaks X11 ( I had that experience , now with new vboxvideo
> model I don't know)  . 

I still don't understand why having that driver present breaks existing
X11 configuration if the virtual hardware for that driver isn't present.
Certainly having drivers for different graphics cards on my machine
doesn't break my configuration.

> > I'm not sure to understand why the other are bad ? For example, there
> > is no conflict with udev 60-vboxguest.rules if the modules are not
> > loaded.
> 
> if we copy file to udev the rules are loaded 

Why does that break anything?

> > So Sergio, do you understand the concept here ?
> 
> No , the question is we need make a mechanism to avoid installation
> of guest-additions in host systems , old mechanism was add conflicts
> between host packages and guest package, but as bug 3425 some would
> like install VirtualBox also on guest . 

You don't understand. Please stop trying to prevent guest-additions
installation on any system and start trying to fix it so that it doesn't
break anything.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"