Troubleshooters.Com®, Linux Library, and DIY Linux Present:

Using VirtualBox For Linux DIY



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 Document is Limited

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.

Use Only Hardware With Hardware VM Assist

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:

grep ^flags < /proc/cpuinfo | grep vmx

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.

Qemu, or VirtualBox?

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.

That Little startx Problem

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.

Overcoming Some Other VirtualBox Frustrations

Host Key

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:

File->Input->Host key

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.

Teeny Tiny Print in a Teeny Tiny Window

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 in VirtualBox

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:

File->Preferences->Input->Host Key

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.

Creating a New VirtualBox Guest VM

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:

  1. virtualbox at the command line to invoke the Oracle VM VirtualBox Manager.
  2. Click the "New" button to invoke the "New Virtual Machine Wizard".
  3. Click the "Next" button on the Wizard window.
  4. Enter "lubu" for the VM name.
  5. Select "Linux" for the operating system.
  6. Select "Other Linux" for the version.
  7. Click the "Next" button.
  8. Enter 3000MB for the base memory size, then click the "Next" button.
  9. Check the "Start-Up Disk" checkbox and the "Create new hard disk" radio button, and then click the "Next" button. A few details you might want to know
    • The Start Up disk is the simulated hard disk for this VM, not the installation media.
    • You haven't yet identified the installation media (in ISO format). Don't worry, this will be done after the fact.
    • In the context of a new VM, there's no "existing" hard disk, so "create new hard disk" is the only choice that makes any sense.
  10. In the "File Type" radio buttons, choose "VDI (VirtualBox Disk Image), then click the "Next" button.
  11. On the "Storage details" radio buttons, choose "fixed size". Dynamic allocation does you little good because VirtualBox can't recover freed space and shrink accordingly.
  12. Set the location to /scratch/virtualbox_images/lubu.vdi
  13. Leave the "Size" field at its default, 8GB.
  14. Click the "Next" button and you will be presented with a summary. Notice, but don't be alarmed at, the fact that the installation media still hasn't been specified. That's OK.
  15. On the summary, click the "Create" button. The computer will format the image and then return you to the summary, complete with the "Create" button. Click the "Create" button again. Yes, I know this is bizarre, but do it. The Wizard closes, leaving you back at the Oracle VM VirtualBox Manager.
  16. You're back at the Oracle VM VirtualBox Manager. Notice that the new "lubu" VM is highlighted. If it is not, then highlight it.
  17. Click the "Settings" button.
  18. Select "System" from the vertical list on the left.
  19. Uncheck "Floppy" and move it to the bottom. Make sure that "CD/DVD-ROM" is at the top of the list, and "Hard Disk" is next. Use the little arrows on the right of the vertical list.
  20. Click OK.
  21. Click the Settings button again.
  22. From the vertical list, click "Storage"
  23. In the "Storage Tree", click the entry with a CDROM icon. It will probably say "Empty".
  24. To the right, check the "Live CD/DVD" check box.
  25. Click the little CD icon to the right of the CD/DVD Drive dropdown, then click "Choose a Virtual CD/DVD disk file". You're now presented with a file navigator.
  26. Navigate to the location of the ISO, which in this example is /scratch/linuxinst/lubuntu/lubuntu-15.04-desktop-amd64.iso.
  27. Back on the "lubu Settings" window, make sure the CD entry on the Storage Tree now points to /scratch/linuxinst/lubuntu/lubuntu-15.04-desktop-amd64.iso. You might need to maximize this window and drag the line to widen the Storage Tree area.
  28. Click the OK button. You're now back at the Oracle VM VirtualBox Manager window.
  29. Make sure the "lubu" virtual machine is still highlighted.
  30. Click the "Start" button. Click "OK through warnings about color mode bits: You can deal with that later, or not.
  31. Install Lubuntu the same as you would on bare metal, starting by clicking the "Install Lubuntu 15.04" icon.
    • VITALLY IMPORTANT: When asked to reboot, don't. Instead, go to the next instruction on this list.
    • NOTE: Starting now, the VM captures your mouse and keyboard, so if you need to go elsewhere, press the Hostkey, which defaults to the right Ctrl key.
  32. When asked to reboot the computer, go ahead, but PAY CLOSE ATTENTION!
    • If it reboots into the install CD, then from the lubu VM window, menu Machine->Close, and then choose "Poweroff".
    • If it seems to just hang, then from the lubu VM window, menu Machine->Close, and then choose "Poweroff". Once the "lubu" VM is shut down, continue...
  33. On the Oracle VM VirtualBox Manager, make sure the "lubu" VM is highlighted.
  34. Click the "Settings" button.
  35. Click "System" in the vertical list on the Settings window.
  36. In the Boot Order, move the "Hard Disk" item to the very top.
  37. Click OK.
  38. On the Oracle VM VirtualBox Manager, click the "Start" button. This should boot you right into your newly installed Lubuntu VM.
  39. DO NOT upgrade the distro's programs at this time!!! Wait til you have a backup of your VM.
  40. If you need to troubleshoot and can't get the VM to run, see the Busting Back In to a Borked VM section of this document.

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:

  1. Power off your lubu VM.
  2. Copy /scratch/virtualbox_images/lubu.vdi to a safe backup location.
  3. If you anticipate using VirtualBox much, make a note to do backups the VirtualBox way. However, once in a while making a file copy might be a good idea, in case VirtualBox's backup methods develop a bug.
  4. Rerun your lubu VM.
  5. NOW you can upgrade your programs, safe in the knowledge that if worst comes to worst and the upgrade borks your VM, you can copy the pre-upgrade one on top of it.

VirtualBox Copy and Paste Substitutes

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 Challenge

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, 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 (, for instance) knows its Internet facing IP address, but nothing from the Internet knows or can contact

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...

  1. Install ssh server on the host, and make sure it's running.
  2. Install sshfs on the guest.
  3. On both host and guest, create directory /tmp/xfer.
  4. On guest, su to the root user.
  5. On guest, sshfs $USER@$HOSTIP:/tmp/xfer /tmp/xfer
    • $USER is the username you want to access /tmp/xfer on the host, usually a normal user.
    • $HOSTIP is the host's IP address as known to the guest! This defaults to on VirtualBox setups with default networking, regardless of the host's actual IP address. Different VirtualBox networking setups can lead to different values of $HOSTIP.
  6. Verify that data written to the guest's /tmp/xfer is readable on the host's /tmp/xfer, and vice versa.
  7. Now, instead of copying and pasting, you can pipe or screenshot to a file in /tmp/xfer, and have that data available on the other side.
  8. This is very insecure, so don't put secret data in /tmp/xfer, and clean it out often.
  9. Before shutting down the guest, run the following command:
    • fusermount -u /tmp/xfer

Busting Back In to a Borked VM

You want your Lubuntu 15.04 VM to boot to CLI instead of GUI, so you rename /usr/sbin/lightdm to /usr/sbin/, 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/ 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:

  1. Kill the stuck VM however you can. Start with the least destructive, such as the VirtualBox app's Machine->Close->Poweroff.
  2. On the Oracle VM VirtualBox Manager window, highlight the VM to be busted back into. I called mine Lubuntu1504.
  3. On the Oracle VM VirtualBox Manager window, click the Settings button. The Settings window should pop up.
  4. On the list down the left of the Settings window, highlight the system choice.
  5. Rearrange Boot order so that CD/DVD-ROM is at the top.
  6. On the list at the left of the window, click Storage and highlight the storage tree entry for the CD. Note the CD icon to the left of the CD entry on the list, as opposed to the other entry, which shows a hard disk icon.
  7. Click the CD icon that appears to the right of the "CD/DVD Drive" dropdown. N
  8. A dropdown menu appears. Click "Choose a Virtual CD/DVD Disk file".
  9. Navigate and select your System Rescue CD ISO file.
  10. Make sure the "Live CD/DVD checkbox", located below the "CD/DVD Drive" dropdown, is checked.
  11. Click OK.
  12. Click the Start button on the Oracle VM Virtualbox Manager
  13. lsblk -f at the System Rescue CD prompt, in order to figure out the root partition of your VM hard drive's root partition. Note that this root partition will not be mounted, and probably will be on the /dev/sda drive. It will not be on the /dev/sr0 device.
  14. Figure out which partition is your VM's root partition. For the rest of these instructions, call it /dev/$rootpart.
  15. mkdir /mnt/root
  16. mount /dev/$rootpart /mnt/root
  17. ls -ldF /mnt/root/* to verify that you've mounted the right partition. It should have /usr, /home, /etc, /boot, /var, and the like.
  18. chroot /mnt/root bash to make the filesystem look like it looks when you boot directly into the VM.
  19. Make your repairs.
  20. Ctrl+D at the command prompt to undo the chroot.
  21. cd /
  22. umount /mnt/root in order to write the changes you made to the partition.
  23. poweroff
  24. At this point the VM shuts down. Now you need to prevent it from booting to the CD the next time.
  25. On the Oracle VM VirtualBox Manager window, click the Settings button.
  26. On the Settings window, highlight "System" from the list on the left.
  27. Change the boot order on the Settings window so that the hard disk boots first.
  28. Click OK on the Settings window.
  29. On the Oracle VM VirtualBox Manager window, click the Start button. If your repairs were adequate, your VM should boot correctly. Otherwise, set the CD to boot first and try more repairs.

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.

[ Training | Troubleshooters.Com | Email Steve Litt ]