Reading: None!
In this lab, you will set up a Ubuntu virtual machine for use in later labs.
Proceed as follows:
Download and install the latest version of VirtualBox (Version 7.1.4 at the time of this writing). Note that VirtualBox is available for Windows, macOS, and Linux system. If you are using one of the newer Macs built around the M-series processors ("Apple Silicon"), be sure to download the appropriate version of VirtualBox for that system.
Unfortunately, VirtualBox is not (yet) available for Windows-on-ARM devices such as the new "Copilot PCs." If you are using such a device, talk to me so we can find a work-around.
Download and install the VirtualBox extension pack from the same page as above. This adds some features to VirtualBox. I consider it a necessary part of a full installation.
Start the VirtualBox Manager (the GUI control panel for VirtualBox). Use the File > Tools > Network Manager menu item to view the list of preconfigured host-only networks. VirtualBox should have automatically created one named "VirtualBox Host-Only Ethernet Adapter" with the address 192.168.56.1/24. Verify this. If there is a problem, you can manually create a host-only adapter with the appropriate address.
Proceed as follows:
Download the latest version of Ubuntu Server (Version 24.04.1 LTS at the time of this writing). Do not use the 24.10 version. In a production environment, it is typical to stick to the Long-Term Support (LTS) versions for stability. The download is an ISO file.
If you are using an M-series Mac, you will want to download the ARM version instead (not the 64k page size version).
Proceed as follows:
From the main menu do Machine > New to bring up the Create Virtual Machine dialog box. Here are a few notes about how to fill in the various fields:
Click "Finish" to initialize the virtual machine. VirtualBox will automatically boot the system and start the Ubuntu installer. It should ask no further questions, but instead proceed immediately to doing an unattended installation.
After the installation completes, the system should automatically reboot and present a login prompt. Proceed as follows:
Log in as "student" with the password you created.
Install the SSH server using the command:
$ sudo apt install openssh-server
Use the following two commands to enable the SSH server to run on system boot and also to start the SSH server for this session:
$ sudo systemctl enable ssh
$ sudo systemctl start ssh
Check that the SSH server is working by connecting to it directly:
$ ssh student@localhost
Use the exit command to disconnect from localhost.
We now want to configure your system so you can use a modern SSH client to access it from your host rather than logging in via the guest's console. This is because the console is a primitive interface with almost no convenience features. Your experience will be much improved using a modern SSH client (of which there are many options).
Proceed as follows:
Shutdown the guest cleanly using:
$ sudo shutdown -h now
In the VirtualBox Manager, click on the "Settings" option for your Virtual Machine. Click on "Network" and then enable Adapter 2. Attach the adapter to the "Host-only Adapter" and be sure "VirtualBox Host-Only Ethernet Adapter" is selected in the "Name" field. This will create a second network interface in your guest that connects directly to the host on an internal, virtualized network that the host and guest share.
Reboot the guest and log back in.
Use the command ip addr to inspect a summary of your guest's network interfaces. You should see one (probably enp0s3) as "UP" with an IP address assigned (probably 10.0.2.15). You should also see another interface (probably enp0s8) as "DOWN". This is the Adapter 2 interface you created earlier. Take note of its name.
The file /etc/netplan/50-cloud-init.yaml is the file that defines the network configuration. By default, Ubuntu server uses a system called cloud-init to initialize server instances. This system allows servers to be configured easily by a central configuration server, for example, when booting virtual machines to support cloud services. We want to change sahara to a manual configuration. Start with:
$ sudo cat /etc/netplan/50-cloud-init.yaml
Follow the instructions in that file to disable cloud-init.
Now, modify that file so that it contains a note saying that you disabled cloud-init, your name, and when you did it. This documentation will help others understand the system's configuration later. Also, change the network configuration to:
network:
ethernets:
enp0s3:
dhcp4: true
enp0s8:
addresses: [192.168.56.2/24]
version: 2
Be careful with indentation. YAML ("Yet Another Markup-Language") uses indentation to indicate the structure of the file. Be sure you use the right interface names. Also, take note of the IP address. You can use any address you want on the 192.168.56.0/24 subnetwork except 192.168.56.1. The .1 address is connected to your host.
Apply the changes using:
$ sudo netplan apply
Use the ip addr command again to verify that the second network interface is now "UP" and has the expected IP address.
Now you should be able to use any SSH client on your host system to log into your guest at the IP address you specified (192.168.56.2, or similar). Verify that this works. You can then log out from the console and continue interacting with the guest via SSH.
It is very realistic for system administrators to use SSH to access remote servers that might reside in a different building, in a different city, or on a different continent. You are getting practice with that workflow here even though the system you are administering (sahara) is a guest VM on the same system you normally use.
It is normally a good idea to apply all available system patches to a freshly installed system. Use the following three commands to do this:
$ sudo apt update $ sudo apt upgrade $ sudo apt autoremove
The first command updates the local copy of the package database. This informs your system of any new packages that are available, but it doesn't actually change any of the packages on your system.
The second command downloads and installs new versions of any package that has an eligible update available.
The last command removes any packages that are no longer needed. These are packages that were automatically installed to satisfy dependencies in the past but aren't needed now because the new packages don't have the same dependencies. Often there are no packages to auto-remove, so don't be surprised if the last command does nothing.
Normally you should reboot the system after applying updates so the new packages can take full effect. This is particularly important if a kernel update was done since the kernel can't be replaced while the system is running. Use the command:
$ sudo shutdown -r now
This part just contains some useful supplementary information. It does not include any steps you need to complete for the lab.
When you want to turn off your virtual machine, you should first shut down the guest OS cleanly. Just closing the VirtualBox window is similar to abruptly powering off the VM. This can lead to problems since advanced operating systems tend to cache a lot of material in memory, and That material won't be properly saved when the power is unexpectedly shut off.
There are two commands to know:
$ sudo shutdown -h now $ sudo shutdown -r now
The first command "halts" (-h) the system. This puts the system into a state where it is safe to turn the power off (or close VirtualBox). The second command "reboots" (-r) the system. This is appropriate, for example, after applying updates when you want to immediately restart the system with the updates in place.
The word "now" in the commands specifies when you want the shutdown to occur. Naturally, "now" means right away. It is possible to schedule shutdowns (or reboots) for a later time, for example, in the middle of the night. Note that "now" is not the default, so if you forget to specify it, shutdown will schedule a future shutdown and behave in a way you aren't expecting. See the manual page for shutdown for more information.
If you are using a Windows host, you might notice a green turtle icon on the right-hand side of the status bar at the bottom of a VirtualBox window. This almost certainly means your Windows host is using Hyper-V, a type-1 hypervisor provided by Microsoft.
Type-1 hypervisors are virtualization systems that operate at a very low level, directly on the hardware. In contrast, VirtualBox and other similar systems (VMware) are type-2 hypervisors that run on top of a conventional operating system. Type-2 hypervisors need to go through the host OS to get to the hardware. Type-1 hypervisors don't need to do that, and so can be faster.
Modern Windows systems use Hyper-V for several purposes, in effect running your entire Windows host as a virtual machine on top of Hyper-V. That means your VirtualBox VM is running as a virtual machine inside a virtual machine. This can cause additional overhead, hence the turtle icon.
In the past, VirtualBox couldn't run at all if Hyper-V was enabled. However, modern versions of VirtualBox can work with modern Windows and provide reliable and reasonably efficient performance even with Hyper-V. In other words, don't worry too much about the green turtle.
You could experiment with disabling Hyper-V, but that is harder to do than it sounds and has consequences you might not like. For one thing, Windows uses virtualization technology (aka Hyper-V) to implement certain security features. You need to first disable all virtualization-based security features if you are serious about disabling Hyper-V. I don't recommend doing this.
Second, Hyper-V supports Windows Subsystem for Linux (WSL), so if you use WSL or plan to, you can't disable Hyper-V. Finally, Docker uses Hyper-V either directly or, more commonly, indirectly via WSL. Fully disabling Hyper-V rules out using these other systems on your device.
If you still want to try disabling Hyper-V on your system, proceed as follows (not fully tested):
Disable all virtualization-based security features. There are settings for these in the Windows settings application. You are looking for Memory Integrity (Device Guard) and Local Security Authority Protection (Credential Guard). These can be disabled in the "Core Isolation" settings (under Device Security) of the Windows Security app. You can use the Windows System Information tool to check if virtualization-based security is on or off (look toward the bottom of the list of features it displays).
Open the "Turn Windows Features Off and On" application and disable the following items.
Disable "Virtual Machine Platform." This will disable WSL and Docker-via-WSL.
Disable "Windows Hypervisor Platform" (WHP). This is the feature that allows VirtualBox and other type-2 hypervisors to interact with Hyper-V efficiently. However, if you are disabling Hyper-V, you don't need it.
Disable "Hyper-V." This disables your ability to create virtual machines on top of Hyper-V and removes the Hyper-V Manager tool from your system.
Note that the last two steps only apply to Windows Pro editions. Windows Home editions still use Hyper-V for security purposes and to support WSL, but they don't provide the additional Hyper-V services.
All of the steps above have to be done before Hyper-V is truly disabled. The "Hyper-V" feature only pertains to administrative and user tools related to Hyper-V. Deselecting that option while leaving the others active will still cause Windows to use Hyper-V internally.
After making these changes and rebooting your system, the green turtle icon should be gone and VirtualBox VMs might run a little faster. However, the difference probably isn't going to be large. The Windows Hypervisor Platform gives VirtualBox an efficient way to work with Hyper-V anyway.
There is no submission for this lab. The lab is worth 20 points.
Last Revised: 2025-01-13
© Copyright 2025 by Peter Chapin <peter.chapin@vermontstate.edu>