[OpenIndiana-discuss] VirtualBox

Sun Nov 18 20:47:03 UTC 2018

Hello!

Just to confirm the current state,

We are able to run VirtualBox virtual machines as user in Background by 
this:
VBoxHeadless -s <vmName>
and use the graphical frontend via RDP for example or SSH dependant of 
the guest OS,
save the current state of the VM to disk with
VBoxManage controlvm <vmName> savestate
as i am used to do with closing the virtualbox GUI

I tested one existing Win XP VM and one existent VM with recent Debian 
guest OS

if you like to see the gui do "sudo 'VirtualBox' " and a "machine->add"

Thanks again for your work, Aurélien

Greetings,
Stephan

On 17.11.18 07:24, Aurélien Larcher wrote:
> To be clear, Virtualbox's GUI does not run as non-root if hardening is
> enabled seemingly due to some loading security mechanism.
> The GUI runs as root.
> Headless runs as expected.
>
>
> On 11/16/18, Stephan Althaus <Stephan.Althaus at duedinghausen.eu> wrote:
>> 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
>>
>> _______________________________________________
>> openindiana-discuss mailing list
>> openindiana-discuss at openindiana.org
>> https://openindiana.org/mailman/listinfo/openindiana-discuss
>>
>