Using VirtualBox For Linux DIY
Copyright © 2015 by Steve Litt
See the Troubleshooters.Com Bookstore.
Virtual machines (VMs) are a must if you do a lot of Do It Yourself (DIY) and feel the need for speed. Installs go a lot faster on VMs, plus you can install straight off an .iso file instead, which saves a lot of time and fooling around. And, of course, there's the simple fact that switching computers or hard disks is time consuming, and monetarily costly.
I'm not saying VM experimentation is completely authoritative. Things that work in a VM might fail on hardware, and vice versa. Also, networking on a VM can be very complicated, depending on the extent you want to emulate what you'd do with an individual computer. This document discusses only VirtualBox's default networking, which is very simple.
Distros that fail with VirtualBox might succeed with Qemu, and vice versa. Try both.
Differences between Virtualbox and Qemu include the following:
This is not a document about VirtualBox. VirtualBox is a powerful, flexible, and quite complicated system. In the hands of the most knowledgeable, VirtualBox can perform miracles. This document doesn't tell you how to optimally use VirtualBox.
Instead, this document tries to give you one reliable alternative for each activity necessary for Linux distribution DIY. If you want to do things like testing networking, USB or sound, you'll need to either get much more proficiency than this document provides, or, after you see that it's basically working as a host, run the distro on bare metal.
Some VirtualBox tasks require either the extra stuff covered under the VirtualBox Personal and Evaluation License, or the VirtualBox software under the Commercial License. This document discusses only software available in the GPLv2 core.
The biggest DIY benefit of virtual machines is speed. Linux installation is faster on a VM guest than on bare metal, if and only if, the host hardware has hardware VM assist. If not, it's five times slower than bare metal, erasing every possible benefit.
The way you find out whether your host hardware supports hardware VM assist is with one of these commands, depending on whether you have an Intel or an AMD processor:
echo THIS IS FOR INTEL CPUS grep ^flags < /proc/cpuinfo | grep vmx
echo THIS IS FOR AMD CPUS grep ^flags < /proc/cpuinfo | grep svm
If the proper command for your CPU outputs a bunch of text, you have hardware VM assist. If it outputs nothing, your CPU doesn't have hardware VM assist, and this web page will do you no good unless you find other hardware to work with.
As a DIY person, I'd anticipate you'll need knowledge of both Qemu and VirtualBox. There are some Linux setups that would work on one or not the other. Plus the fact that depending on your host OS and distro, you might have access to only one or the other.
I personally go to VirtualBox first, because I've been able to get Linux distros to run on VirtualBox with considerably less experimentation than with Qemu. When I'm DIYing, I like to save my experimentation for the Linux distro, not configuration of the Virtual Machine.
Be careful of VirtualBox and its licensing. The core is GPLv2, but the VirtualBox Guest Additions are a rather benign kind of free beer license that specifies you're using the VirtualBox Guest Additions only for personal use or for business evaluation. I read that to mean I can't base my business's core activities on any processes using VirtualBox Guest Additions. So I'd need to buy a commercial license to run my business on VirtualBox Guest Additions. According to this 2012 notice, the commercial license is reasonable but not negligible, and you need to spend some coin to be eligible for Oracle support.
My finding is that in more cases than not, you need to jump through substantial hoops to make Qemu run a distro with reasonable GUI. Many times Qemu guested distros just hang, unless you jump through those hoops. On the other side of the coin, Qemu has a scripting-friendly CLI interface, and everything about it is Free Software.
Learn both. If you fail with one, you can quickly try the other. Plus, the more you learn about each, the more you learn about Virtual Machines, which helps you on the other. I've written a Qemu document similar to this one.
Occasionally you'll have a VM guest OS that can't start X. Do not immediately assume that's caused by some sort of VM/driver mismatch. Another possibility, and one you should check for, is that it's caused by an overdependencied window manager of desktop environment. In 2015, with everyone but we DIY types accepting dependencies as if they had no cost, you'd be surprised at the variety of window managers and desktop environments with X killing dependencies. Xfce on Manjaro OpenRC 8.12 on VirtualBox is an example.
So at least try a less dependencied window manager. I used Openbox, and it worked where Xfce didn't. But in these days of celebration of dependencies, OpenBox might become contaminated. If that happens, drop all the way back to things like jwm or Suckless Tools' dwm.
Similarly, if your distro boots to a no-prompt black screen, don't assume it's something exotic. It might be the same startx problem. You can bust back into your borked VM, use the init system to disable the display manager, and see whether a Virtual Terminal comes up. Then, from there, you can diagnose any problems with X.
The host key is the key that releases the guest OS' grip on your mouse and keyboard. It defaults to the right Ctrl key. This key can also substitute for Ctrl+Alt in switching virtual terminals, so that RightCtrl+F3 takes you to Virtual Terminal 3, just like Ctrl+Alt+F3 would do on bare metal. It can do lots of other things.
To change the Hostkey (which I wouldn't recommend doing without a darn good reason), from the Oracle VirtualBox VM Manager window's menu, perform the following menu operation:
Then, click the content area of the "Host Key", and press a key on your keyboard to change the Hostkey. Note that the key should probably be a modifier key.
Sometimes, even if you put the guest in Fullscreen, you end up viewing everything in a tiny portion of that fullscreen, and if you have bad vision, it can be hard to read. No problem, put it in Scale Mode with the following scale toggle key combo:
Once it's in scale mode, use your typical Host OS methods to resize the containing window.
My Openbox host window manager uses Alt+MouseRight to resize windows, but that doesn't work on VirtualBox windows. I had to use other methods.
If your host window manager doesn't provide corner dragging to resize windows, you need to right click the titlebar, select "resize", and drag. Do not access the "resize" operation from the window's top left button: That will prevent you from dragging where you want.
Getting to Virtual Terminals (like what you get when you press Ctrl+Alt+F3 on bare metal) is dead-bang easy in VirtualBox. Your first step is to know your Host Key, which is the key that disables the VM guest's grabbing of the mouse and keyboard. By default, the Host Key is the Ctrl on the right side of the keyboard (called Right Ctrl). If you want to change it or see what it is, use the following from the Oracle VirtualBox VM Window's menu:
Now that you know which physical key is mapped to the Host Key, to move to Virtual Terminal 3, just press the Host Key, press and release F3, and release the Host Key. This accomplishes the same thing as Ctrl+Alt+F3 would have accomplished on bare metal.
Being able to reliably get to Virtual Terminals strictly with the keyboard is one of the big advantages of VirtualBox.
Unlike Qemu's Command Line Interface, which can be scripted, VirtualBox's interface is point and click, so creating a new VirtualBox Guest VM requires lots of user intervention and the process therefore appears long. But it's pretty easy.
For this example, I'll use the following setup:
Instructions for creating this VM follow:
Now you need to make a backup of your system. VirtualBox has an entire system devoted to giving you version backups, and you should learn them, but for the purposes of this document you'll be using a simple file copy to back up your VM:
Core VirtualBox has no facilities for copy and paste, and you certainly need to be able to communicate between host and guest. Imagine transposing long commands. Ugh!
I hear you can get integrated copy and paste with VirtualBox Guest Additions. However, because VirtualBox Guest Additions is not Free Software, I'm going to discuss a different method that's entirely FOSS.
Most other VirtualBox copy and paste substitutes involve shared directories: NFS, SSH, SMB/CIFS, FTP and the like. All are challenging. The least challenging I've found is a directory shared with sshfs, so that's the concentration of this section.
The challenging part of sharing a directory between guest and host is that, in a default network situation, the guest knows the host IP address, which in VirtualBox defaults to 10.0.2.2, same as in Qemu. But the host doesn't know the guest's IP address, so the host can't instantiate contact. This is very much like any Network Address Translation situation: Every machine on your local network (192.168.100.0/24, for instance) knows its Internet facing IP address, but nothing from the Internet knows or can contact 192.168.100.3.
Therefore, the guest must reach out to the host for the necessary shared directory. There are many ways of doing this, but the easiest and most straightforward I've seen is using sshfs. Here's how you do it...
You want your Lubuntu 15.04 VM to boot to CLI instead of GUI, so you rename /usr/sbin/lightdm to /usr/sbin/lightdm.org, and reboot. Bad move!
Now, when you boot this VM, it just sits there, doing nothing, forever. Oh oh!
If only you could boot it, you could rename /usr/sbin/lightdm.org back to /usr/sbin/lightdm to enable booting the VM. And if only you could boot the VM, you could do the rename. A buried shovel!
There are probably a million different ways to bust back into a VirtualBox VM, but I do it the same way I do it on bare metal and on Qemu: Using System Rescue CD. Here are the high level steps for doing so:
And there is. It's the same way you bust back into an OS on bare metal or on Qemu: You use System Rescue CD.
Unlike the Qemu Command Line Interface, VirtualBox has a GUI interface. This makes things more intuitive in VirtualBox, but is resistant to scripting. The DIY Linux person probably wants to learn both. From my observation, VirtualBox more often works right out of the box, so I use it first.
You can use VirtualBox to make a VM out of pretty much any installation CD (.iso). If you bork your VM, you can bust back into it with System Rescue CD and VirtualBox, just by booting the VM from System Rescue CD, and using the System Rescue CD environment to mount and access the VM simulated hard drive's filesystem.
VirtualBox's copy and paste is available only in their free beer "VirtualBox Guest Additions". The easiest way I know, that doesn't use this free beer, is to establish a shared directory using an SSH server on the host and sshfs on the guest, and then copy and paste to the shared directory.