1:57 p.m.
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(a)redhat.com>
>>>>
>>>>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
7:14 a.m.
New subject: F27 Self Contained Change: VirtualBox Guest Integration
On Thu, Jul 6, 2017 at 2:57 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
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.
Good luck with that. Since the Virtualbox guest additions are *not*
RPM enabled from their installation CD images, RPM is likely to
interfere with working, more recent installations of VBox drivers from
the "Guiest Additions" iso image, unless great caution is employed and
unless someone can convince them to be completely consistent in
installation tools, or to gracefully allow older and newer verson on
the same host.
>> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
9:43 a.m.
New subject: F27 Self Contained Change: VirtualBox Guest Integration
On Fri, 2017-07-07 at 08:14 -0400, Nico Kadel-Garcia wrote:
On Thu, Jul 6, 2017 at 2:57 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
> 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.
Good luck with that. Since the Virtualbox guest additions are *not*
RPM enabled from their installation CD images, RPM is likely to
interfere with working, more recent installations of VBox drivers
from
the "Guiest Additions" iso image, unless great caution is employed
and
unless someone can convince them to be completely consistent in
installation tools, or to gracefully allow older and newer verson on
the same host.
yes, we need install VirtualBox-guest-additions , which means
VirtualBox will be one Fedora Package and BTW I hope that Fedora use
RPMFusion package or based on that, I have many work there.
And there [1] we got vboxservice.service which have
ConditionVirtualization=|oracle
[1]
https://pkgs.rpmfusion.org/cgit/free/VirtualBox.git/tree/vboxservice.service
https://pkgs.rpmfusion.org/cgit/free/VirtualBox.git/tree/
> > 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Sérgio M. B.
8:36 a.m.
New subject: F27 Self Contained Change: VirtualBox Guest Integration
Hi,
On 07-07-17 16:43, Sérgio Basto wrote:
On Fri, 2017-07-07 at 08:14 -0400, Nico Kadel-Garcia wrote:
> On Thu, Jul 6, 2017 at 2:57 PM, Zbigniew Jędrzejewski-Szmek
> <zbyszek(a)in.waw.pl> wrote:
>
>> 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.
>
> Good luck with that. Since the Virtualbox guest additions are *not*
> RPM enabled from their installation CD images, RPM is likely to
> interfere with working, more recent installations of VBox drivers
> from
> the "Guiest Additions" iso image, unless great caution is employed
> and
> unless someone can convince them to be completely consistent in
> installation tools, or to gracefully allow older and newer verson on
> the same host.
yes, we need install VirtualBox-guest-additions , which means
VirtualBox will be one Fedora Package and BTW I hope that Fedora use
RPMFusion package or based on that, I have many work there.
And there [1] we got vboxservice.service which have
ConditionVirtualization=|oracle
No worries I do plan to use your package as a
starting point and
I will coordinate with you. For now I'm focussed on cleaning up the
kernel module stuff though.
Regards,
Hans
7:57 a.m.
New subject: F27 Self Contained Change: VirtualBox Guest Integration
On Sat, Jul 8, 2017 at 9:36 AM, Hans de Goede <hdegoede(a)redhat.com> wrote:
Hi,
On 07-07-17 16:43, Sérgio Basto wrote:
>
> On Fri, 2017-07-07 at 08:14 -0400, Nico Kadel-Garcia wrote:
>>
>> On Thu, Jul 6, 2017 at 2:57 PM, Zbigniew Jędrzejewski-Szmek
>> <zbyszek(a)in.waw.pl> wrote:
>>
>>> 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.
>>
>>
>> Good luck with that. Since the Virtualbox guest additions are *not*
>> RPM enabled from their installation CD images, RPM is likely to
>> interfere with working, more recent installations of VBox drivers
>> from
>> the "Guiest Additions" iso image, unless great caution is employed
>> and
>> unless someone can convince them to be completely consistent in
>> installation tools, or to gracefully allow older and newer verson on
>> the same host.
>
>
> yes, we need install VirtualBox-guest-additions , which means
> VirtualBox will be one Fedora Package and BTW I hope that Fedora use
> RPMFusion package or based on that, I have many work there.
> And there [1] we got vboxservice.service which have
> ConditionVirtualization=|oracle
No worries I do plan to use your package as a starting point and
I will coordinate with you. For now I'm focussed on cleaning up the
kernel module stuff though.
Do you expect this to be complete and upstream in time for F27?
While the upstream work is on-going, are you proposing to add the
drivers to the kernel package via a patch? The Change could read
either way on that.
josh
1:10 p.m.
New subject: F27 Self Contained Change: VirtualBox Guest Integration
Hi,
On 14-07-17 14:57, Josh Boyer wrote:
On Sat, Jul 8, 2017 at 9:36 AM, Hans de Goede
<hdegoede(a)redhat.com> wrote:
> Hi,
>
>
> On 07-07-17 16:43, Sérgio Basto wrote:
>>
>> On Fri, 2017-07-07 at 08:14 -0400, Nico Kadel-Garcia wrote:
>>>
>>> On Thu, Jul 6, 2017 at 2:57 PM, Zbigniew Jędrzejewski-Szmek
>>> <zbyszek(a)in.waw.pl> wrote:
>>>
>>>> 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.
>>>
>>>
>>> Good luck with that. Since the Virtualbox guest additions are *not*
>>> RPM enabled from their installation CD images, RPM is likely to
>>> interfere with working, more recent installations of VBox drivers
>>> from
>>> the "Guiest Additions" iso image, unless great caution is employed
>>> and
>>> unless someone can convince them to be completely consistent in
>>> installation tools, or to gracefully allow older and newer verson on
>>> the same host.
>>
>>
>> yes, we need install VirtualBox-guest-additions , which means
>> VirtualBox will be one Fedora Package and BTW I hope that Fedora use
>> RPMFusion package or based on that, I have many work there.
>> And there [1] we got vboxservice.service which have
>> ConditionVirtualization=|oracle
>
> No worries I do plan to use your package as a starting point and
> I will coordinate with you. For now I'm focussed on cleaning up the
> kernel module stuff though.
Do you expect this to be complete and upstream in time for F27?
I don't expect all the kernel-bits to be in the upstream kernel
F27 will use. I do hope to have them in -next (in staging likely)
so we would only have to carry patches for this for a short while.
Note the vboxvideo driver just got merged for 4.13-rc#, so that is
1 done, 2 to go: vboxguest and vboxsf, with the latter one being
quite small.
vboxguest is 100,000 lines of code which I plan to cut down to
aprox 10,000 as the rest is a portable runtime to allow the same
driver code to run on 4 different OS-es. This currently is my
main focus.
While the upstream work is on-going, are you proposing to add the
drivers to the kernel package via a patch?
Yes adding (some of) the drivers to the kernel package via a patch
is the plan, I plan to coordinate this with the kennel team when
I do the first upstream submission of the vboxguest driver, as then
I can actually show that this is just a well contained small
(10k lines) driver and not the monster it is now.
Regards,
Hans
2468
days inactive
2484
days old
5 comments
5 participants
participants (5)
-
Hans de Goede -
Josh Boyer -
Nico Kadel-Garcia -
Sérgio Basto -
Zbigniew Jędrzejewski-Szmek