Demo Virtual Machine

We’ve created and made available to you a virtual machine (VM) image that aims to mimic all 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 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 that we’ve packaged here for you is not the kind of lean server that we advocate or that you would want in a production environment; but it is a perfect server to present 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 that we’ve run throughout this book, with all the real-world typos removed (we hope)

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

  • Some Easter eggs, as well as some of our very own sys admin mistakes!

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 things to do 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 hypervisor software as well as other applications that can be used used for interacting with or managing the hypervisor software.

  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 4GB of physical RAM on the physical host system, you can safely allocate 1GB of virtual RAM to up two individual VM instances (such that your host will have approximately 2GB left for itself).

  6. Decide which networking options you want to assign to the VM(s); for example, 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 that 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. And for best performance, the host CPU should support either Intel Virtualization Technology (Intel VT) or AMD Virtualization (AMD-V) extensions.Which tests/commands that 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:

[root @ intel-server ~]# grep -i “vmx” /proc/cpuinfo
flags : fpu pae mce cx8 apic …… vmx

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

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:

[root @ amd-server ~]# grep -i “svm” /proc/cpuinfo
flags : fpu vme de pse 3dnowext ……svm

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

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:

[root @ host ~]# egrep -oh ‘\w*(vmx|svm)\w*’ /proc/cpuinfo

Depending on the output and by using a simple process of elimination, you can determine whether your host platform architecture is Intel or AMD. If you see one or more vmx strings in the output, then you have a supported Intel CPU. If you see one or more svm strings in the output, then you have a supported AMD CPU. And if the command does not show either vmx or svm, then your CPU does not support the necessary extensionsthat will provide the best experience for using the VM.

Installing the Virtualization Applications and Utilities

We are assuming that your host system is running any of the recent Linux distributions. You should therefore already have support for KVM built into your kernel. All that’s left is to ensure that 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 Fedora/Centos/RHEL-based distro, use dnf to install the virt-install application:

[[email protected]~]# dnf -y install virt-install

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

[email protected]:~$ sudo apt-get -y install qemu-kvm

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

  1. On a systemd-enabled distro like Fedora, or a recent version of Debian or Ubuntu , you can start the libvirtd service by using the systemctl utility like so:

[root @ host ~]# systemctl start libvirtd

  1. On Linux distros using systemd as the service manager, use the systemctl utility to make sure that the libvirtd service starts up automatically during the next system boot:

[root @ host ~]# systemctl enable libvirtd.service

  1. Use the virsh utility to make sure that virtualization is enabled and running properly on the system:

[root @ host ~]# virsh list
Id Name State
———————-

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 rather large. It contains the entire operating system and lots of application. Depending on your Internet connect and other factors, you may or may not be able to download the entire image file in one swing. For this reason, we’ve created two versions of the file for you. The first version is a single large file that is almost 6GB. The second version is similar to the first version except that we’ve split it up into two individual smaller files. If you choose to use the smaller files, you will have to recombine the files after downloading them to form a complete VM image file.

Let’s start with the steps for downloading and decompressing the single 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:

[root @ host ~]# mkdir -p /home/vms/

  1. Change your working directory to the /home/vms location:

[root @ host ~]# cd /home/vms/

  1. Use the wget program to download the single file:

[root @ host ~]# wget -c -O abg-7e-vm.qcow2.tar.xz \
http://linuxserverexperts.com/7e/abg-7e-vm.qcow2.tar.xz

  1. Untar (extract and decompress) the image file that you just downloaded. Type

[root @ host ~]# tar xvJf abg-7e-vm.qcow2.tar.xz

  1. After a short while, you should end up with a single VM disk image file. Verify this by running

[root @ host ~]# ls -lh abg-7e-vm.qcow2

Alternatively, if you choose to download the VM image as two files, follow these steps:

  1. Create the directory to store the VM images:

[root @ server ~]# mkdir -p /home/vms/

  1. Change your working directory to the /home/vms location:

[root @ host ~]# cd /home/vms/

  1. Use wget to download the first file of the set of two:

[root @ host ~]# wget -c -O abg-7e.qcow2-01 \
http://linuxserverexperts.com/7e/abg-7e.qcow2-01

  1. Use wget to download the second file of the set:

[root @ host ~]# wget -c -O abg-7e.qcow2-02 \
http://linuxserverexperts.com/7e/abg-7e.qcow2-02

  1. Use the cat command to concatenate (join) the files together:

[root @ host ~]# cat abg-7e.qcow2-01 abg-7e.qcow2-02 > abg-7e-vm.qcow2.tar.xz

  1. Untar (extract and decompress) the recombined file by running

[root @ host ~]# tar xvJf abg-7e-vm.qcow2.tar.xz

  1. After a short while, you should end up with a single VM disk image file. Verify this by running

[root @ host ~]# ls -lh abg-7e-vm.qcow2

Hardware and Networking Notes for VMs

Virtual machines running on a host have to share the finite resources of the host. This is true for almost all the virtual components (disk space, memory, network cards, CPU, USB ports, and so on) that you assign to the VM. If your host system has total storage capacity of, say, 500GB, it would be unwise to allocate a virtual disk of 250GB to more than one VM. Similarly, if the host system has 8GB of physical RAM, it would be unwise to allocate virtual RAM of 4GB to more than one VM. Our point here is that you have to apply a liberal dose of common sense when building your VMs and assigning them virtual hardware from the host.

Different hypervisor platforms handle network provisioning for VMs in various fashions. Particularly, the KVM and libvirt platforms support several methods for handling network connectivity for VMs. Some of the these methods revolve around the concept of bridging on the host system, laced with a lot of pure black magic.

Probably the simplest method is the so-called bridge networking approach. Next in level of complexity are the NAT-only networking and user-mode networking (SLIRP) methods, the latter of which is good for allowing non-privileged users to run and manage their own VMs with some networking functionality. Finally are the more exotic solutions, such as Virtual Distributed Ethernet (VDE).

The Demo VM walk-through in this appendix uses bridged networking, which gives the guest VMs full outbound and inbound connectivity to and from the same LAN as the host system.

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. The steps are

  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-7e-vm.qcow2.original by running

[root @ host vms]# cp abg-7e-vm.qcow2 abg-7e-vm.qcow2.original

  1. 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

[root @ host vms]# virt-install \
–name abg-7e-vm \
–ram 2000 \
–disk /home/vms/abg-7e-vm.qcow2,bus=virtio,format=qcow2 \
–graphics vnc,listen=0.0.0.0,port=5910,password=abg \
–noreboot \
–import

Option

Description

Value(s)

–name

Name of virtual machine/guest instance.

abg-7e-vm

–ram

RAM (memory) to allocate to VM guest, in MiB.

2000

–disk

Specifies the path to the VM image that you are importing, as well as other storage-related options. The options are

bus Virtual disk bus type

format Disk image format

/home/vms/abg-7e-vm.qcow2,bus=virtio,format=qcow2

(Specifies the path to the VM image file, a bus option of virtio, and format option of qcow2.)

–graphics

Specifies the graphical display configuration.

vnc,listen=0.0.0.0,port=5910,password=abg

(These options will set up a VNC server listening on port 5910 on the host system. The password to use to connect is abg.)

–noreboot

Prevents the new domain from automatically rebooting after the install or import has completed.

–import

Skips the OS installation process, and imports a guest from an existing disk image.

Table 1: virt-install options
TIP: The virt-install command offers a rich set of options. You should definitely take a minute to look over its manual (man virt-install). For example, it has options (–os-variant) that will allow you to optimize the configuration for different guest operating system platforms (such as Windows, Unix, Linux, UNIX, and so on) out of the box.

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.

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

[root @ host ~]# virsh
virsh #

  1. 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:

virsh # help
attach-device attach device from an XML file
attach-disk attach disk device
……

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

virsh # list –-all
Id Name State
—————————
– abg-7e-vm shut off

The output shows that the fedora-VM guest domain is currently shut off (inactive).

  1. To view detailed information about the fedora-VM guest, type this:

virsh # dominfo abg-7e-vm
Id: –
Name: abg-7e-vm
UUID: ghghcf36-6a9f-4f0e-b7a4-562b793c1234
OS Type: hvm
State: shut off
CPU(s): 1
Max memory: 2048000 KiB
Used memory: 2048000 KiB
Persistent: yes
Autostart: disable

……

  1. Assuming the fedora-demo-VM is not currently running, you can start it by running

virsh # start abg-7e-vm

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 either run

# virsh –connect qemu:///system start abg-7e-vm

or run

# virsh start abg-7e-vm

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 10.0.0.88, you would run

# virsh –connect qemu+ssh:[email protected]/system

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

virsh # shutdown abg-7e-vm

  1. If the abg-7e-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:

virsh # destroy abg-7e-vm

  1. 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 re-import the original VM image to follow along the rest of this appendix.

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

virsh # undefine abg-7e-vm

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). But you shouldn’t just take our word for it. In this section we’ll walk through some of the methods that you can use to connect to, view, manage, and interact directly with the operating system running in the VM. The options are

  • Virtual Network Computing (VNC)

  • Secure Shell (SSH)

  • Virtual serial TTY console

  • 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):

IP Address

Tips

IP address of host (hypervisor) system

Use ifconfig or ip a on the host system to view its current IP address(es)

IP address of running Demo VM

Check your LAN’s DHCP server IP address leases for the newest DHCP requests/leases

Log in at the VM’s console and use ifconfig, ip, or nm commands to view the IP address

Virtual Network Computing (VNC)

VNC has been implemented as a graphics display option in KVM ( and 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.

There are numerous free VNC clients available on the Windows, Apple OS X, 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 client (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 Apple OS X versions . Other popular VNC clients include TightVNC, RealVNC, Chicken of the VNC, and so on.

We’ll demonstrate using the built-in VNC client on an OS X system here:

  1. While logged into an OS X system, launch the Finder application.

  2. In the Finder menu navigate to

Finder → Go → Connect to Server

  1. 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 192.168.1.10, the proper information for the Server Address field is

vnc://192.168.1.10:5910

image32-01 here.1

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

  2. After connecting and authenticating to the VNC server successfully, you will see a login or console screen within the VNC client window similar to the one shown here:

image32-02 here.2

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

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

  1. 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 address) to IP addresses. MAC addresses are supposed to be universally unique.

The tool that 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 these readily available information, we can obtain the IP address of a running VM from the host. For example, assuming that you’ve booted up the Demo VM and that VM instance name is – abg-7e-vm. You can obtain the MAC address and the current IP address for the VM by running:

# arp -an | grep “`virsh dumpxml abg-7e-vm | grep “mac address” | \

sed “s/.*’\(.*\)’.*/\1/g”`”

The sample corresponding output is:

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

From this output, we can tell the IP address for abg-7e-vm is – 192.168.1.202

Connecting via SSH

Chapter 22 covered the indispensable Secure Shell (SSH) protocol. As a reminder, SSH is a Linux/UNIX-based command interface and protocol for securely accessing remote systems/computers. It has been ported for use on numerous operating systems, including Windows platforms (newest Windows server versions are rumored to even support SSH natively).

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 192.168.1.202. 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, by running

[you @ client ~]$ ssh [email protected]

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

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

  3. 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

[root @ abg-vm ~]# hostnamectl set-hostname “kick-ass-server” –static

  1. Use the exit command to log out.

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

[you @ client ~]$ ssh [email protected]

After logging in successfully, the new prompt should look like this:

[root @ kick-ass-server ~]#

That’s it!

(2)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—since 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. The steps follow:

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

[root @ host ~]# virsh -c qemu:///session

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

virsh # list
 Id Name State
—————————————————-
1 abg-7e-vm running

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

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

virsh # ttyconsole abg-7e-vm
/dev/pts/8

  1. Finally, connect to its virtual serial console by executing

virsh # console abg-7e-vm
Connected to domain abg-7e-vm
Escape character is ^]

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

  2. To log into the system as the user master, type master at the login prompt and press enter.

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

  1. 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.

  1. Once you are logged in successfully, you might want to issue commands to obtain the IP address allocated to the VM and/or change the network settings of the VM to suit your environment.

That’s it!

Cockpit Application

The latest Fedora 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. Forget about all these new fancy GUI-based “point and click” tools like Cockpit.

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 that 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 that you’ve discovered the IP address of the Demo VM and that it’s 192.168.1.202, from any system within the same network as the Demo VM, launch your favorite web browser and visit the following website/URL (ignore or accept any certificate-related warnings):

https://192.168.1.202:9090/

You will be greeted with a web page similar to the one shown here:3image32-03 here

Type root in the User Name field. Then type root’s password (72erty7!2) in the Password field and 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

Tools → Terminal. You will see a screen similar to this one:4image32-04 here.

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/daemons that you want to use! In addition to just using it, you will also 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 in the Demo VM the DNS server component that we discussed in Chapter 16. Assuming the IP address of the Demo VM is 192.168.1.202, 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

[root @ client ~]# dig @192.168.1.202 example.org MX

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

[root @ host~]# smbclient -U% -L 172.16.1.202

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 10.0.0.202, use the telnet program from any computer to connect to port 17 on the Demo VM by running

[email protected]~$ telnet 10.0.0.202 17
Trying 10.0.0.202…
Connected to 10.0.0.202.
Escape character is ‘^]’.
……

Feedback

We’d love to hear from you and also know that you’re successfully applying and building upon the concepts/topics in this book to develop your own Linux system/network administration repertoire. One way 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 if necessary, and use the SMTP server on the Demo VM to send us an e-mail (showing your e-mail address) to feedback @ linuxserverexperts.com, showing your output/version of the previous telnet command.