Child pages
  • 7.2 VirtualBox
Skip to end of metadata
Go to start of metadata

General overview

VirtualBox is a Type 2 Hypervisor, a user-space program which runs in the host operating system (in our case, the host OS is OpenIndiana) and emulates a hardware virtual machine, and is one of very few hypervisors running on Solaris and its descendants. It also runs on Linux, MacOS and Windows, is GPL2'ed, and the VirtualBox 4.x Extension Pack with extra features is free for "Personal Use and Evaluation", making it a very versatile tool. Its public discussion for running under Solaris-related operating systems is maintained at the product forum here: (participation may require a free Oracle SSO login).

This hypervisor can help when you need to run different operating systems (i.e. to support particular software) with the benefits of OpenIndiana (including CrossBow networking, ZFS storage, local zones for resource allocation, etc.) It may also be useful for developers seeking to test newly compiled OpenIndiana distributions without risk to their host OS, or to isolate certain tasks from their interactive environment.

If you plan to compile or test illumos/OpenIndiana under VirtualBox, note that there are often reported performance problems (during compilation, which can take days) and there may be some issues running with debug kernels and timer skews. There are also reports of things working properly, though (wink)

Finally, in the command-line examples below the ":;" characters starting the lines are the root's or user's (with sudo) shell prompt.

Virtualization features

VirtualBox provides the same CPU feature set to its hosted VMs as are available to the host CPU (i.e. it may pose certain problems to migrate a VM between hosts using different CPU hardware, though there are workarounds). VirtualBox also enhances its performance by using some drivers (kernel modules) in the host OS, as well as providing optimized virtual hardware drivers for some guest OSes. VirtualBox can emulate SMP multiprocessing (multiple hardware cores not required, but VT-X CPU hardware extensions may be needed), and 32-bit and 64-bit CPUs (on 64-bit hardware at least).

Note that CPU-accelerated virtualization (VT-X, VT-D and others) may only be claimed by one hypervisor program at a time.

In case of illumos-based OSes there may be a conflict between VirtualBox and KVM, even if neither subsystem is running a VM – the kernel-side drivers included in the products and loaded at boot may provide conflicts already. It is likely that to run one hypervisor, you would have to uninstall or otherwise disable all traces of another on this particular box.

Some VirtualBox features overlap with those provided by an OS, because not all supported host OSes have these features. Ones which may be used directly or ignored on OpenIndiana include: an iSCSI client (initiator) and the NAT engine for networked VMs – the host OS features may be better used instead. In particular, for bridged networking setup Solaris VNICs must be used, along with a fixed MAC address of the VNIC dedicated to a particular VM. Intricate networked labs can be created with Solaris Etherstubs (virtual switches).

Recent releases of VirtualBox 4.x and newer, by default expect a Solaris with CrossBow support to be the Oracle Solaris 11 with somewhat different kernel capabilities in comparison to illumos/OpenIndiana, and a simple install-time workaround (touch /etc/vboxinst_vboxflt) may be needed to use the particular network virtualization filter driver in the host OS.

In recent illumos, with implemented SMAP functions and using Intel Haswell and newer Intel CPU, since VirtaulBox binaries are made for Solaris and Solaris does not enable SMAP support, binaries are built without SMAP support and can reset illumos host upon run. Workaround is to put: set disable_smap=1 in /etc/system and reboot, before starting VirtualBox, until illumos SMAP support in VirtualBox is enabled or VirtualBox is built locally for Openindiana/illumos.

Also note that in order to run VirtualBox VMs, available on-disk swap space is required (sized as the VM's RAM size), even if the swap space is not really actively used.

Virtual disks can be used from files (including those served over NFS) and block devices (including ZFS volumes, possibly served over iSCSI). It is often convenient to use ZFS snapshots and clones to near-instantly and with zero storage overhead provide new VMs, originally identical to an administratively maintained "golden image", to end-users. For example, this is used in commercial and self-made VDI deployments and can be used in a (private) cloud of standardized server VMs.

Management access and resource capping

VirtualBox on Solaris hosts includes X11 support for the GUI management wizard and interactive access to the VM consoles. It is also possible to manage virtual machines using only the command line, and run them in a headless mode (console access may optionally be published via RDP). The distribution also includes a module for SOAP-based web services to manage VMs using some third-party management engines, many of them are open-sourced and provide a Web-GUI equivalent to a local X11 GUI. Installation and/or execution may require (depend on) some graphics-related libraries which must be added on the host; light-weight VNC desktops can be used for remote administration.

VirtualBox VMs can be contained in Solaris local zones, which allows to delegate administrative access over the VMs and limit/control/monitor overall system resource allocation, reservation and consumption (and, perhaps, different CPU priorities and scheduling preferences). Also, if VirtualBox is only used in local zones, this may help avoid installation of X11 in the global zone.

X11 dependencies

It is recommended to use OpenIndiana Desktop as the host OS, so all the GUI dependencies will be satisfied.  If you are using some other distribution, you might need to install some X11-related libraries to execute VirtualBox GUI programs. This can be very difficult.

The required (legacy SVR4) package names should be listed and requested by the distribution package; if you've skipped those requirements and now the programs can't run, you can use IPS pkg search to find and install the packages with libraries that VirtualBox can't find on your system; for example:

:; pkg rebuild-index
:; pkg search -l libfreetype'*.so'
INDEX      ACTION VALUE                          PACKAGE
basename   link   usr/lib/         pkg:/system/library/freetype-2@2.4.9-
:; pkg search -l 'libXi*.so'
INDEX       ACTION VALUE                                           PACKAGE
basename    link   usr/X11/lib/amd64/              pkg:/x11/library/libxi@1.3.2-
basename    link   usr/X11/lib/amd64/        pkg:/x11/library/libxinerama@1.1-
pkg.fmri    set       pkg:/x11/library/libxi@1.3.2-
pkg.fmri    set pkg:/x11/library/libxinerama@1.1-
:; pkg search -l 'libXrender*.so'
INDEX      ACTION VALUE                           PACKAGE
basename   link   usr/X11/lib/amd64/ pkg:/x11/library/libxrender@0.9.6-

In the example above I used the -l option to search in the locally-installed packages (the libs my VBox apparently uses). For example, there are some copies provided with Java as well. The search command also suggested that I rebuild my indexes, so I added that above.

Apparently, for this example you'd have to install the three packages above (recursing for dependencies), then reiterate until your VBox installs and runs successfully – and doesn't ask for more libs (wink) (you can use ldd to check VirtualBox's binaries and libraries for dynamic dependencies). Install the packages found above:

:; pkg install freetype-2 libxi libxrender

NOTE: The renamed IPS packages also define the legacy SUNW* package names that they "replace". You can use those legacy package names for searches or IPS installation, i.e.:

### You can "pkg search '*freetype*' | grep legacy" if you can't guess old pkg name
:; pkg search SUNWfreetype2 | grep legacy
legacy_pkg  legacy SUNWfreetype2      pkg:/system/library/freetype-2@2.4.9-

:; pkg install SUNWfreetype2
            Packages to update:   1    
       Create boot environment:  No
Create backup boot environment: Yes

Hopefully, since these are IPS packages now under the hood, asking for their installation should pull up all their needed dependency packages too.

Virtual Machines and ZFS

If you don't do anything special with ZFS, then VirtualBox has some built-in snapshot capabilities, but it works by making filesystem level copies of files (or, rather, writing new changes of virtual disk data into new storage files). Quite portable, but not as good as what you want, if you enjoy the features of ZFS. Also, nobody forbids you to mix the two approaches.

  • The simplest thing is to just create a new ZFS filesystem each time you create a new VM.  By default, VirtualBox will store guest VM's in .vdifiles. But this has some limitations:
    • By default, new files have no reservation and no refreservation. This means, as you consume storage in your pool, it is possible to run out of storage, and accidentally crash all your guest VM's with IO errors. If you're clever, you can create your own reservations and refreservations on the dataset that will contain the VM images in order to avoid this problem -- but you need to account for ZFS metadata too. Approx 3% higher than the size of your VDI might be correct.
    • Guest performance in .vdi files seems to be noticeably slower than guest performance in zvol's.
  • You may create new zvol's to use as guest storage instead (see below). This also has an important limitation.
    • (Note, it may be possible to solve this with something like zfs properties, zpool properties, delegation, or something like that.  If anybody puts in the effort to figure it out, please update this page or at least email the zfs-discuss mailing list, so one of us will come update this page.)
    • When the host OS reboots, or remounts filesystems, by default, a zvol will be owned by root, and it needs to be owned by the user who runs the VirtualBox process. So you need to script the sudo chown of the zvol's.  Again, see below.
    • Also note that ZFS volumes use a fixed-size blocks, and typically these are smaller than ZFS filesystem blocks (all configurable at dataset creation time). While a change in a single block or cluster of a filesystem in a VM would typically result in a smaller block (re-)write in a ZFS volume, and a higher hit rate if deduplication is used, volumes also have larger storage overheads due to more needed metadata (especially noticeable on 4KB-sectored disks and thus ZFS pools with ashift=12).
Installation and Configuration Process
  • To install VirtualBox:
    • Before you begin, you will most likely want to have GUI access to the host machine, even if it is temporary.
      • You can enable VNC.  For example: 

        :; vncserver :1 -geometry 1350x820
        :; vncserver -kill :1

        I personally create the above commands as aliases in my ~/.bashrc profile file:

        alias runvncserver='vncserver :1 -geometry 1350x820'
      • You can use the physical console of the machine.
      • You can use ssh X-forwarding (but only as long as your terminal remains always connected for the duration of your work with GUI) – change /etc/ssh/sshd_config and svcadm restart ssh for this.
      • I think there's some way to enable XDMCP or RDP access to the physical console, and maybe some other options.
    • Download the latest "*SunOS*" Solaris VirtualBox binaries (GPL-licensed) from and/or browse here: (you can use wget or curl to do the download straight to your OI environment).
      Before installing Virtualbox 4.x on Openindiana, you could do: touch /etc/vboxinst_vboxflt to make host-ony networking work on OI (due to not recognizing CrossBow during install).
      Install it with a bit of automated copy-pasting (update VBVERSION here to match your downloaded version):

      :; export VBVERSION=4.2.0
      :; mkdir VirtualBox-${VBVERSION}
      :; cd VirtualBox-${VBVERSION}
      :; tar xzf ../VirtualBox-${VBVERSION}*.tar.gz
      :; sudo pkgadd -d VirtualBox-${VBVERSION}*.pkg -n -a autoresponse SUNWvbox


      • The installer may complain about other incompatibilities between OI and what it expects of supported commercial Solaris 10/11/12 OSes, based on the version number and not actual capabilities of the kernel, and for that reason deny installation of some drivers such as USB support. With recent illumos-based distro uname changes that did away with version numbers completely and/or kernel package numbering pattern changes, this script breaks down even worse.
        A patch for is available to coerce it into installing appropriate kernel modules (and installing or un-installing at all, in some cases); see the patch project here: and specifically downloadable (text patch file) or (resulting script – fixed against a recent upstream version). To use this patch, you can unpack the downloaded virtualbox SVR4 package (see pkgtrans) and gpatch -p1 the file in the package with the patch, update the pkgmap with new size and checksums – and you're ready to go. Instructions are available in the README file of the patch project.

    • Optionally, download the latest Oracle VM Extension Pack (PUEL-licensed) from the same location. This extension pack provides many enhanced features, but it is generally not free for use, though a number of free-to-use situations are defined. Read the PUEL for details to see if your deployment applies to be free, or pay Oracle for a license (approx $50). Most notably, the extension pack provides USB2.0 (EHCI) support (note that the basic USB support and filtering is available in the core GPL'ed package), webcam passthrough, and guest machine console via VRDP. The guest machine console via RDP is particularly useful if you plan to run a headless server.
      Optionally, install it:
      • If you are installing the Oracle VM Extension Pack, you may either launch the VirtualBox GUI client (/opt/VirtualBox/VirtualBox) and go to the File / Preferences / Extensions menu, or do it from the command line:

        :; sudo VBoxManage extpack install \
    • By default, your typical unprivileged user account does not have sufficient access to the USB subsystem. But when you installed VirtualBox, a new group was created, "vboxuser" – so just add yourself to that group. Of course, that's irrelevant if you don't plan to do USB pass-thru to any of your guest machines.
    • By default, the VirtualBox "Host key" is Right-Ctrl (that's the key or key combination used to release a keyboard/mouse captured  by a VM's console, and to issue menu commands by using shortcut keys). This is particularly a problem if you will ever connect with a Mac, which doesn't have a Right-Ctrl key.
      Solve the problem preventively: Launch the VirtualBox GUI client, go to File / Preferences / Input, and press the Left Ctrl + Alt keys or whatever you'd prefer. (You should see it immediately take effect; you might have to click in the key selection field in order for it to take your input.)

    Complete process to create new VM with full ZFS support for its files:

    ### Virtual Machine owner's UNIX user account name
    :; export VBOXUSER=username
    ### pool/dataset name (path) that holds different VM storage components
    :; export VMSTORAGE=storage/virtualmachines
    :; export VMMOUNT=`zfs list -Ho mountpoint ${VMSTORAGE}`
    ### Create the storage container for a new VM
    :; export NEWMACHINENAME=foobar
    :; sudo zfs create $VMSTORAGE/$NEWMACHINENAME

    Note: enabling compression will improve performance for most situations, but can hurt performance depending on your usage. You might consider zle compression which only affects contiguous stretches of null (0x00) bytes.

    :; sudo zfs set compression=on $VMSTORAGE/$NEWMACHINENAME
    :; sudo zfs set compression=zle $VMSTORAGE/$NEWMACHINENAME

    Note: disabling ZIL will definitely improve performance, but is generally unsafe, unless you understand the types of workloads that can be done safely.

    #(optional, and very much not recommended - unless...)#
    :; sudo zfs set sync=disabled $VMSTORAGE/$NEWMACHINENAME

    If you are planning to use .vdi files, you're done now. Go into VirtualBox GUI or use the command-line utilities to create your guest machine in the newly created ZFS filesystem.
    If you are planning to use ZFS volumes (zvol's) as "raw disk" storage, these additional steps (similar to delegation of raw disks and partitions) are necessary:

    ### (To create an 80g volume)
    :; sudo zfs create -V 80g $VMSTORAGE/$NEWMACHINENAME/${NEWMACHINENAME}_disk0
    :; sudo chown $VBOXUSER /dev/zvol/*dsk/$VMSTORAGE/$NEWMACHINENAME/${NEWMACHINENAME}_disk0
    :; VBoxManage internalcommands createrawvmdk -filename \
       -rawdisk /dev/zvol/rdsk/$VMSTORAGE/$NEWMACHINENAME/${NEWMACHINENAME}_disk0

    Now, when you create the guest VM, add the existing .vmdk file (see the -filename parameter above) as a "pre-existing" disk image. It holds pointers for VirtualBox to find the provided "raw storage".
    In the future, repeat the "sudo chown" commands shown above after each reboot, or every time you're about to launch the VM. You may want to create a wrapper script for the sudo chown and VirtualBox start, and you may want to add the NOPASSWD option for that command in your sudo configuration (see /etc/sudoers or equivalent LDAP entries). 
    The least secure solution would have a line similar to the following in the sudo configuration, allowing the named user to elevate privileges for any commands:

    username ALL=(ALL) NOPASSWD: ALL

VMs as SMF service instances

Using third-party scripts, it is possible to manage VirtualBox virtual machines as Solaris SMF service instances. This allows to set up dependencies between VMs and other system services to ensure a definite host/VM startup and shutdown order, as well as to simply enable auto-starting and proper shutdown of VMs on headless server hosts. 

  • At the time of this writing (Oct 2012) the latest VirtualBox (4.2.0) release comes with support to start guest machines via SMF (see the VirtualBox User Manual for more info) but unfortunately, this support seems to only start a configured list of VMs under a single SMF service instance, seemingly lacks an ability to gracefully shutdown guests during host system shutdown/reboot, and lacks some other more advanced features. 
    So some other projects also exist, to use instead:
  • The "vboxsvc - VirtualBox SMF service wrapper" project ( is a fully featured, "everything and kitchen sink" solution.  Its discussion is in VirtualBox forum, thread "[Free as in beer] SMF service for VirtualBox VM's".
    This project provides an SMF method script and manifest to wrap execution/hibernation/shutdown and lifetime monitoring of a VM (i.e. a frozen VM can be forced to reboot), as well as optional automated ZFS snapshot creation upon VM startup/shutdown, "kidnapping" of a VM into a GUI client and back into a headless SMF service, and many other administrative features. An SVR4 package of the project deliverables is also available. New development on the project currently adds better support for desktop systems that use interactive VMs with GUI consoles, as well as a solution to non-root ownership of ZFS volumes (access rights not surviving the host reboot, as discussed above).
  • The "simplesmf" project ( provides a very simple virtualbox-guest-control SMF service, which executes simple scripts. So if you're comfortable with shell scripting and unfamiliar with the complexities of SMF, this might be a good solution for you.  Does not support lifetime monitoring (if guest VM dies, simplesmf service will not know, and will not do anything about it).

Local zones and VMs

For a number of administrative reasons it may be desirable – and is certainly possible for a long time – to run VMs in local zones. Rationales include the use of zone-wide resource-capping, grouping of interdependent VMs, set-up of independent lab environments, and administrative control delegation without compromising security of the host and other zones. Some of these reasons are better explained in Jeff Victor's "Layered Virtualization".

In order to run VMs in a local zone, you need only install the VirtualBox software in the zone (as well as in GZ for the kernel dirvers and to svcadm enable virtualbox/zoneaccess – even if you don't run VMs in the GZ itself), the SMF scripts if desired, and pass the required device driver nodes into the zone. One is always required, add it by running in the global zone a command similar to:

:; zonecfg -z vboxzone "add device; set match=/dev/vboxdrv; end" 
  • Obviously, substitute your zone's name for vboxzone above.

Other devices that people (try to) delegate may include audio (/dev/audio) and USB pass-through (/dev/vboxusbmon); search the net for more examples (and refine the examples in this page, please).

For example, to use the VirtualBox Host-only networking (may also be needed for VirtualBox NAT) add the filter driver to the zone by passing such devices as /dev/vboxnet0 and/or /dev/vboxnet, /dev/vboxflt. Alternately (or in conjunction with Host-Only networking) you can pass particular VNICs defined in the GZ and perhaps attached there to a particular etherstub for an emulated network lab using externally-available network adapters and an exclusive-IP networking stack in the zone.

VNIC passing might require such a snippet in the local zone's XML manifest:

  <network address="" physical="vnic162020"/>
  <device match="/dev/net/vnic162020"/> 
  • You should also run a command like "touch /etc/hostname.vnic162020" (corresponding to your device names) and create empty files in the local zone. Upon zone boot these interfaces will become defined (plumb'ed, but not configured with an IP address nor up'ed), and thus can be used by VirtualBox to attach VMs. Usual rules still apply – that MAC addresses of the host VNIC and its bound guest NIC interfaces must be the same.

Also, the use of advanced networking in the local zone (if required and not counter to your administrative intentions) may generally benefit from extended permissions assigned to the zone, i.e. this header was used to define a zone which acts as a NAT/router between the internet and several etherstub "switches" and VMs attached to them:

<zone name="emulan" zonepath="/zones/emulan" autoboot="true" ip-type="exclusive" limitpriv="default,net_rawaccess">

Bridged networking

About bridging in VirtualBox 

One of the popular ways to use VirtualBox machines is to "bridge" them over a networking interface on the host, so that for the rest of the LAN they would seem as individual hosts, complete with a dedicated MAC (Ethernet) address and an IP address (you may need to arrange this resource with your LAN admin to avoid conflicts and surprises, and/or to permit communications on the networking gear you are connected to). In particular, bridging allows to use the VMs as "servers" of some protocols which would otherwise require hassle with NAT to publish particular ports, which is especially inconvenient with dynamic-port protocols like RPC.

Normally (as on Solaris 10 and other OSes) bridging would put the interface into "promiscuous mode" (like a "sniffer") so that it can capture any Ethernet frames, and not only those addressed to the physical host NIC's MAC addresses. This can put undesired extra processing load on the host networking subsystem, and may be limited by OS security provisions. This also happens to be occasionally glitchy on OpenSolaris and its descendants, for example, with intermittent communications problems between a host and its guests (while other systems on the LAN communicate quite well).

VirtualBox has a long history of supporting the (Open)Solaris VNIC interfaces for bridging, however, with some limitations: the host should bridge each virtual-hardware NIC from a virtual machine ("vHW NIC" below) over a dedicated host CrossBow VNIC, and the MAC address of the VNIC should be the same as configured on the vHW NIC. (Solaris 11 has since developed a different implementation of CrossBow which does not require such matching.)

Configuring a bridged interface over a dedicated host VNIC 

Query the bridged VM for its (automatically generated) vHW NIC settings:

:; /opt/VirtualBox/VBoxManage showvminfo myVM --machinereadable --details | \
   egrep '^(nic|bridge|mac)' | grep -v none
bridgeadapter1="e1000g0 - Intel PRO/1000 Gigabit Ethernet"
  • Here, the host's interface named e1000g0 is used for bridging the vHW interface number 1 (of usually 8 possible) with the reported MAC address.

Create a VNIC with a link over the same host NIC (and optionally bound to a specific external network's VLAN, see -v parameter) and with the same MAC address as the vHW NIC above:

:; dladm create-vnic -l e1000g0 -m 08:00:27:F6:DC:BD vnic1
  • Here, we've named the VNIC in a default numbering manner. Another option, for systems with multiple connected subnets and persistent IP addressing, is to name the VNICs with a number similar to the IP address, i.e. vnic93008 might stand for

 Bridge the vHW NIC over the dedicated VNIC (this may require that the guest VM is shut down):

:; /opt/VirtualBox/VBoxManage modifyvm myVM --bridgeadapter1 vnic1

Verify the bridged VM for its vHW NIC settings:

:; /opt/VirtualBox/VBoxManage showvminfo myVM --machinereadable --details | \
   egrep '^(nic|bridge|mac)' | grep -v none
bridgeadapter1="vnic1 - Virtual Network Interface Ethernet"

Notes on bridging

VirtualBox is known for unstable command-line "API", so in future versions you might need slightly different configuration options. A somewhat more portable approach might be to use dladm on command line, and configure VirtualBox via its X11-GUI or by directly editing of the VM manifest files (note that for such file-based editions to take hold, no VirtualBox-related processes should be running – especially not the VBoxSVC registry daemon).

If you use VirtualBox VM's in local zones, you should create the VNICs in the global zone and delegate them (as "matched" devices) into the local zone.

You should not configure the resulting interfaces in the GZ or LZ operating environment any further (that is, no plumbing, no IP addreses, no /etc/hostname.* files are required nor desired).

Notes for installing VirtualBox on Hipster

If you recieve and error similar to this:

Oracle VM VirtualBox(i386) 5.1.22,REV=2017.
Oracle Corporation
## Executing checkinstall script.
Checking package dependencies...
## Missing packages:
## IPS :  system/library/gcc/gcc-c++-runtime or system/library/gcc-45-runtime system/library/gcc/gcc-c-runtime or system/library/gcc-45-runtime
## SVr4:  SUNWPython SUNWPython-devel
## Please install either the IPS or SVr4 packages before installing VirtualBox.
pkgadd: ERROR: checkinstall script did not complete successfully

Installation of <SUNWvbox> failed.
No changes were made to the system.
It is because "The error is that the pre-install script checks that 'gcc-45-runtime' is installed but this package does not exist on Hipster, only on Solaris."
Jim Klimov has a workaround at

  • NOTE: another option would be (example for version 5.1.30)

    [2017-10-26 13:13:00] pkgtrans VirtualBox-5.1.30-SunOS-amd64-r118389.pkg . all
    [2017-10-26 13:13:10] rm SUNWvbox/install/checkinstall
    [2017-10-26 13:13:16] sed -i /checkinstall/d SUNWvbox/pkgmap
    [2017-10-26 13:13:25] pfexec pkgadd -d . SUNWvbox

Reinstalling Virtuabox Guest Additions

Whenever the Xorg server is updated to a newer major release, the Virtuabox video driver needs be reinstalled because of ABI change.

After rebooting with a newly installed Xorg video server, the login manager lightdm should go to maintenance as the Xorg server cannot start with the previous (ABI incompatible) vboxvideo module.

Jun 11 21:19:49 openindiana svc.startd[10]: [ID 652011 daemon.warning] svc:/application/graphical-login/lightdm:default: Method "/lib/svc/method/svc-lightdm stop" failed with exit status 1.

Login at the console prompt and uninstall the Guest Additions:

# pkgrm SUNWvboxguest

Then reinstall the package again.

First, in the Virtualbox interface, click on Devices -> Insert Guest Additions CD image...

Then using the terminal in the OpenIndiana guest, go to the directory containing the packaes in /media:

# cd /media/VBOXADDITIONS_5.1.22_115126/

Finally install the package:

# pkgadd -d VBoxSolarisAdditions.pkg

and validate all the steps.

The machine can readily be restarted, or if you want to check that the graphical interface can start, clear the login manager from maintenance:

# svcadm clear lightdm
  • No labels


  1. Just FYI:

    have installed VirtualBox 4.2.0 on top of OI 151a6 and had nothing to do (fix, like export LD_NODIRECT=1)...

    This version should also support SMF  for auto-starting.

    Best regards.


    1. I've also recently installed VBox 4.2.0rc3 on my oi_151a5 test box with no problems to note, except one nit: during OS startup the text console is disgraced by stacktraces of various vbox* drivers in the stack failing to load. This trace ultimately lead me to a system driver in misc/ dir (I can't say which it was at the moment, the test box is not available to me today). The driver was found somewhere in /usr/kernel/misc(/amd64)or in /platform/i86pc/kernel/misc(/amd64), so I copied it over into /kernel/misc(/amd64) and rebuilt the boot archive. Probably a cleaner solution would be just to add correct paths to /boot/solaris/filelist.ramdisk instead of making hardlinks or copies to a static version in /kernel/misc (these copies would likely be obsoleted by updates sometime in the future), but for a POC test this copy sufficed. The next reboot went smoothly without spewing errors.

      This is a nit and not a bug per se, because after passing the boot archive phase (which only includes modules from /kernel) the missing modules are loaded again, and with all dependencies found, the VBox modules do load automagically.

      On the other hand, it may be a bug if these modules do now go into /kernel tree indeed, because the Solaris build instructions page recommends to place the vbox* modules under /platform/i86pc/kernel/drv which makes more sense.

      > This version should also support SMF for auto-starting.

      There is merit in this, especially being a similar solution for various host OSes. Still, as an author of a competing open-sourced framework to boot and monitor VirtualBoxes as SMF service instance ( I may be biased and can point out a few differences which may be important in more advanced setups - but only for solutions built on Solaris 10 and its relatives (using SMF and ZFS):

      • With vboxsvc each VM is an SMF instance, which allows to enable-disable them independently, and to build SMF dependency graphs between VMs and/or other system services and resources for automatic startup and shutdown/savestate of VMs.
      • You can monitor the VM's functionality (i.e. test that it is "pingable" or that a webserver inside it responds), and accordingly restart the SMF service or put it into maintenance; you can also delay the exit from the start-method until the VM actually works (needed for dependencies to start at a right moment in time and not after a delay randomly selected by admins).
      • You can automate taking snapshots of ZFS-backed VM filesystem resources (including those on remote ZFS storage hosts available to VBox host via NFS or perhaps CIFS) before start/after stop to keep track of relatively stable points in time.

      There are some other differences, such as getting X11 control of a VM and then passing its execution back to headless SMF controller and various other "nifty features", all controllable with SMF attributes per-VM (or with settable defaults shared by all service instances).

      //Jim Klimov

  2. I needed to to this : touch /etc/vboxinst_vboxflt
    before install, for host-only networking to work fro VMs on Virtualbox 4.2.4 (OI151a7)

    (In case of this message:
    Failed to open/create the internal network 'HostInterfaceNetworking-vboxnet0' (VERR_SUPDRV_COMPONENT_NOT_FOUND). Failed to attach the network LUN (VERR_SUPDRV_COMPONENT_NOT_FOUND). Result Code: NS_ERROR_FAILURE (0x80004005) Component: Console Interface: IConsole {db7ab4ca-2a3f-4183-9243-c1208da92392}
    Bit of explanation:
    " Tekn0>  # If host is S10 or S11 (< snv_159) or vboxbow isn't shipped, then load vboxflt, in the OpenIndiana/illumos case, i guess it does detect that it is S11 and tries loading vboxbow which probably fails due to some missing symbol " - And said vbox needs to find away during install to see if crossbow is active.

    1. Gotta admit I'm confused by this.  I don't see a /etc/vboxinst_vboxflt either before or after installing Virtualbox 4.2.10 on my system (OI 151a7).  Is this a file that came with Virtualbox 4.2.4?

      1. The touch command creates the named file (or refreshes its last-modification date if it exists). The intention is that during the package installation, its scripts check to see if this file exists (does not by default, and is not created by the package), and based on that form of admin's wish – they pick one or another driver to install.

        1. Appreciate that explanation Jim.  That makes sense.  It didn't occur to me that the presence (or lack of) a file was being used as a switch.

  3. There are a few links worth further reading:

  4. Hi,

    i have enabled "Privileges debugging" (from man privileges) by:

    $ echo "set priv_debug = 1" >> /etc/system
    $ init 6

    to try to see if there are some problems... I have installed package vboxsvc and configured one guest to be started on boot (out of this topic, it starts CentOS 6 just to run skype). It works like charm, but it throws error (very frequent one):

    Mar 22 13:46:07 xx genunix: [ID 864859 kern.notice] NOTICE: VBoxSVC[1229]: missing privilege "file_dac_read" (euid = 1961, syscall = 5) needed at devfs_unlocked_access+0x7b
    Mar 22 13:47:06 xx genunix: [ID 864859 kern.notice] NOTICE: VBoxManage[24691]: missing privilege "proc_priocntl" (euid = 1961, syscall = 112) needed at secpolicy_setpriority+0x24
    Mar 22 13:47:07 xx genunix: [ID 864859 kern.notice] NOTICE: VBoxSVC[1229]: missing privilege "file_dac_read" (euid = 1961, syscall = 5) needed at devfs_unlocked_access+0x7b
    Mar 22 13:48:07 xx genunix: [ID 864859 kern.notice] NOTICE: VBoxManage[24850]: missing privilege "proc_priocntl" (euid = 1961, syscall = 112) needed at secpolicy_setpriority+0x24

    that euid (1961) is my account user id (group id is also 1961). I have tried with adding following:

    $ grep VirtualBox /etc/security/exec_attr
    VirtualBox Management:solaris:cmd:::/usr/bin/VBoxManage:privs=proc_priocntl;euid=1961;egid=1961
    VirtualBox Service:solaris:cmd:::/opt/VirtualBox/amd64/VBoxSVC:privs=file_dac_read;euid=1961;egid=1961
    VirtualBox SMF:solaris:cmd:::/lib/svc/method/,proc_priocntl;euid=1961;egid=1961

    But it doesn't work.

    Not sure if this has anything to do with functionality/performance/resource usage of VirtualBox or not, but i would like to get rid of it.

    Does someone has any idea?


    1. I think it would be more proper to ask this kind of detail on the VirtualBox forums (for Solaris-hosted VMs). The messages don't seem like coming from my package to wrap VirtualBoxes as SMF service instances (with some unlucky legacy naming of vboxsvc), but rather from the original product's component VBoxSVC which is responsible for, IIRC, storage of management info for the running VMs, and is launched along with the first VirtualBox, VBoxHeadless, VBoxManage, etc. process in the current OS (and dies soon after all its clients are closed). That said, I am not readily sure how to fix that error.

      One idea to explore would be to go over your RBAC setup (perhaps the euid/egid should point to root for higher priority, and linkage to 1961 user should be via /etc/user_attr?)

      Another idea is to check if your user is a member of the vboxusers(question) group. It is not usually needed unless you use USB/audio device passthrough, possibly some networking configs or maybe volumes (raw partitions) as backing storage. I think I only needed that once.

      If you used an SMF service wrapper or a local zone that, as a "software project", could be assigned some privilege sets of its own.

      Did you test whether this complains similarly if you run the VM as root (be sure to change any rights on the FS objects involved after the test, or just snapshot and rollback, so that unprivileged user can continue to use the files afterwards)?.. Does the VBox.log file notice anything?

      I wish you better luck (and more experts) on the VB forums, really (wink)
      //Jim Klimov

      1. Hi Jim,

        thanks for reply - you at least had some ideas... My account IS member of vboxusers:

        $ egrep "vbox.*predrag" /etc/group

        And i was running VBox Guest as "me" before moving to vboxsvc (before started to use it) and no errors was written to syslog (privileges debugging runs since long time ago - and not only vbox stuff logs there). This is why i am asking it here: only difference is start up of guest during boot using package.

        Well, as this is not urgent, i will try to find something searching suggested places.




        1. A few more ideas to verify, possibly:

          1) What happens if you run any virtualbox program (such as the GUI manager) as root and then start your user-owned VM? Possibly, the product's VBoxSVC would start as root and remain usable for others (not certainly – at least, under Windows it does not work for other users, but that is reportedly an MS DCOM limitation). Even if this works, it is not a solution – but might give some insight (smile)

          Alternately, if this does already happen that you run the VM and a VBoxSVC as different users – try to stop all virtualbox programs, wait for the remaining daemons to die off (usually takes a minute, or kill them off), and start it up as only an SMF service (which I believe you do use) so that this daemon starts as part of it.

          2) Did you anyhow truss or DTrace which files it is trying to access and fails? Possibly, it tries to get into a VM XML manifest or repository (part of VirtualBox data files), maybe those of a wrong user or mis-owned for some reason?

          3) Can there be any weirdness regarding the user's POSIX data, such as accessibility of homedirs, the shell... maybe even the long username over 8 chars and/or non-ASCII usernames, home paths and VM names might be among problems that I never tested (smile)

          PS: I meant to ask above if you've inspected the per-VM log files that VirtualBox creates (not syslog), for any clues? Perhaps it would complain which file it can't access...


          //Jim Klimov

  5. I've installed virtualbox 4.2.10 on OI 151a7 desktop.  Install was quite easy, it just requires following the instructions in the ReadMe.txt after the tarball is extracted (which are 4 steps, all quite simple).

    Everything worked fine at first, however after a few system reboots I could no longer use a bridged network in a VM (bridged to a crossbow adapter).  Starting a VM gave me VERR_SUPDRV_COMPONENT_NOT_FOUND errors, exacly as reported by Nikola above, however I don't have the referenced file in my system.  After a day of troubleshooting the solution is in this thread at

    What appears to be happening is the vbox network drivers drop out of the system after a few reboots.  A few fingers point at NWAM towards the end, but nothing definitive and thread has been inactive for over a year now.

    To re-instate the network drivers, exit any VMs and the Virtualbox UI.  As root:

    # rem_drv vboxflt
    # add_drv vboxflt

    To verify the drivers are now installed:

    # modinfo | grep -i vbox

    On my system there are two vboxflt drivers, NetDrv and NetMod, that are added by this process.  Reportedly, they will disappear again after a few more reboots.  If anyone has a permanent solution to this, I'd like to know!

    1. I continue to have this problem with or without "touching" the file indicated above before installing VBox.  As far as I can tell I don't think this matters with VBox's worked the same for me with or without.  I know this isn't the best place to ask, but am I the only one having this issue?  I've opened a ticked over at Virtualbox (#11684,, we'll see what they say...

  6. I notice that since ages (before even of VirtualBox that when I log into my session (JDS) I get two (2)! virtualbox startups.

    I've never enabled autostartup, and I can't seem to figure out what needs to be clean up in order to be able to login without fluff.

    Even deinstall/reinstall doesn't fix the problem.

    Has anybody else experienced this?


  7. Hello, Bit of a newb with unix and I'm having issues with the VBoxSVC script not processing the stop command when the host shuts down. I'm not even sure that it's being called. A peek in /var/svc/log/site-xvm-vbox:'Vbox'.log does not show any indication that the host tried shutting down the guest. Is this suppose to be happening? I can run the svcadm enable and disable commands and everything works as I expect. All the links provided in the readme's and threads seem to be dead now, so I'm at a bit of a loss. If it helps you any, I tried the same thing with simplesmf and had the same exact results. TIA,

    1. Hello, as an aside, there is historical mixup between VBoxSVC (a VirtualBox system component) and vboxsvc (the method script to manage VirtualBox VMs as individual SMF instances, received from

      More to the point, which version of this script are you using? It might be obsolete – not that I remember any bugs like this in any version, however. For example, the 0.16 release is tagged like this:

      :; grep Id /lib/svc/method/
      #       $Id:,v 1.62 2012/04/15 02:02:41 jim Exp $
          echo '      $Id:,v 1.62 2012/04/15 02:02:41 jim Exp $' 

      (There were some development updates not packaged into a new release, since then).

      All in all, it does not seem proper that SMF does not try to stop the service – as you say your logs imply. Does it properly stop other services? How does your typical shutdown look like?

      One problem I might think of today is that if you use X11 to interface with your VM console directly (i.e. with startgui options, and not via VirtualBox RDP/VNC console servers), and then shut down your computer (or just log off), the desktop environment and X11 server close first, which kills all its clients abruptly. This wouldn't matter for a VBoxHeadless VM, but would abort an interactive one.

      Unfortunately, this is not a problem that can be easily solved within SMF. Even if you configure a dependency, so that gdm would be "required" to run your VM service, the session management is on a layer below that – and you can still log off, killing the VM ungracefully. Short of creating a wrapper which would make each X11 session an SMF service, there's little that can be done "properly" for this case.

      Nevertheless, the unpackaged development version of vboxsvc does include some solutions for running the VMs in an interactive manner under X11 and maintained as an SMF service, though not quite at the same time. This is mostly geared towards dual-booted "interactive" VMs or those which require (and get) desktop graphics acceleration. The solution is to leave open a terminal window which, when closed, TERMinated, etc. signals the VM to savestate or otherwise shut down as you'd configure it (then the VM is transferred to SMF as usual for startgui actions – and might be resumed headless if you configure it to do so). There are also provisions to start up interactive GUI access to the VM you need with a symlink to the script, so you can use it to create a panel shortcut easily. This does not fully solve the problem (i.e. X11 server closure does still badly kill everything), but if your manual routine for logoff would now include closing that terminal and waiting for it to complete, this does help a lot.

      Hope this helps (and that I've guessed your problem right),
      //Jim Klimov

      1. I'm keeping the post below in case it helps others.

        I read up on restarting solaris and it seems that you shouldn't call 'reboot' directly.  I ran from what I gathered the correct way to reboot a server 'shutdown -y -i6' and the services stopped  computer rebooted and services restarted as normal.  Thank you Jim for your help!


        Hello, Jim

        That is quite a post to digest (wink)

        I am using  vboxsvc from  I am using the latest release 1.62 according to the script file.

        I do not know if it properly shuts down other services. I may not be looking in the correct log file.  I am looking in the directory var/svc/log/ and the file site-xvm-vbox:Whs-01.log.  I can see the start up instances, the manual stop services by typing svcadm disable Whs-01, but never anything when it's shutting down.  I can remote desktop to the guest while shutting down and the screen never goes black as it would normally do when it was 'saving state'.

        I do not see anything in the var/adm/messages

        I am running my server headless via /lib/svc/method/ start in my xml file.

        I am rebooting from command line using the 'reboot' command.

        I am doing this so on power failure, it will shut down my guest and then my host.  Now it's become a challenge that I want to figure out.



        1. Regarding the sutdown routine, in Solaris it was for a long time customary that "the right thing" is to change into a particular run-level (0 = stop kernel and wait, 5 = stop kernel and try to shut off the power source, 6 = reboot), processing of which ultimately calls the proper command or alias of poweroff/reboot/shutdown/halt... Some say this changed with SMF and now calls to things like reboot should do the right thing causing SMF to call stop methods, but it seems your experience proved otherwise. In fact, sometimes explicit calls to reboot and friends (with certain parameters at least) are needed in order to shut down quickly and ungracefully, in order to work around hung processes, i.e. in case of IO errors to external storage that died first during brown-out shutdown.

          BTW, what do you use to process power-failure properly (there are a number of solutions)?

          1. I believe that this maybe why I cant just use reboot:

            reboot: Failed to stop svc:/application/graphical-login/gdm:default.
            reboot: Falling back to regular reboot.

            I'm using xvnc so I wonder if that is the problem.


            I am using apcupsd because NUT would constantly drop the connection and then reconnect.  It doesn't seem as if either of these are being maintained any longer.