Red hat enterprise linux server cookbook

Red Hat Enterprise Linux Server Cookbook

English | 2016 | ISBN: 978-1-78439-201-7 | 289 Pages | PDF, EPUB, AZW3 | 12 MB

Dominating the server market, the Red Hat Enterprise Linux operating system gives you the support you need to modernize your infrastructure and boost your organization’s efficiency. Combining both stability and flexibility, RHEL helps you meet the challenges of today and adapt to the demands of tomorrow.
This practical Cookbook guide will help you get to grips with RHEL 7 Server and automating its installation. Designed to provide targeted assistance through hands-on recipe guidance, it will introduce you to everything you need to know about KVM guests and deploying multiple standardized RHEL systems effortlessly. Get practical reference advice that will make complex networks setups look like child’s play, and dive into in-depth coverage of configuring a RHEL system. Also including full recipe coverage of how to set up, configuring, and troubleshoot SELinux, you’ll also discover how secure your operating system, as well as how to monitor it.
What you will learn

• Set up and configure RHEL 7 Server
• Use NetworkManager to configure all aspects of your network
• Manage virtual environments using libvirt
• Set up software repositories
• Secure and monitor your RHEL environment
• Configure SELinux, and create and apply its policies
• Create kickstart scripts to automatically deploy RHEL 7 systems
• Use Orchestration and configuration management tools to manage your environment

Homepage

Источник

Red hat enterprise linux server cookbook

This book will attempt to show you how to deploy RHEL 7 systems without too much of a hassle. As this book is written with automation in mind, I will emphasize on command-line utilities rather than elaborating on its GUI counterparts, which are useless for automation.

This chapter explains how to build and manage KVM guests using the libvirt interface and various tools built around it. It will provide a brief overview on how to set up a KVM on RHEL and manage its resources. The setup provided in this overview is far from the ready enterprise as it doesn’t provide any redundancy, which is generally required in enterprises. However, the recipes provided are relevant in enterprise setups as the interface stays the same. Most of the time, you will probably use a management layer (such as RHEV or oVirt), which will make your life easier in managing redundancy.

Libvirt is the API between the user and the various virtualization and container layers that are available, such as KVM, VMware, Hyper-V, and Linux Containers. Check https://libvirt.org/drivers.html for a complete list of supported hypervisors and container solutions.

As most tasks performed need to be automated in the end, I tend not to use any graphical interfaces as these do not allow an easy conversion into script. Hence, you will not find any recipes in this chapter involving a graphical interface. These recipes will primarily focus on virsh , the libvirt management user interface that is used to manage various aspects of your KVM host and guests. While a lot of people rely on the edit option of virsh , it doesn’t allow you to edit a guest’s configuration in real time. Editing your guest’s XML configuration in this way will require you to shut down and boot your guest for the changes to take effect. A reboot of your guest doesn’t do the trick as the XML configuration needs to be completely reread by the guest’s instance in order for it to apply the changes. Only a fresh boot of the guest will do this.

The virsh interface is also a shell, so by launching virsh without any commands, you will enter the libvirt management shell. A very interesting command is help . This will output all the available commands grouped by keyword. Each command accepts the —help argument to show a detailed list of the possible arguments, and their explanation, which you can use.

Installing and configuring a KVM

This recipe covers the installing of virtualization tools and packages on RHEL 7.

By default, a RHEL 7 system doesn’t come with a KVM or libvirt preinstalled. This can be installed in three ways:

Through the graphical setup during the system’s setup

Via a kickstart installation

Through a manual installation from the command line

For this recipe, you should know how to install packages using yum, and your system should be configured to have access to the default RHEL 7 repository (refer to Chapter 8, Yum and Repositories , for more information), which is required for the packages that we will use.

Alternatively, you could install packages from the installation media using rpm , but you’ll need to figure out the dependencies yourself.

Check the dependencies of an rpm using the following command:

This will output a list of binaries, libraries, and files that you need installed prior to installing this package.

Check which package contains these files through this command:

As you can imagine, this is a tedious job and can take quite some time as you need to figure out every dependency for every package that you want to install in this way.

Getting ready

To install a KVM, you will require at least 6 GB of free disk space, 2 GB of RAM, and an additional core or thread per guest.

Check whether your CPU supports a virtualization flag (such as SVM or VMX). Some hardware vendors disable this in the BIOS, so you may want to check your BIOS as well. Run the following command:

Alternatively, you can run the following command:

Check whether the hardware virtualization modules (such as kvm_intel and kvm ) are loaded in the kernel using the following command:

How to do it…

We’ll look at the three ways of installing a KVM onto your system.

Manual installation

This way of installing a KVM is generally done once the base system is installed by some other means. You need to perform the following steps:

Install the software needed to provide an environment to host virtualized guests with the following command:

The installation of these packages will include quite a lot of dependencies.

Install additional utilities required to configure libvirt and install virtual machines by running this command:

By default, the libvirt daemon is marked to autostart on each boot. Check whether it is enabled by executing the following command:

If for some reason this is not the case, mark it for autostart by executing the following:

To manually stop/start/restart the libvirt daemon, this is what you’ll need to execute:

Kickstart installation

Installing a KVM during kickstart offers you an easy way to automate the installation of KVM instances. Perform the following steps:

Add the following package groups to your kickstarted file in the %packages section:

Start the installation of your host with this kickstart file.

Graphical setup during the system’s setup

This is probably the least common way of installing a KVM. The only time I used this was during the course of writing this recipe. Here’s how you can do this:

Boot from the RHEL 7 Installation media.

Complete all steps besides the Software selection step.

Go to Software Selection to complete the KVM software selection.

Select the Virtualization host radio button in Base Environment , and check the Virtualization Platform checkbox in Add-Ons for Selected Environment :

Finalize the installation.

On the Installation Summary screen, complete any other steps and click on Begin Installation .

See also

To set up your repositories, check out Chapter 8, Yum and Repositories .

To deploy a system using kickstart, refer to Chapter 2, Deploying RHEL «En Masse» .

For more in-depth information about using libvirt, go to http://www.libvirt.org/.

RHEL 7 has certain support limits, which are listed at these locations:

Configuring resources

Virtual machines require CPUs, memory, storage, and network access, similar to physical machines. This recipe will show you how to set up a basic KVM environment for easy resource management through libvirt.

A storage pool is a virtual container limited by two factors:

The maximum size allowed by qemu-kvm

The size of the disk on the physical machine

Storage pools may not exceed the size of the disk on the host. The maximum sizes are as follows:

virtio-blk = 2^63 bytes or 8 exabytes (raw files or disk)

16 TB (using 4 KB block size)

Getting ready

For this recipe, you will need a volume of at least 2 GB mounted on /vm and access to an NFS server and export.

We’ll use NetworkManager to create a bridge, so ensure that you don’t disable NetworkManager and have bridge-utils installed.

How to do it…

Let’s have a look into managing storage pools and networks.

Creating storage pools

In order to create storage pools, we need to provide the necessary details to the KVM for it to be able to create it. You can do this as follows:

Create a localfs storage pool using virsh on /vm , as follows:

Create the target for the storage pool through the following command:

Create an NFS storage pool using virsh on NFS server: /export/vm , as follows:

Make the storage pools persistent across reboots through the following commands:

Start the storage pool, as follows:

Verify that the storage pools are created, started, and persistent across reboots. Run the following for this:

Querying storage pools

At some point in time, you will need to know how much space you have left in your storage pool.

Get the information of the storage pool by executing the following:

As you can see, this command easily shows you its disk space allocation and availability.

Be careful though; if you use a filesystem that supports sparse files, these numbers will most likely be incorrect. You will have to manually calculate the sizes yourself!

To detect whether a file is sparse, run ls -lhs against the file. The -s command will show an additional column (the first), showing the exact space that the file is occupying, as follows:

Removing storage pools

Sometimes, storage is phased out. So, it needs to be removed from the host.

You have to ensure that no guest is using volumes on the storage pool before proceeding, and you need to remove all the remaining volumes from the storage pool. Here’s how to do this:

Remove the storage volume, as follows:

Stop the storage pool through the following command:

Delete the storage pool using the following command:

Creating a virtual network

Before creating the virtual networks, we need to build a bridge over our existing network interface. For the sake of convenience, this NIC will be called eth0 . Ensure that you record your current network configuration as we’ll destroy it and recreate it on the bridge.

Unlike the storage pool, we need to create an XML configuration file to define the networks. There is no command similar to pool-create-as for networks. Perform the following steps:

Create a bridge interface on your network’s interface, as follows:

Remove your NIC’s configuration using the following command:

Configure your bridge, as follows:

Finally, add your NIC to the bridge by executing the following:

For starters, we’ll take a look at how we can create a NATed network similar to the one that is configured by default and called the default:

Create the network XML configuration file, /tmp/net-nat.xml , as follows:

Define the network in the KVM using the preceding XML configuration file. Execute the following command:

Now, let’s create a bridged network that can use the network bound to this bridge through the following steps:

Create the network XML configuration file, /tmp/net-bridge-eth0.xml , by running the following:

Create the network in the KVM using the preceding file, as follows:

There’s one more type of network that is worth mentioning: the isolated network. This network is only accessible to guests defined in this network as there is no connection to the «real» world.

Create the network XML configuration file, /tmp/net-local.xml , by using the following code:

Create the network in KVM by using the above file:

Creating networks in this way will register them with the KVM but will not activate them or make them persistent through reboots. So, this is an additional step that you need to perform for each network. Now, perform the following steps:

Make the network persistent across reboots using the following command:

Activate the network, as follows:

Verify the existence of the KVM network by executing the following:

Removing networks

On some occasions, the networks are phased out; in this case, we need to remove the network from our setup.

Prior to executing this, you need to ensure that no guest is using the network that you want to remove. Perform the following steps to remove the networks:

Stop the network with the following command:

Then, delete the network using this command:

How it works…

It’s easy to create multiple storage pools using the define-pool-as command, as you can see. Every type of storage pool needs more, or fewer, arguments. In the case of the NFS storage pool, we need to specify the NFS server and export. This is done by specifying—source-host and—source-path respectively.

Creating networks is a bit more complex as it requires you to create a XML configuration file. When you want a network connected transparently to your physical networks, you can only use bridged networks as it is impossible to bind a network straight to your network’s interface.

There’s more…

The storage backend created in this recipe is not the limit. Libvirt also supports the following backend pools:

Local storage pools

Local storage pools are directly connected to the physical machine. They include local directories, disks, partitions, and LVM volume groups. Local storage pools are not suitable for enterprises as these do not support live migration.

Networked or shared storage pools

Network storage pools include storage shared through standard protocols over a network. This is required when we migrate virtual machines between physical hosts. The supported network storage protocols are Fibre Channel-based LUNs, iSCSI, NFS, GFS2, and SCSI RDMA.

By defining the storage pools and networks in libvirt, you ensure the availability of the resources for your guest. If, for some reason, the resource is unavailable, the KVM will not attempt to start the guests that use these resources.

When checking out the man page for virsh (1) , you will find a similar command to net-define , pool-define : net-create , and pool-create (and pool-create-as ). The net-create command, similar to pool-create and pool-create-as , creates transient (or temporary) resources, which will be gone when libvirt is restarted. On the other hand, net-define and pool-define (as also pool-define-as ) create persistent (or permanent) resources, which will still be there after you restart libvirt.

Источник