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: https://forums.virtualbox.org/viewforum.php?f=11 (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
Finally, in the command-line examples below the "
:;" characters starting the lines are the
root's or user's (with
sudo) shell prompt.
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, VirtualBox.org 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.
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.
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:
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 (you can use
ldd to check VirtualBox's binaries and libraries for dynamic dependencies). Install the packages found above:
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.:
Hopefully, since these are IPS packages now under the hood, asking for their installation should pull up all their needed dependency packages too.
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.
.vdifiles. But this has some limitations:
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
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.
.vdifiles seems to be noticeably slower than guest performance in zvol's.
root, and it needs to be owned by the user who runs the VirtualBox process. So you need to script the
sudo chownof the zvol's. Again, see below.
You can enable VNC. For example:
I personally create the above commands as aliases in my
~/.bashrc profile file:
svcadm restart sshfor this.
Download the latest "*SunOS*" Solaris VirtualBox binaries (GPL-licensed) from https://www.virtualbox.org/wiki/Downloads and/or browse here: http://download.virtualbox.org/virtualbox/ (you can use
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):
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
vboxconfig.sh 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: https://github.com/jimklimov/vboxconfig_sh and specifically downloadable https://raw.githubusercontent.com/jimklimov/vboxconfig_sh/master/vboxconfig.sh.patch (text patch file) or https://raw.githubusercontent.com/jimklimov/vboxconfig_sh/master/vboxconfig.sh (resulting script – fixed against a recent upstream version). To use this patch, you can unpack the downloaded virtualbox SVR4 package (see
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.
If you are installing the Oracle VM Extension Pack, you may either launch the VirtualBox GUI client (
/opt/) and go to the File / Preferences / Extensions menu, or do it from the command line:
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.
Complete process to create new VM with full ZFS support for its files:
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 (
Note: disabling ZIL will definitely improve performance, but is generally unsafe, unless you understand the types of workloads that can be done safely.
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:
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:
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.
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:
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/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:
/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:
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.)
Query the bridged VM for its (automatically generated) vHW NIC settings:
e1000g0is 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:
vnic93008might stand for
Bridge the vHW NIC over the dedicated VNIC (this may require that the guest VM is shut down):
Verify the bridged VM for its vHW NIC settings:
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).
If you recieve and error similar to this:
Oracle VM VirtualBox(i386) 5.1.22,REV=2017.04.28.17.36.115126
## 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.
NOTE: another option would be (example for version 5.1.30)
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.
Login at the console prompt and uninstall the Guest Additions:
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:
Finally install the package:
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: