VirtualBox Basics

VirtualBox is one of several programs that allow you to run a virtual computer as software on your actual computer: this becomes hugely useful when you run an alternate operating system in the virtual computer.

[Still fighting Pelican - the blog software - on the formatting of this article, apologies for the appearance.]


  • the technical term for this kind of software seems to be "hypervisor," but VirtualBox is to hypervisors what Kleenex is to tissues: a lot of people just call the emulated operating systems "virtual boxes"

  • VirtualBox is free, and currently owned and maintained by Oracle (it's changed hands a couple times)

  • its best-known competitor is the proprietary VMware

  • other software in the category: QEMU (which can emulate other chipsets ... but that's much slower), Bochs, Xen (which is lower level) ...

  • turns out there's a lot of these:

  • your main OS is considered the "host," the OS in the virtual computer is the "guest"

  • VirtualBox is available for Windows, OS X, Linux, and even Solaris

  • a limitation: VirtualBox only does x86 on x86: you can't run an ARM version of Android on your i5 machine

    • if you have a 64-bit computer you can choose between x86-64 and x86-32, but that's the extent of your processor choices
  • there are other OS emulators to deal with stuff like that (Bochs, or Google's Android Development Tools if you're after the specific Android instance - there are lots more emulators)

  • emulating an entire computer uses up a fair bit of system resources: the most obvious hits you'll take will be RAM (however much you allot to the virtual machine) and hard disk space (however much is currently in use for the virtual machine)

  • the RAM is usually the big issue: if you run two guest OSes that each use 1GB of RAM on a system that has 3GB of RAM, you now only have 1GB of RAM left for your host OS


  • download and install VirtualBox: your first step is to create a new virtual machine (if in doubt, use the defaults)
  • through the settings, you make decisions about how much memory, how big (and how many) hard drive(s), how many network cards, etc.
  • then you "insert" a bootable CD/DVD by selecting a disc image (usually a .ISO)
  • boot the system, walk through an installation as you would on real hardware
  • "remove" the bootable ISO from the system, just as you would with real hardware (or the system will boot from that media again)
  • start the system, and it boots into your new guest OS
  • some companies actually provide pre-packaged virtual hard disks that you can just import and start (ex. download a NixOS VirtualBox appliance: )

Guest Additions

  • the "Guest Additions" package allows the guest OS to be somewhat aware of the host OS
  • to better integrate graphics
  • to allow guests partial access to the host hard drive
  • the "Guest Additions" are distributed as a CD image with the version of VirtualBox, and it's (sometimes) specific to your current version of VirtualBox (if you upgrade VirtualBox you may have to re-install Guest Additions in guest OSes)
  • graphics integration allows you two interesting modes: "Fullscreen" has the guest OS taking over the current screen (usually only one if you have a multi-screen host - I haven't messed with this)
  • "Seamless" graphics integration shows windows from the guest OS alongside host OS windows on your host desktop
  • "Seamless" is pretty cool: having an XTerm sitting beside your Microsoft Word window is really good, but if you minimize the XTerm (assuming Windows is the host and Linux the guest), you have to get to the Linux taskbar to restore the XTerm, it doesn't minimize to the Windows bar - but keep that in mind and you're good
  • access from the guest to parts of the host hard drive is done through mappings: it's first declared in the VirtualBox settings, and then (in a Linux guest, the only way I've used it) the shared host OS folders are mounted with a particular fstype
    • I've had a lot of trouble with this: it's great when it works, but it tends to just not be there on boot at times

Internal Network

  • you can run two (or more) virtual machines simultaneously, at which point (depending on what you're working on) it may become useful to have the virtual machines be able to have their own internal network

  • under "Settings" for each machine you want as part of this internal network, go to "Network" and select the "Adapter 2" tab (I'm assuming you have only one network card already in use - but you wouldn't need to be reading this if you already had more NICs):

    • click "Enable Network Adapter"
    • under "Attached to:" set the drop-down menu to "Internal Network"
    • the "Name:" will default to "intnet," which is probably fine but you can change it if you want
    • I usually go to "Advanced" and change the "Adapter Type:" to "Intel PRO/1000 MT Desktop (82540EM)" - "Paravirtualized Network (virtio-net)" is theoretically better and faster for the internal network, but see the note below
  • you can set up a DHCP server for your internal network through VirtualBox's own software, but I've usually just configured the interfaces in Linux guests with ifconfig and route (old-fashioned and hardcore, not really recommended)

  • with Debian guests on a Windows host, it would randomly swap the two NICs on boot (two different virtual machines), meaning that if I used the "Paravirtualized Network (virtio-net)" network card (which is theoretically faster - but achieves its speed by NOT emulating an actual card) then the external network would cease to work when the cards were reversed

  • so I set both the NICs to "Intel PRO/1000 MT Desktop (82540EM)" - works fine, potentially slower

  • the NIC flip-flop also means that if you filter on virtual machine MAC you'll have to list both the MACs whereever because you don't know which one is going to show up ... my guess is this isn't a huge problem, but I guess it would depend on circumstance, haven't had to deal with it


  • used to be (perhaps when VirtualBox was under previous ownership) that USB was blocked unless you payed for the premium version: this seems to no longer be the case
  • while this is really great in some ways, dealing with USB in a guest OS can be a real PITA: the problem is that USB storage has to be mounted on the host OS, and then mounted on the guest OS - and if it's unmounted on the host before unmounting on the guest, you're going to have problems - it's not ideal
  • haven't tested how this applies to HID devices - most things like mouse and keyboard pass the input through the application so you don't have to handle it in the guest through the USB interface

Copying/Cloning/Moving Virtual Machines

  • select the machine you want to copy/clone/move in the left column
  • make sure the machine is shut off, not simply paused
  • in the upper right corner, click the "Snapshots" icon
  • click the "Clone" button (used to be a sheep, now two offset sheets of paper like the "Copy" button in most editors)
  • one option during the process is to "re-initialize all network cards" - very useful if you expect the clones will ever be running at the same time, as without this they will have the same MAC address(es)
  • for Moving the clone (my intent), I need a "Full clone" not a "Linked clone"
  • the next/final option is whether or not to include snapshots: I chose "Current machine state" which doesn't take snapshots with it
  • the clone appears as another virtual machine in your left column list - on Windows, you can right-click on the machine and say "Show in {Explorer|Finder|File Manager}" - which it says depends on your OS
  • on Windows, the files are stored by default in C:\Users\<username>\VirtualBox VMs\<machinename>\
  • on Linux and OS X: ~/VirtualBox VMs/<machinename>/
  • the new clone folder contains two files, both with the machine name, one with a .vbox extension, and the other, the OS/hard drive image, with a .vdi extension
  • copy the VDI file
  • put it on the new host machine: I put them in the ~/VirtualBox VMs/Imports folder I've created, follow along to see why
  • start VirtualBox, choose "New", go through the steps, and say "Use Existing Hard Disk", navigating to the new VDI file
  • this all works well, except for the fact that VirtualBox simply links to the VDI, it doesn't copy or move it: this means that if you left it on the USB stick you transported it on, the guest stops working without the USB stick, and if you copied it to a ~/VirtualBox VMs/ folder named after the OS, it doesn't entirely work out: thus the "Imports" folder mentioned above
  • amazingly, I took SliTaz (a little-known Linux distro) installed to a virtual disk on Windows and moved it to OS X and not only does it run, the Guest Additions are working properly (the network is broken and needs investigation)


  • An interesting distinction between Windows and Linux/Mac crops up if you use a non-standard keymap (I use Dvorak). On Windows, your mapped keystrokes are passed to the guest and you never have to do anything about it: on Linux and the Mac, you're back to the default keymap and for each OS installed you have to sort out the keymapping software yourself. Fun!

Future Reading

I found some piece of functionality in VirtualBox recently that was only available in the "Extension Pack." The Extension Pack doesn't appear to be readily available and may be even less open source than the rest of VirtualBox. Here's what appeared to be the best article on installing it that I found: