Re: was -> wasn't Re: [VirtualBox] Use systemd-detect-virt to detect if we can install
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(a)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"