How to Create a Server on VirtualBox

This tutorial shows you how to set up a desktop Linux virtual machine as a generic server that can be used as a Kubernetes manager or worker node, or for other kinds of “big software” testing. You can use a VM, set up exactly this way, when evaluating Mirantis products like Mirantis Kubernetes Engine and k0s – zero friction Kubernetes.

Prerequisites

To follow this tutorial, you’ll need a laptop or desktop Windows, Mac, or indeed Linux machine with internet access — for example, a desktop Linux development environment as described in this tutorial. You’ll also need sufficient resources — either on your local host or on another computer (or computers) connected to your local network — to run the ‘server’ virtual machines you’ll be building. Your LAN can be wired or wireless.

Note: a few old laptops worth of resources will let you build virtual servers to host reasonably performant configurations of any Mirantis product (e.g., k0s, Mirantis Kubernetes Engine) except for Mirantis Container Cloud — a system explicitly designed for managing consistent Kubernetes for production across multiple “big” infrastructures (e.g., VMware, OpenStack, AWS, Equinix Metal, etc.).

Step 1: Install VirtualBox on your server host

VirtualBox is “free as in beer” proprietary desktop virtualization software from Oracle that runs on Linux, Mac, and Windows. You’ll use it to host your ‘server’ VMs — the targets of your eventual “big software” deployment.

To install VirtualBox, just visit virtualbox.org, click the download link, and launch the executable. When you first start VirtualBox, it should automatically offer to download its Extensions Pack — do this, and install it.

Step 2: Download Ubuntu Desktop

Download a copy of Ubuntu Server 18.04.5 LTS, which is a recent version of Ubuntu Server supported by Mirantis for all of its products.

Step 3: Create and configure a new VirtualBox virtual machine

Start VirtualBox, and click on the top menu: Machine>New (or press CTRL-N).

Select Linux and Ubuntu (64-bit) from the popdowns. Give your machine a generic name that identifies it by operating system and version. You’ll use this initial VM image to create new VMs as you need them (a process called “cloning”).

Click Next, and assign a reasonable amount of RAM to your VM. Since we’re building servers for hosting (for example) Kubernetes manager or worker nodes, we usually want to set RAM to be as large as practical — understanding that this needs to be a compromise based on other resource demands on the host (including the presence of other running virtual machines). For what it may be worth, on a 32GB Windows laptop, you have enough room to run two virtual servers with 12GB RAM each (12GB = 12228MB, as shown below in the context of VirtualBox's memory allocator), while also leaving enough room for Windows and basic applications. These two servers are sufficiently resourced to host, for example, a Mirantis Kubernetes Engine manager and worker node, which is enough for basic evaluation and even laboratory use of this powerful Kubernetes/Swarm platform.

On the next screen, select the radio button to create a virtual hard disk file.

And select the radio button to use VDI format for the virtual disk.

On the next screen, determine if you want to create a dynamically-sized or fixed virtual hard disk file. Dynamic disks grow as they get filled up, so consume less of your mass storage. Fixed-size disks consume all their allocated space immediately, but run a little faster. If you plan on building a lot of containers, you may find the extra speed useful and worth the mass storage cost. Likewise, if you’re deploying infrastructure nodes (e.g., Kubernetes workers) that will then run workloads of their own, the extra speed of a fixed-size disk may be desirable, if you have the SSD space to spare.

Finally, pick the size of your virtual hard disk. 10GB — the default — is sufficient for most projects. Kubernetes nodes may require 25GB or more.

Click Create to tell VirtualBox to create your virtual hard disk.

Next, click to highlight your new VM in the left-hand menu and select Settings>System>Processor. A typical server VM will profit by being given two or more virtual CPUs (vCPUs). A Kubernetes node can use more, if your physical CPU has sufficient cores available.

Next, click the Network tab. VirtualBox offers many options for networking. VMs for cloudy work, however, have some special requirements:

• They need to conveniently access other VMs running on your local host.

• They may need to conveniently access VMs running on other VirtualBox hosts on the same wired or wireless LAN (for example, many people use old and spare laptops, all attached to the same LAN, to build home labs).

• You may need to access this VM from your host or vice-versa.

• All these machines are somewhat protected behind a home router and NAT (unless you’ve pinholed the router to enable access to a webserver VM — a popular application).

• You don’t want to mess with networking any more than you need to.

For this reason, we recommend using VirtualBox “bridged” networking unless you know you have reason not to do so. This networking mode gives each virtual machine you start a class C LAN IP address (i.e., 192.168.x.x) assigned by your local DHCP server (usually that home router), which is reachable from your host and any other machine (or similarly-configured VM) on your local network. Most home routers will, by default, reserve assigned IP addresses for long periods of time unless reset. So for all but the most long-term projects, this setup gives you directly-accessible IPs for all your VMs (no need for local tunneling or other shenanigans), and you can trust those IPs to stay the same, even when you power down VMs for periods of time.

Note: Ubuntu Server classically requires a cabled Ethernet connection for installation, because it doesn’t deploy by default with WiFi drivers enabled. This isn’t a worry when configuring VMs, because the hypervisor fakes the cable connection. So your physical host actually can be connected to network via WiFi. See the ‘Cable Connected’ field, which VirtualBox normally checks by default.

Finally, click the Storage tab. Here, you’re going to click on the icon of the CD-ROM drive (which is now empty) and use the popdown menu on the right (little CD icon) to ‘Choose a disk file …’ to browse to your newly-downloaded Ubuntu Desktop .iso. The popdown will also display links to install disk files you’ve used before.

Click ‘OK.’

Step 4: Install Ubuntu Server

Now you’re ready to install Ubuntu to the virtual drive of your VM. Double-click the VM’s name in the left-hand menu to start it. It will work for a while, then display Ubuntu install options. Pick the option that says “Install Ubuntu.”

Thereafter, Ubuntu Server will take you through a fairly quick group of setup screens. You’ll need to confirm the kind of keyboard you’re using, determine the scope of the installation, determine whether you want to apply all recent updates during installation, pick a username and password, and confirm that you want to install Ubuntu to the VM’s hard disk, erasing its current contents (of which there aren’t any). At a certain point, the installer may ask if you want to install certain default applications: OpenSSH server is a good application to install.

Ubuntu Server usually installs without a hiccup. Your VM will automatically restart when installation is complete. You’ll be prompted to remove the boot disk (the CD ROM in this case), but you can just press any key to pass this prompt. Log in with your username and password.

Step 5: Update your server

Unless updates were applied during installation, next step is to update your server with recent patches and software improvements.

sudo apt-get update
sudo apt-get upgrade

Step 6: Passwordless sudo

By default, Ubuntu Server sets up to insist that you enter a password before executing commands in sudo mode. This can be annoying. If you’d like to enter sudo without being asked for a password, here’s how to fix it. Note: on some cloud platforms, like Amazon Web Services EC2, Ubuntu is preconfigured with passwordless sudo for the administrative user by default.

Enter:

sudo visudo

This loads the sudo configuration file in the system default editor (nano). At the bottom of this file, add the line:

$USER ALL=(ALL) NOPASSWD: ALL 

… where $USER is a system-created shell variable that contains your username.

Save and exit. Then log out of the machine:

log out and back in. You should now be able to perform sudo actions as your administrative user, without providing your password.

Step 7: Fix vi

The vi editor is a very crude line editor that’s often used to make changes in configuration files. The benefit of vi is that it’s preinstalled on pretty-much any Linux server, so it’s always available. The nano editor — a little bit less crude — is usually also preinstalled for making quick file changes.

vi has a little problem on standard Ubuntu installations, which is that it doesn’t, in its default configuration, recognize the arrow keys on standard keyboards. This makes it impossible to drive the cursor around to navigate within a file.

This is easy to fix. First, open a terminal (CTRL-ALT-T).

You should already be in your home directory. Now enter:

sudo vi /etc/hosts

… you should be able to move around with the arrow keys. Exit vi (without saving changes) by pressing ESC, then entering :q! (colon, the letter q, and the exclamation point).

Step 8: Enable SSH

You’ll need OpenSSH server active in order to be able to log into your server remotely. Various deployer software (e.g., Mirantis Launchpad) also requires SSH to connect with and install software on servers.

Determine your VM’s local IP address by entering:

HTML pre Tag

ip addr

You’ll see the local IP in the list — if things on your LAN are set up conventionally and you chose “bridged” networking, this will be a Class C address (e.g., 192.168.x.x). Write this down.

Then start OpenSSH server:

sudo systemctl start ssh

On new Ubuntu Server installs, the ssh service normally enables itself at installation, so if you restart this VM, ssh accessibility will come back.

At this point, you can try logging into the server from your host or workstation VM:

ssh <username>@<ip_of_server>

You’ll need to provide your password.

Step 9: Upload a public key to your server for passwordless SSH

Many deployment systems (Mirantis Launchpad, Ansible, etc.) use SSH to remotely configure servers. It’s usually preferable (and sometimes required) to enable SSH on target machines to permit login with a private SSH key, instead of a password. The public key — the other part of a ‘keypair’ — is stored on the server to authenticate.

This is easy to set up. Our tutorial How to Generate an SSH Keypair shows you how, and how to upload the public key to your server. Once you’ve done this, you should be able to log into your server from your desktop using your private key, which is stored in /home/user/.ssh, as follows, where id_rsa is the name of the private key file:

ssh -i /home/user/.ssh/id_rsa <username>@<ip_of_server>

For test servers, it’s usually not necessary to further complicate the process by turning off regular login with passwords. Having this still available means you can still SSH in with a password if you don’t have your private key — handy, in some circumstances.

Step 10: Snapshot and clone your server VM

At this point, it makes sense to ensure that you can always return your VM to its current known good state. To do this, first power down the VM (don’t restart), whose VirtualBox window will close. Then select the VM in the left-hand menu, and click the green plus sign (+, also marked “Take”) in the upper bar. In just a second or so, you’ll be able to name your snapshot, and see it recorded in this VM’s list of available snapshots. Thereafter, if your VM gets broken for some reason, you can return it to this known good state by powering it down, right-clicking this snapshot, and selecting ‘Restore.’

You can also clone the snapshot to create new, clean servers for each new project you begin. It’s preferable to use VirtualBox’s “Full Clone” option for this (vs. “Linked Clone,” which creates a dependency between the original and cloned VMs’ virtual hard disks), and to remember to create new network-card MAC IDs for clones, so they don’t fight over IP addresses. You may also need to adjust hostnames so they’re distinct.

Step 11: Adjust VM hostnames

This is pretty simple. Three tasks are required to change the hostname of an Ubuntu server:

First, edit the file /etc@sol;hosts using sudo vi.

sudo vi /etc/hosts 

Change the hostname as represented in the second line of this file.

127.0.1.1 old_hostname # change 'old_hostname' to the new hostname

Save the file (exit vi with ESC, followed by :wq — colon, ‘w’, ‘q’). Then edit the file /etc/hostname the same way:

sudo vi /etc/hostname

and change the old hostname to the new hostname, there, saving the file once you’ve done so.

Finally, either issue a hostname command to update the hostname within the current shell session:

sudo hostname my_new_hostname

or simply log out and back in.

Step 11: Install curl

Curl is a much-used and much-loved application for interacting with web services and efficiently downloading binary and text content from websites. Curl is required on target servers by some Mirantis deployment workflows (e.g., the one described in Download k0s – Zero Friction Kubernetes). So it makes sense to install curl on your server (if it’s not already there). To do this, enter:

sudo apt-get install curl

Step 13: Next steps

At this point, your server is pretty-well tuned up and ready for real work. You should be ready to start using it as a target host for Mirantis Kubernetes products, like Mirantis Kubernetes Engine and k0s – zero friction Kubernetes.