Most cloud providers will rent virtual servers rather than actual hardware. If you want to do the same thing on your own servers, either to run different operating systems or manage multiple environments, you can do so entirely from your terminal.

If you’re planning on only using virtual machines, you might be interested in a hypervisor. A hypervisor replaces your host OS, and is custom built for managing multiple virtual machines. You won’t be able to run applications on the host OS, but you can easily virtualize Ubuntu Server or something and run the applications on top of the hypervisor.

Installing VirtualBox and the VBox Extension Pack

VirtualBox is a free GUI-based virtualization software that runs as an app on your host OS (a Type 2 hypervisor). You might have used it before on a personal computer to set up a VM, but VirtualBox actually has a full command line interface and is fully usable from only a terminal, making it perfect for this use case. Another solution would be QEMU, but VirtualBox is tried and tested, and is unbeatable for being free and open source.

The VirtualBox CLI is admittedly a bit unwieldy though, so if you’re just messing about on a home server and have a bit of RAM to spare, you could instead install a light desktop environment on your server and set up VirtualBox the normal way. You can still run VMs in headless mode to keep them running after you log out of the DE.

If you do plan on sticking to the CLI, installation is fairly simple, as it’s available straight from apt:

You’ll want to make a note of the version that is installed though ( VBoxManage -v ), as you’ll need to install a few more things. Because we’re setting up in headless mode, we’ll need a way to connect to the machine before SSH/RDP can be configured.

Head over to VirtualBox’s download page, and find the link for the extension pack for the version you’re running on. Download it with wget:

And install it:

For some reason, VRDE didn’t seem to work for us with the built in VNC extension pack installed. Removing this pack solved the issue:

Setting Up a VM

To begin, we’ll create a new VM named “Ubuntu.” You can view a list of supported OS types with VBoxManage list ostypes.

Give the machine some RAM and create a new hard drive. We’ll go with 4 GB of RAM and 32 GB of HDD space, but these can both be expanded later. Note that the hard drive is a virtual disk, and isn’t preallocated.

Set the number of vCPUs. This is measured in threads, not full CPU cores.

Next is some more configuration for the hard drive. Usually this happens automatically when creating machines from the GUI, but you’ll have to manually create a SAS controller and attach it to the VM for the hard drive to work properly.

We’ll do the same for the disk that will hold the ISO to install the OS. This assumes your ISO is located at /home/user/Ubuntu.iso, so change it accordingly.

Then, flip some performance-related switches to prevent slowdowns from excess RAM usage:

Next, we’ll create the network that this VM will use. There’s a lot of options for this step:

NAT, the simplest, which simply allows the VM to communicate to the outside world using network address translation (NAT). This doesn’t allow VMs to talk to each other, and doesn’t allow host-to-guest contact unless port forwarded. NAT Network, is similar to NAT, except the network is shared among the VMs, and they can talk to each other. The NAT network acts as a virtual subnet. Bridged, which bridges the physical connection straight to the VM. The VM has an actual IP address on your network. This can work even with only one Wi-Fi/Ethernet connection, but if you’ve got a network card with multiple Ethernet ports, you can assign an entire interface directly to a VM. Virtual Network, which connects multiple instances in an isolated virtualized network. This is useful for modelling real networks, but isn’t suitable for most use cases. Host Only Adapter, is similar to virtual network, but allows talking to the host (not the internet).

For this example, we’ll go with NAT Network, as it’s simple to set up and the most versatile of the bunch, offing a balance of connectivity and isolation.

Create a new network on the 10.0.0.0/24 subnet, start it up:

And attach it to the VM:

Next, we’ll have to configure how we access this instance. Because we’re installing this on a headless server (no video output), we won’t be able to complete the installation process and install an RDP client on the guest OS. To solve this, we’ll use VirtualBox’s VRDE server, the main reason why we installed the VirtualBox Extension Pack earlier. This captures the output of the virtual display and makes it available over RDP.

Turn this on, and set a port for it. You’ll want to make sure the host OS has this port open.

Finally, we’re able to start the VM in headless mode and begin OS installation.

Note that headless mode means it’s running on a headless server, and not that the guest OS has no video out.

It will take a second or two to start, and you’ll be able to fire up an RDP client and connect to it using the port you specified. It may ask for a username and password; VRDE defaults to “admin” with no password.

Port Forwarding After Setup

Once OS installation is complete, you’ll have to do some port forwarding to maintain access after VRDE is turned off, essentially like opening firewall rules. If you’re setting up a headless environment like Linux, you’ll simply have to port forward SSH. The following command will add a port forward rule to your NAT network to forward port 2200 on the host OS to the default SSH port on the guest. Note that this port will need to be open in your host’s firewall for this to work.

If you’re setting up RDP, you’ll have to configure the RDP server in the guest OS, and make sure the RDP port is open in the guest’s firewall. After that, you can port forward in much the same way:

If you need to delete port-forwarding rules, you’ll have to delete them by name with this rather unwieldy command (the first string before the colon):

Once you’ve verified that you can connect over SSH/RDP directly to the guest OS, you can turn off VRDE:

If you’re planning on using this VM over RDP for extended time periods, you might want to install the VirtualBox Guest Additions suite for your guest OS.

If you do decide to manage VirtualBox using the GUI after setting up this VM from the CLI, keep in mind that this VM was created as root, so you will need to launch the VirtualBox GUI as root to see this VM in the list. Otherwise, it should work normally.

Also, If you want the machine to run while your desktop environment is shut down, you’ll have to right-click to launch the machine in headless mode.