=^.^=

A Word on Oracle VM VirtualBox Start Modes (defaultfrontend)

• karma

Generally speaking, I recommend setting the default front-end for all virtual machines to headless for the following reasons:

  • Running virtual machines headless, as one typically would in a production environment, de-necessitates dependence on X11 and accompanying desktop environment baggage. On Oracle Solaris 11.4, the solaris-desktop set contains over 360 packages. However, given the practical benefits the VirtualBox Manageer GUI provides (don't be ashamed to use a GUI, especially in a crisis - time is of the essence!) I tend to indulge in the superfluity.
  • Although it is possible to specify which front-end to use under the Start submenu in the GUI, the default front-end when you simply hit the Start toolbar button or context menu item is gui
  • If you have started a VM with the gui front-end you will not have the option to close its window without shutting it completely down. This can be a costly oversight if you now have long-term processes running or other users accessing a VM
  • You don't have to worry about what happens to your VMs if your session is logged out or otherwise lost or, heaven forbid, your X or DE crashes
  • You can always attach a GUI window to the VM's framebuffer any time after the fact (use the Show toolbar button or context menu item in the Manager gui), with the benefit of the additional Continue running in the background option when you close the window that is otherwise missing

The documentation for VBoxManage startvm mentions the following pertaining to the detatched frontend:

Starts a VM with a detachable UI. Technically, it is a headless VM with user interface in a separate process. This is an experimental feature as it lacks certain functionality, such as 3D acceleration.

Moreover, according to VirtualBox forum moderator scottgus1 in 2020:

...Starting 'headless' or 'detachable' causes any 3D acceleration that might be interfering due to bunged Guest Additions to not start, leaving only software-graphics in the guest...

Please take this under advisement if your particular use case depends on advanced graphics capabilities.

To change the frontend, as the VM's owner's user run:
$ VBoxManage modifyvm vmname --defaultfrontend headless

It should be noted that you can't make this change via the GUI and it is also not possible at this time to do it while a VM is running, you will encounter an error similar to:
VBoxManage: error: The machine 'vmname' is already locked for a session (or being unlocked) VBoxManage: error: Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), component MachineWrap, interface IMachine, callee nsISupports VBoxManage: error: Context: "LockMachine(a->session, LockType_Write)" at line 554 of file VBoxManageModifyVM.cpp
Therefore it is important to try to make this modification before you first spin up a virtual machine in production.

Automatically Starting Oracle VirtualBox VMs on Windows the Quick and Dirty Way (Do Not Use)

• karma

Before I start I should put forward that since Oracle VM VirtualBox brought autostart-as-a-service support to Windows the correct way to do this is covered in the official documentation: 9.21.4. Windows: Starting the Autostart Service.

Even before that, more sophisticated and ideologically correct ways to do this were devised in the wider community out of necessity:

But as I retire (thank god) an old Windows VirtualBox server I had to rush many moons ago I am inclined to record this hot tip straight out of the Windows 95 era for posterity. See, back in my day savvy Power Users started their applications by dropping shortcuts in the Start Menu > Startup folder - and while it's not obvious on modern versions of Windows this directory (in fact several of them, scattered in the various locations that are merged into the actively displayed Start Menu) is still alive and kickin'. This method depends on your VirtualBox VM administrator account automatically logging in - i.e.: passwordless. Because if you're going to half-ass a server go all the goddamned way.

  1. In the VirtualBox Manager GUI right-click on the desired virtual machine(s) and select Create Shortcut on Desktop
  2. Open the Run prompt by pressing Meta (Windows) Key + R and entering shell:startup or open an instance of File Explorer and in the address bar type %appdata%\Microsoft\Windows\Start Menu to zip to C:\Users\user\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
  3. Cut the VM shortcuts from your desktop and paste them into your Statup folder
  4. Crack a beer and land those puppies up on the desk: you are MCSE Material(tm).

Start Android-x86 With a GUI

• karma

By default, Android-x86 boots to the command line instead of a typical Android GUI. This is great if you're installing Android-x86 to do wicked ninja hackery. I don't. I install Android-x86 to run Android apps. Colour me lamesauce.

Fortunately we can cajole such behaviour out of it by providing a UVESA_MODE argument to the kernel command line. Follow these steps:

  1. At bootup intercept the GRUB menu by hitting the down key when it appears. Boot in Debug Mode.
  2. At the command line, run:
    mount -o remount,rw /mnt cd /mnt/grub nano menu.lst
  3. At the end of the first line that starts with kernel add nomodeset UVESA_MODE=1024x728 as shown (you will probably need to scroll right):
    default=0 timeout=6 splashimage=/grub/android-x86.xpm.gz root (hd0,0) title LineageOS 14.1-r5 kernel /cm-x86-14.1-r5/kernel quiet root=/dev/ram0 androidboot.selinux=permissive buildvariant=userdebug SRC=/cm-x86-14.1-r5 nomodeset UVESA_MODE=1024x768 initrd /cm-x86-14.1-r5/initrd.img title LineageOS 14.1-r5 (Debug mode) kernel /cm-x86-14.1-r5/kernel root=/dev/ram0 androidboot.selinux=permissive buildvariant=userdebug DEBUG=2 SRC=/cm-x86-14.1-r5 initrd /cm-x86-14.1-r5/initrd.img title LineageOS 14.1-r5 (Debug nomodeset) kernel /cm-x86-14.1-r5/kernel nomodeset root=/dev/ram0 androidboot.selinux=permissive buildvariant=userdebug DEBUG=2 SRC=/cm-x86-14.1-r5 initrd /cm-x86-14.1-r5/initrd.img title LineageOS 14.1-r5 (Debug video=LVDS-1:d) kernel /cm-x86-14.1-r5/kernel video=LVDS-1:d root=/dev/ram0 androidboot.selinux=permissive buildvariant=userdebug DEBUG=2 SRC=/cm-x86-14.1-r5 initrd /cm-x86-14.1-r5/initrd.img
  4. Save changes and reboot:
    reboot -f

  5. Boot with the first (default) GRUB menu entry. You should see a GUI style animated boot splash. The first time you boot with a GUI will take a very long time.
  6. A more flexible way to implement this would be to create a second menu entry in GRUB:
    1. Copy and paste the first entry's configuration block (Control+U several times, Control+K to paste, if using nano)
    2. Add the additional kernel command line parameters to the first or second block, depending on whether you want to boot to the GUI or CLI by default
    3. Edit the title of whichever entry you have modified to reflect that it will boot into a GUI

Make GNOME Shell Less Awful

• karma

I have always been a KDE/Plasma fanboy on systems where it is appropriate, I spent several years with enlightenment and I'm also perfectly happy to adopt systems like xfce which I am now immersed in since switching from Gentoo to Qubes as my daily driver. But for some reason GNOME has always rubbed me the wrong way. Late to the party as usual, I have finally been exposed to the GNOME 3.x incarnation: GNOME Shell as it is the default desktop environment bundled with the solaris-desktop package on Oracle Solaris 11.4. Worse, it is the only modern DE available out-of-the-box for modern Solaris (RIP KDE on Solaris).

It feels almost like GNOME Shell goes out of its way to get in mine. A good desktop environment is one that anyone can sit down at and start using intuitively without being interrupted by overwhelming feelings of frustration (tiled window manager nerds and the like are welcome to step in at this moment and chirp nonsense arguments in favour of efficiency at the expense of usability). I'm probably just a brain moron but there is precious little that is intuitive to me about GNOME Shell. How do I minimize a window? Once I've figured out where that is hidden, where do they go? Is it back under this weird touch interface style Activities thingy? Touch interfaces are by necessity intuitive, I have almost no idea what is really going on here. I see workspaces are peeking out on the right. Cool. I almost never use those either.

Why are there so many extra clicks or key presses to get from one open application to another? Alt+tab works as expected but it's inconvenient when I have to hit it five times just to get around. If this is a window manager how am I supposed to manage my goddamned windows?

To bring back an environment that resembles something more like what I, at least, am used to:

  1. Open a terminal. As the presently logged-in user, run gnome-tweak-tool. Fortunately this is installed by default on Oracle Solaris 11.4. Your mileage will, as my experience with Fedora and Debian on Qubes has taught me, likely vary. Install it the appropriate way for your platform if it is not available.
  2. Click on the Windows tab, under Titlebar Buttons:
    • Enable the Maximize toggle.
    • Enable the Minimize toggle.
  3. Click on the Extensions tab, enable:
    • Applications Menu to replace the Activities interface, which can still be accessed via a menu item at the bottom of the list.
    • Window List which will waste some space by creating another global bar across the bottom of the screen but with the justified purpose of providing a conventional open-windows menu.

Automatically Start Oracle VM VirtualBox and Virtual Machines on Solaris 11

• karma

As with starting the VirtualBox Web Service on Oracle Solaris, the documentation regarding starting VirtualBox and auto-starting virtual machines is rather convoluted. In particular it is not immediately clear if the autostart database directory provisions necessary under Linux are required under Solaris (they are not) or how to specify which VMs to automatically start, regardless of platform. Here I will once again attempt to straighten the instructions out, for my purposes - your mileage may vary.

First we must create a configuration file which defines those users (local system user accounts) may autostart virtual machines and after what delay they may be started (to prevent the over-congestion of resources at bootup).

First we need somewhere to store configuration files:
# mkdir /etc/vbox

Even if only one user account is used to run virtual machines on the host it is good to retain the default deny policy outlined in the official documentation's example configuration as restrictive assumptions are often safe assumptions - not that the compromise of any other account and subsequent automatic running of virtual machines is a particularly impactful security concern.

Drop the following in /etc/vbox/autostart.cfg:
# Default policy is to deny starting a VM, the other option is "allow". default_policy = deny # user is allowed to start virtual machines but starting them # will be delayed for 10 seconds user = { allow = true startup_delay = 10 }

Now we need to tell svccfg where to find the configuration file:
# svccfg -s svc:/application/virtualbox/autostart:default setprop config/config=/etc/vbox/autostart.cfg

A ways before covering how to set up autostart the documentation for VBoxManage modifyvm shows us how to specify those VMs which should be automatically started and after how long a delay (for a staggered configuration that avoids over-taxing your host's resources at startup):

8.8.9. Autostarting VMs During Host System Boot

These settings configure the VM autostart feature, which automatically starts the VM at host system boot-up. Note that there are prerequisites that need to be addressed before using this feature. See Section 9.21, “Starting Virtual Machines During System Boot”.

  • --autostart-enabled on|off: Enables and disables VM autostart at host system boot-up, using the specified user name.
  • --autostart-delay : Specifies a delay, in seconds, following host system boot-up, before the VM autostarts.

As the user that owns the virtual machines run:
$ VBoxManage modifyvm vmname --autostart-enabled on $ VBoxManage modifyvm vmname --autostart-delay seconds

This is also a good time to change your VMs' default frontend to headless, for reasons why please see A Word on Oracle VM VirtualBox Start Modes (defaultfrontend):
$ VBoxManage modifyvm vmname --defaultfrontend headless

You may wish to consider Preallocating VirtualBox VM RAM for Greater Stability and Avoiding Overcommitment:
$ VBoxManage setextradata vmname VBoxInternal/RamPreAlloc 1

When the configuration has been completed and you are ready to enable autostart, as root run:
# svcadm enable svc:/application/virtualbox/autostart:default