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@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
