B Demo Virtual Machine and Container – Linux Administration: A Beginner's Guide, Eighth Edition, 8th Edition



Demo Virtual Machine and Container

We’ve created and made available to you a virtual machine (VM) image that aims to mimic most of the exercises and projects covered in this book, from the installation chapter (Chapter 2) all the way through the backup chapter (Chapter 31). This VM is based on the native Linux Kernel-based Virtual Machine (KVM) hypervisor implementation. What we’ve ended up with is a really bloated and ill-advised server that’s running/serving various services and daemons. This server can offer web, LDAP, DNS, VoIP, tax advice, file, teeth-whitening, DHCP, fortune-telling, SMTP, accounting/bookkeeping, IMAP and POP, FTP, and legal advice services!

Throughout this book, we’ve consistently emphasized the importance of running lean servers that run absolutely only the minimum number of services and applications required. This is good for both security and management reasons. As the previous paragraph indicates, the server we’ve packaged here for you is not the kind of lean server that we advocate or you would want in a production environment; however, it is a perfect server for presenting most of the topics and concepts covered in this book in a nice, safe, and controlled environment. Once the VM is powered up, you’ll find enshrined in it the following:

•   A history of most of the commands we’ve run throughout this book

•   Files, users, groups, daemons, configs, scripts, and applications we created or installed

•   Some Easter eggs, as well as some of our very own sysadmin mistakes and typos!

The virtual machine is just a file (albeit a large one), so you can easily duplicate it, destroy it, re-create it, or start from scratch when you make any mistakes—without meaningfully affecting the underlying physical system/computer.

Here is a summary of the steps to take in order to use this VM image:

1.   Ensure that your host system meets the minimum system requirement to run the KVM hypervisor. For best performance, the CPU of the host system should at least support the relevant extended CPU virtualization instructions. See Chapter 30 for more details.

2.   Install the applications that can be used for managing the hypervisor.

3.   Download the VM image file.

4.   Make a backup copy of the original VM image file that you downloaded. Make extra copies of the KVM image file if you intend to run multiple instances.

5.   Decide how much hardware resources you want to assign to the VM(s). For example, if you only have 8GB of physical RAM on the physical host system, you can safely allocate 2GB of virtual RAM to up to two individual VM instances (such that your host will have approximately 4GB left for itself).

6.   Decide which networking options you want to assign to the VM(s), such as bridged networking, NAT-only, host-only, and so on.

7.   Fire up the VM(s)!

The following sections cover the requirements and steps in more detail.

Basic Host System Requirements

The host system is the system you will run the VM on. The VM will be constrained by whatever constraints the host has. You should have enough storage/disk space available on the host to download the VM image. The host CPU should support either Intel Virtualization Technology (Intel VT) or AMD Virtualization (AMD-V) extensions. Which tests/commands you execute in the following section depends on your host system platform (Intel or AMD), which corresponds with the CPU type of your host system.

While logged into an Intel-based host system running Linux, check whether the Intel processor shows support for the vmx instruction, by using the grep command to search for the desired flag in /proc/cpuinfo, like so:

The presence of vmx in this output shows that the necessary Intel CPU extensions are in place.

While logged into an AMD-based host system running Linux, check whether the AMD processor shows support for the Secure Virtual Machine (svm) instruction, by using the grep command to search for the desired flag in /proc/cpuinfo, like so:

The presence of svm in this output shows that necessary AMD CPU extensions are in place.

If you aren’t sure what your host platform or architecture is, you can use the following command to test for either of the flags:

Depending on the output and by using a simple process of elimination, you can determine whether your host platform architecture is Intel or AMD. However, if the command does not show either vmx or svm, then your CPU does not support (or you haven’t enabled) the necessary extensions that will provide the best experience for using the VM.

Installing the Virtualization Applications and Utilities

Most modern Linux distros have support for KVM built into the kernel by default, so all that’s left is to ensure you have all the supporting userland tools, utilities, and libraries installed for interacting with the KVM subsystem.

Several such tools are available for creating or managing VMs. We’ll keep things simple and use the readily available virt-install utility, which is based on the libvirt C library, to provision the new VM from an existing image.

Use the following steps to install the needed applications:

1.   On a Red Hat–like distro, use dnf to install the virt-install application:

2.   On a Debian-based distro like Ubuntu, you can install the packages and load the necessary modules by first running

and then using the modprobe command to load the appropriate module for your platform (kvm-intel or kvm-amd).

3.   On a systemd-enabled distro, you can simultaneously enable the libvirtd service for automatic startup and start the libvirtd service by using the systemctl utility like:

4.   Use virsh to make sure virtualization is enabled and running properly:

As long as the previous output does not return any errors, you are fine.

Download and Prep the Demo VM Image File

The original, uncompressed VM image file is large and contains the entire operating system and lots of applications. We compressed the original file to make it faster/easier for you to download.

Let’s start with the steps for downloading and decompressing the file:

1.   On our sample host system, we will store all the backing storage files pertaining to each VM under a custom directory path named /home/vms/. Let’s create that directory:

2.   You will need to obtain the exact download location (URL) for the demo VM image. For the sake of redundancy, we’ve published this information on a few web sites (just in case any of them become unavailable). You can use your favorite web browser to get the latest/exact download location by navigating to any of the following web sites:

•   https://linuxserverexperts.com/8e/.

•   https://www.mhprofessional.com/9781260441703-usa-linux-administration-a-beginners-guide-eighth-edition. (Click the Downloads & Resources tab.)

3.   Once you’ve found the exact download link, copy the link to your clipboard (try right-clicking the final link and selecting an option similar to Copy Link...).

4.   Substitute <DOWNLOAD-LINK> with the proper URL in the following command:

For example, if the link you obtained from the first web site is https://linuxserverexperts.com/8e/abg-8e-vm.qcow2.tar.xz, you can use the wget program to download the single file by running the following:

5.   Untar (extract and decompress) the image file that you just downloaded:

6.   Once this is done, you should end up with a single VM disk image file. Verify this by running the following:

Import the Demo VM Image and Create a New VM Instance

With all the prerequisites out of the way, we are now ready to instantiate the VM. We’ll use the virt-install utility that was installed earlier. Here are the steps:

1.   Make backup copies of the original/pristine VM image, just so that you will always have a clean image to fall back to if necessary. The copies can also be used to spin up additional VM instances if, for example, you decide to set up an entire network of VMs for various purposes.

While in the /home/vms directory, make a copy of the original VM image and name the copy abg-8e-vm.qcow2.original by running

2.   Use the virt-install utility to import the VM image. The virt-install utility supports several options that allow you to customize the new VM. The requirements/parameters that we use are described in Table B-1. Import the VM by running

Table B-1 The virt-install Options

Managing the Demo Virtual Machine

In the preceding section, we walked through the process of importing and creating a new virtual machine from an existing image. In this section, we will look at some typical tasks associated with managing guest virtual machines.

We’ll use—and encourage you to learn how to use—the feature-rich virsh program for most of our tasks. virsh is used for performing administrative tasks on virtual guest domains (machines), such as shutting down, rebooting, starting, and pausing the guest domains.

virsh can run directly from the command line using appropriate options, or it can run directly inside its own command interpreter. It is also based on the libvirt C library.

We will use virsh inside its own shell in the following examples:

1.   To start virsh in its own minimal interactive shell, type the following:

2.    virsh has its own built-in help system for the different options and arguments that it supports. To see a quick help summary for all supported arguments, type this:

3.   To list all the configured inactive and active domains on the hypervisor, type the following:

The output shows that the abg-8e-vm guest domain is currently shut off (inactive).

4.   To view detailed information about the abg-8e-vm guest, type this:

5.   Assuming abg-8e-vm is not currently running, you can start it by running this:

TIP You can run virsh commands directly from the Linux shell (for example, Bash) without dropping down into the virsh interactive shell by using the --connect option with virsh. For example, to start our demo VM running on the local hypervisor, we can run either

It is possible to connect to and manage hypervisors on remote hosts, through the use of rich connection Uniform Resource Identifiers (URIs) supported by virsh using the --connect option.

For example, to connect to and manage KVM on a remote host with the IP address, you would run

6.   Use the shutdown argument to shut down the fedora-demo-VM domain gracefully:

7.   If the abg-8e-vm guest domain has become wedged or frozen and you want to power it off ungracefully (this is akin to yanking out its power cable), type this:

8.   We still need this VM, so do not complete this step yet! If you do, you will have to go back to the earlier sections and reimport the original VM image to follow along with the rest of this appendix.

However, if you ever need to undefine the abg-8e-vm guest domain or remove its configuration from the hypervisor, type this:

Connecting to the Demo VM

Your demo VM should be up and running at this point (if you stopped at Step 5 in the previous section). However, you shouldn’t just take our word for it. In this section, we’ll walk through some of the methods you can use to connect to, view, manage, and interact directly with the operating system running in the VM. Here are the options:

•   Virtual Network Computing (VNC)

•   Virtual serial TTY console

•   Secure Shell (SSH)

•   Cockpit application

•   Just use it!

To make the entire process easy, you should have the following IP addresses readily available to you ahead of time (using any means possible):

Virtual Network Computing (VNC)

VNC has been implemented as a graphics display option in KVM, as well as Quick Emulator (QEMU). Normally, a new VNC connection will be set up on every new VM that specifies the VNC graphics option, using a TCP port starting from 5900, 5901, 5902, and so on. To avoid clashing with possibly existing ports, and to better guarantee that you can connect successfully to the VM via VNC, we hard-coded the VNC listening port in the imported VM profile to be port 5910. We also specified a simple password of abg.

NOTE  The VNC password for the virtual machine is abg.

Numerous free VNC clients are available on the Windows, macOS, and Linux operating systems. Most of these platforms even have VNC clients built directly into the standard OS application suite so that you won’t need to install any third-party VNC clients (if you don’t want to). Both of the popular GNOME and KDE desktop environments in Linux have built-in VNC clients. Same goes for recent macOS versions. Other popular VNC clients include TightVNC, RealVNC, and Chicken of the VNC.

We’ll demonstrate using the built-in VNC client on a macOS system here:

1.   While logged into a macOS system, launch the Finder application.

2.   In the Finder menu, navigate to

3.   Finder → Go → Connect to Server.

4.   Complete the fields in the ensuing Connect to Server window with the proper information, as shown next. For example, to connect to the demo VM running on a remote Linux hypervisor with the IP address, the proper information for the Server Address field is


5.   You will be prompted for the VNC password. Type abg when prompted.

6.   After connecting and authenticating to the VNC server successfully, you will see a login or console screen within the VNC client window.

To log into the system as master, type master at the login prompt and press ENTER.

At the Password prompt, type 72erty7!2 (master’s password) and press enter.

7.   Alternatively, if you want to log into the system as the superuser (root), type root at the login prompt and press ENTER.

At the Password prompt, type 72erty7!2 (root’s password) and press ENTER.

From here on, you can continue to use and interact with the VM just as you would a physical machine or any other VM.

TIP  We mentioned the Address Resolution Protocol (ARP) in Chapter 11. ARP provides a mechanism for mapping Ethernet addresses, or Media Access Control (MAC addresses), to IP addresses. MAC addresses are supposed to be universally unique. The tool we used for provisioning the demo VM automatically generates and assigns unique MAC addresses to the network interfaces in a VM.

The MAC addresses for VMs are stored/saved along with other information in a virtual machine profile, usually stored in an Extensible Markup Language (XML) format, under /etc/libvirt/qemu/. By combining various command-line utilities that can query, filter, parse, and sort through all of this readily available information, we can obtain the IP address of a running VM from the host.

For example, assuming you’ve booted up the demo VM and that the VM instance name is abg-8e-vm, you can obtain the MAC address and the current IP address for the VM by running the following:

The sample corresponding output is

? ( at 99:99:00:fe:0f:75 [ether] on br4

From this output, we can tell that the IP address for abg-8e-vm is

Virtual Serial TTY Console

This connection method is a virtual implementation of a really old-school way of connecting to devices using a serial connection or port. No actual physical serial ports or devices are required on the host or the VM for this to work—it’s all virtual.

The beauty of this connection method is that you don’t need to know the IP address of the demo VM ahead of time. However, you do need to be connected to and logged into the host system using any means possible. Follow these steps:

1.   While logged into the host server, connect and launch a virsh shell by running the following:

2.   While at the virsh shell, list any running VM domains:

Take note of the name of the VM under the Name column of the output. In our example, the name is abg-8e-vm.

3.   Once you’ve ensured that the demo VM is running, view the virtual TTY console that has been allocated to the running demo VM:

4.   Finally, connect to its virtual serial console by executing the following:

5.   Press enter to see the actual console and the login prompt.

6.   To log into the system as master, type master at the login prompt and press ENTER.

At the Password prompt, type 72erty7!2 (master’s password) and press ENTER.

7.   Alternatively, if you want to log into the system as the superuser (root), type root at the login prompt and press ENTER.

At the Password prompt, type 72erty7!2 (root’s password) and press ENTER.

8.   Once you are logged in successfully, you might want to issue commands to view the VM’s IP address and/or change the network settings of the VM to suit your environment.

That’s it!

Connecting via SSH

Chapter 23 covered the indispensable Secure Shell (SSH) protocol. As a reminder, SSH is the de facto GNU/Linux protocol for securely accessing and administering remote systems. It has been ported for use on numerous operating systems and platforms, including Microsoft Windows.

Until something better comes along, every system/network administrator should have SSH in their toolkit and (of course) know how to use it.

The demo VM that you imported earlier already has an SSH server running and listening for connection requests on the default SSH port 22. Remember that, once fired up, the demo VM is just like any other physical machine on your LAN—albeit virtual. Therefore, you can connect and manage it remotely. To connect to the SSH server on the demo VM, you will need to know the IP address of the VM instance. You can glean this information from various sources, such as the DHCP server on your LAN, the VM’s console, and so on.

In the following steps, we’ll assume that you’ve discovered the IP address of the demo VM and that it’s From any system with an SSH client, use ssh to connect to the VM. Here we use a built-in SSH client from a Linux workstation:

1.   Connect to the demo VM as the root user using ssh from the command line:

2.   If you get a warning about the authenticity and fingerprint of the remote host, type yes to continue.

3.   Enter root’s password (72erty7!2) when prompted for the password.

4.   Once logged in successfully, you’ll be at the shell prompt of the demo VM, where you can run numerous commands. For example, to view or change the hostname of the demo VM using the systemctl command, type the following:

5.   Use the exit command to log out.

6.   Use SSH to log back into the system formerly known as demo VM to see the new hostname:

After logging in successfully, you’ll see the new prompt, which should look like this:

That’s it!

Cockpit Application

The latest Fedora, RHEL, CentOS distributions ship with the web-based Cockpit management console installed and enabled by default. Cockpit provides a web-based interface to aid system management. The Cockpit project is still somewhat in its infancy but is very usable and production ready in its current form. You can expect that a lot of new features and capabilities will be added to it over time.

As we’ve alluded to throughout this book, there’s nothing quite like the good ol’ command line to get your system/network admin tasks done quickly and efficiently. We’ve suggested that you forget about all these new fancy GUI-based “point-and-click” tools (like Cockpit) and get familiar/comfortable with using the CLI for System Administration tasks.

But darn it, when we were all poised to dislike it, it turns out Cockpit has a web-based shell console built into it!

The demo VM you imported earlier has its own Cockpit instance already running and listening for connection requests on the default port, 9090. Remember that, once fired up, the demo VM is just like any other physical machine on your LAN. Therefore, you can connect and access its services remotely.

To connect to and use Cockpit, you will need to know the current IP address of the demo VM. The IP address might even be printed for you right at the login console/screen. You can view the login console/screen of the demo VM using any of the methods discussed in the previous sections. Assuming you’ve discovered the IP address of the demo VM (and that it’s, from any system within the same network as the demo VM, launch your favorite web browser and visit the following web site/URL (ignore or accept any certificate-related warnings):

You will be greeted with a web page similar to the one shown here:

Type master in the User Name field. Then type the corresponding password (72erty7!2, if you haven’t changed it) in the Password field. If it’s available, select the option to elevate your session so that you can perform privileged actions while using Cockpit. Click the Log In button.

After authenticating and logging in successfully to Cockpit, you can view the built-in web-based console/shell/terminal by navigating to Host → Terminal. You will be presented with a familiar command-line terminal and a shell prompt.

TIP  We cobbled together a little script that can be used for restoring the demo VM to an almost clean or pre-customization state. Running the script will remove most of the software packages, source code, history of commands, users/groups, configuration files, and other server customizations that were done after the initial operating system installation. You can use wget to download the script by running the following:

After downloading the script, and making double sure you want to clean up (restore) the demo VM server, you can do so by running this:

Just Use It!

Out of the box and with the exception of the DHCP service, your demo VM should be running virtually every service/daemon and command that we’ve covered in this thick book. And so, to take the “Just Use It!” approach, you will need to at least know a little about whichever of the many components, services, or daemons you want to use! In order to use one, you will need to know how to connect to the demo VM via its IP address. The previous sections talked about the various ways to obtain this information.

Say, for example, you want to test the DNS server component we discussed in Chapter 16 inside the demo VM. Assuming the IP address of the demo VM is, you can use the dig command on your workstation or on the host system to query the DNS server running in the demo VM by running the following:

Suppose you want to list the Samba shares we configured in Chapter 24 and the IP address of the demo VM (Samba server) is You can use the smbclient command on your workstation or on the host system to query the Samba server by running this:

As a final test of the immense and magical capabilities of the demo VM that we lovingly put together for you, let’s query it for some random fortune-telling and wise sayings. Assuming the IP address of the demo VM is, use the telnet program from any computer to connect to port 17 on the demo VM by running the following:

Demo Containers (Docker, podman, buildah, and kubectl)

For extra points, we also created a demo container that unashamedly runs way too many of the services we covered in this book. Please note that this container is completely contrary to the function of containers. Containers are supposed to be single-purpose abstractions of a very specific function. The image for the container is located on Docker hub at https://hub.docker.com. First, make sure you have all the client-side Docker tools installed (see Chapter 30). You can also follow along if you instead have other Open Container Initiative (OCI)–compatible tools (podman, buildah, and so on) installed. Follow these steps to pull down and start using the demo container:

1.   While logged into a system as a user with Docker privileges, download the Dockerfile into your PWD, as shown next. The directives in the Dockerfile will help pull down and build the correct image from the registry.

2.   Use docker (or buildah) to pull down, build, and tag the container image:

To alternatively use buildah, type this:

3.   Once you have successfully done this, query your local image repository to list available images:

To alternatively query buildah for the images it knows about, type this:

4.   Create a sample container from the new image:

To use podman to create a container from the buildah image, type the following:

5.   Use the exec option with Docker or podman to launch an interactive Bash session inside the running container. For the Docker container, type the following:

To alternatively use podman, type this:

6.   Once safely inside the container, you should be able to explore the completely containerized environment almost as though you were inside a regular system. For example, run the ps command inside the container, as follows:

Because this is a container, you might only see a handful of processes running instead of the usual long list of processes in a regular server or VM.

7.   The container has many of the daemons and services discussed in this book preconfigured and running. For example, you can use any SSH client to access the container’s SSHD daemon that was mapped to the host’s port 2222 (via the -p 2222:22 option) by running the following:

8.   If you have docker-compose installed and want an easy way to play with all the services container style, you can download the docker-compose.yml file from the following URL:

Once downloaded into your PWD, use docker-compose to gracefully start the container and map all the ports of the various services to ports on the host system:

9.   And if you are feeling super-adventurous and want a slightly more elaborate Kubernetes-style approach, where some of the services/components have been defined declaratively and are segregated into different containers and pods, you can download the following Kubernetes-compatible pod definition:

10.   Once this is downloaded, you can bring up the entire cluster using podman:

11.   And if you already have the entire Kubernetes toolchain installed, you can bring up a native Kubernetes cluster using kubectl by running this:

And that’s it.


We’re glad you made to the end of this book! We’d love to hear from you about how you’re successfully applying and building upon the concepts/topics in this book to develop your own Linux system/network administration repertoire. One way we’d like for you to get in touch with us is to construct the proper sequence of commands (and options), tweak the SMTP server configs (Chapter 19) on your demo VM or demo container(s), and use the SMTP server on the demo VM or demo container to send us a “Hello, World ...” e-mail (showing your e-mail address) at feedback@linuxserverexperts.com.

Thank you and good luck in your system administration journey!