[OpenIndiana-discuss] VirtualBox

Fri Nov 16 22:34:09 UTC 2018

Hello!

Short story:

I managed to build VirtualBox successfully. The target system is on 
SunOS dell 5.11 illumos-b75eb7e6b5 i86pc i386 i86pc

VirtualBox does not run on my target machine complaining about

ld.so.1: VirtualBox: fatal: libQt5XcbQpa.so.5: open failed: No such file 
or directory
ld.so.1: VirtualBox: fatal: relocation error: file 
/usr/lib/qt/5.8/plugins/amd64/platforms/libqxcb.so: symbol 
_ZN15QXcbIntegrationC1ERK11QStringListRiPPc: referenced symbol not found

I will investigate further - tomorrow evening maybe..

LONG story

My Package can be found and installed by doing this:
#pkg unset-publisher userland
#pkg set-publisher -g http://duedinghausen.eu:10000/userland userland
#pkg refresh
#pkg install 
pkg://userland/system/virtualbox@5.2.22,5.11-2018.0.0.0:20181116T220242Z

i tried and managed to get the sources of oi-userland virtualbox with 
date 2018/11/13

https://codeload.github.com/OpenIndiana/oi-userland/zip/e3d92fa79d298d84ba67a8b46c042a647841c6cb

First error when building:

/tank/src/oi-userland/components/sysutils/virtualbox/build/amd64/src/VBox/Devices/Audio/DrvHostOSSAudio.cpp:22:27: 
fatal error: sys/soundcard.h: No such file or directory
  #include <sys/soundcard.h>
                            ^
i installed

#pkg install pkg:/system/header/header-audio

to fix that.

Then, qt5 was not found. In the output i found a hint to do
source ./build/amd64/env.sh

But, QT5 was still not found. The directory stated in the env.sh was not 
correct for my system.
The QT PATH in the Makefile was set to /usr/qt/5, i changed that to 
/usr/lib/qt/5.8

next missing packages:
#pkg install pkg:/system/header/header-usb
#pkg install pkg:/system/header/header-ugen

  -- maybe i forgot to gmake env-prep before this all..

Finally, after install on the target system,
it does not run complaining about libQt5X11Extras.so.5
#pkg install qt5
   :-D

Greetings,
Stephan

On 14.11.18 20:40, Till Wegmüller wrote:
> Hi Tim
>
> It is quite hard to get to Feature parity with Virtualbox when it comes
> to Desktop Features. Both KVM and bHyve have traditionally been more
> used in the Server and Cloud Market. However I believe some workarounds
> can be made.
>
> First Proper Graphics Integration. I have since long ago stopped using
> any Virtualmachine Console for something like daily work with a GUI
> (Windows) The Built in RDP Server available in almost any Windows
> Version is massively Powerfull and the FOSS Implementation xfreerdp
> works well for many Use cases. Including Clipbord sharing any much more.
> Using the Virtual Machines Remote Desktop Capability is what you want in
> most cases.
>
> RedHat tried to offer a competing Product to Microsofts RDP with Spice
> but did not succeed that much. And as is unfortunately common with
> RedHat Software it makes heavy use of Linux exclusive functionality.
>
> Both bHyve and QEMU use VNC as default. TigerVNC which we have packaged
> should allow for Good resolution and Clipboard Sharing. You may need the
> Virtio Windows Dirvers and the Quemu Guest Agent though. I would guess
> since Virtualbox also uses software on the Guest for this purpose.
>
> bHyve looks like to be a step Back when it comes to Desktop features.
>
> As for Resolution. This depends very much on the Graphics device Qemu
> presents to the VM. We seem to have cirrus, qxl, vmware and std
> available. I believe std is vesa. At least qxl, cirrus and vmware should
> be able to support 1080p Dsktop resolutions. You will need to pass the
> correct -vga option when starting the VM.
>
> As for shared Folders. The situation seems a lot better here for both
> KVM and bHyve. Both Support virtio-9p aka VirtFS. Which has kernel
> drivers for at least Linux which can use the Filesystem as Root
> apparently. Unfortunatly Windows Driver Work is not yet that complete
> see [0]. But with some Poking of both the ReactOS and the virtio-win
> Community this will be the way to go for shared folders. What remains as
> a question is if we have virtio-9p support compiled with our version of
> Qemu as it is quite recent. See [1] for examples of usage.
>
> While finishing this mail I noticed the Features list on freerdp [2]. It
> has everything you wanted. Given the feature compiles in Illumos. I
> think the Quickest way to get to feature parity is using Windows RDP
> server and Freedrp.
>
> [0] https://github.com/virtio-win/kvm-guest-drivers-windows/issues/126
> [1] https://github.com/FreeRDP/FreeRDP/wiki/CommandLineInterface
> [2] https://github.com/FreeRDP/FreeRDP/wiki/CommandLineInterface
>
> Researching Greetings
> Till
> On 11/14/18 07:37 PM, Tim Mooney wrote:
>> In regard to: Re: [OpenIndiana-discuss] VirtualBox, Stephan Althaus
>> said...:
>>
>>> If you are on OmniOs / Omniosce, you have Bhyve.
>>> You can use that instead of virtualbox.
>>>
>>> With Openindiana, you could use QEMU-KVM as well..
>>> What are your personal reasons not to do so?
>> There was a thread a couple weeks ago where some people, myself included,
>> posted some of the reasons why they had previously found VirtualBox
>> preferrable to KVM.  The "feature parity" part of the thread kind of
>> starts with my post:
>>
>>      https://openindiana.org/pipermail/openindiana-discuss/2018-October/022445.html
>>
>>
>> Tim
> _______________________________________________
> openindiana-discuss mailing list
> openindiana-discuss at openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss