- Chapter 3. Introduction to Red Hat Virtualization Products and Features
- 3.1. KVM and Virtualization in Red Hat Enterprise Linux
- Setting up KVM on Red Hat Enterprise Linux
- Our Objectives
- Installing RHEL
- Virtualisation Extensions
- Install KVM and associated software components
- Networking Considerations
- Configure VNC
- Creating a Virtual Machine
- Listing existing Virtual Machines
- Final Thoughts
- Resources
- About Keith Rogers
Chapter 3. Introduction to Red Hat Virtualization Products and Features
This chapter introduces the main virtualization products and features available in Red Hat Enterprise Linux 7.
3.1. KVM and Virtualization in Red Hat Enterprise Linux
KVM (Kernel-based Virtual Machine) is a full virtualization solution for Linux on a variety of architectures. It is built into the standard Red Hat Enterprise Linux 7 kernel and integrated with the Quick Emulator (QEMU), and it can run multiple guest operating systems. The KVM hypervisor in Red Hat Enterprise Linux is managed with the libvirt API, and tools built for libvirt (such as virt-manager and virsh ). Virtual machines are executed and run as multi-threaded Linux processes, controlled by these tools.
QEMU and libvirt also support a dynamic translation mode using the QEMU Tiny Code Generator (TCG), which does not require hardware virtualization support. This configuration is not supported by Red Hat.
Figure 3.1. KVM architecture
The KVM hypervisor supports overcommitting of system resources. Overcommitting means allocating more virtualized CPUs or memory than the available resources on the system, so the resources can be dynamically swapped when required by one guest and not used by another. This can improve how efficiently guests use the resources of the host, and can make it possible for the user to require fewer hosts.
Overcommitting involves possible risks to system stability. For more information on overcommitting with KVM, and the precautions that should be taken, see the Red Hat Enterprise Linux 7 Virtualization Deployment and Administration Guide.
Kernel Same-page Merging (KSM), used by the KVM hypervisor, enables KVM guests to share identical memory pages. These shared pages are usually common libraries or other identical, high-use data. KSM allows for greater guest density of identical or similar guest operating systems by avoiding memory duplication.
The QEMU guest agent runs on the guest operating system and makes it possible for the host machine to issue commands to the guest operating system.
When several virtual machines are running simultaneously, they can interfere with the overall system performance by using excessive disk I/O. Disk I/O throttling in KVM provides the ability to set a limit on disk I/O requests sent from individual virtual machines to the host machine. This can prevent a virtual machine from over-utilizing shared resources, and impacting the performance of other virtual machines.
Automatic non-uniform memory access (NUMA) balancing moves tasks, which can be threads or processes closer to the memory they are accessing. This improves the performance of applications running on non-uniform memory access (NUMA) hardware systems, without any manual tuning required for Red Hat Enterprise Linux 7 guests.
Virtual CPU (vCPU) hot add capability provides the ability to increase processing power on running virtual machines as needed, without shutting down the guests. The vCPUs assigned to a virtual machine can be added to a running guest to either meet the workload’s demands, or to maintain the Service Level Agreement (SLA) associated with the workload.
As a Technology Preview, Red Hat Enterprise Linux 7.2 and later offers hardware-assisted nested virtualization. This feature enables KVM guests to act as hypervisors and create their own guests.
This can for example be used for debugging hypervisors on a virtual machine or testing larger virtual deployments on a limited amount of physical machines.
Setting up KVM on Red Hat Enterprise Linux
Editor’s Note: If you have a Linux system that runs KVM and would like to try Red Hat Enterprise Linux on KVM, follow our KVM Get started guide, https://developers.redhat.com/products/rhel/getting-started
The kernel-based Virtual Machine (KVM) is a virtualization infrastructure many have become familiar with throughout the industry. This article will guide you through getting a basic KVM hypervisor up and running and ready for use. In order to fully utilize the KVM, you will need a CPU that has virtualization extensions, and these will need to be enabled in the BIOS of the machine you’re working on. In general, you’ll need to look to enable VT-X or AMD-V depending on your system architecture.
Our Objectives
- Set up a RedHat Enterprise Linux (RHEL 7.2) server
- Identify whether Virtualisation extensions are present
- Install KVM and associated software components
- Networking Considerations
- Configure VNC
- Demonstrate how to fire up a new Virtual Machine running on the KVM hypervisor
- Listing existing Virtual Machines
Installing RHEL
For the purposes of this article, I’m going to be showing you how to manually install KVM from the command line, rather than opt to have it installed as part of the RHEL installation process. This will allow us to fine tune the installation by only installing what we need, and it also gives us a better understanding of how everything fits together. With this in mind, we will be working on the basis that you have opted for a ‘minimal install’ of RHEL. After first boot, you will want to register to the Red Hat network to receive updates and download software. This can be done by running the following command:
subscription-manager register –auto-attach
You will be prompted to enter your username and password.
Virtualisation Extensions
Now that we’re in a position to begin installing KVM and its components, I thought this would be a good time to show you how to check whether virtualisation extensions are being seen on our CPU from within RHEL. To do this, simply run:
grep –E ‘svm|vmx’ /proc/cpuinfo
You should see something similar to the following:
If you receive no output then it’s likely that virtualization extensions are not enabled in your BIOS and you will need to take steps to rectify this before moving forward with the KVM installation.
Install KVM and associated software components
For the purposes of this article, the assumption is that this RHEL machine running KVM will be used as a standalone hypervisor, so we will not be installing any graphical tools to manage the Virtual Machines.
To install KVM along with the components required to provision Virtual Machines from the command line, run the following command:
yum install qemu-kvm qemu-img libvirt virt-install libvirt-client libvirt-python
This command will also process a number of dependencies required during installation. Whilst we’re at it, let’s install ‘wget’ as we’ll be needing this later on:
Once the above has completed, we should check to ensure that the relevant KVM modules have been loaded to allow us to make full use of KVM. You can do this by running:
Your output should be as follows:
Excellent! We’re almost ready to begin creating Virtual Machines!
Networking Considerations
By default, KVM will set up a network interface on your hypervisor named ‘virbr0’. It creates a network for your Virtual Machines which uses NAT (Network Address Translation) to access resources outside of the network it resides on, which in our case is 192.168.122.0/24.
Depending on your environment, you may wish to create a bridge interface on your KVM hypervisor to allow the Virtual Machines to use the same network as the hypervisor by default and remove the layer of NAT.
Configure VNC
When you fire up a new Virtual Machine with the ‘—vnc’ option, you’ll find that it creates a listener on the localhost (127.0.0.1) address. If you want to be able to access this remotely without using things like SSH tunnels, then you’ll need to amend the ‘/etc/libvirt/qemu.conf’ file by removing the # in front of ‘vnc_listen = “0.0.0.0”’. This will allow any new VNC connections to listen on all interfaces and allow you to connect remotely.
It’s worth mentioning at this point that you’ll most likely want to add a firewall rule to allow the VNC traffic to your hypervisor—otherwise you won’t be able to connect. Generally, the VNC port range will start from TCP 5900. It’s unlikely that we will be running more than 200 Virtual Machines on our hypervisor, so if we open up TCP 5900 -> 6100, this should be enough to allow connections to succeed. We should first check which zone is active by running:
‘firewall-cmd –get-active-zones’
In my case, this is ‘public’. Now, we need to add a permanent firewall rule to allow traffic in on the ports defined above:
firewall-cmd --zone=public --permanent --add-port=5900-6100/tcp
We can verify our rule entry by running:
firewall-cmd --zone=public --permanent --list-ports
This command should return the following:
[root@kvm ~]# firewall-cmd --zone=public --permanent --list-ports 5900-6100/tcp [root@kvm ~]#
Creating a Virtual Machine
Now that we’re ready to provision a new Virtual Machine, let’s go ahead and download a Fedora ISO for example purposes. Run the following commands to create a directory to store your ISO images, then download the ISO. mkdir /home/iso && wget -O /home/iso/Fedora-Server-DVD-x86_64-23.iso https://download.fedoraproject.org/pub/fedora/linux/releases/23/Server/x86_64/iso/Fedora-Server-DVD-x86_64-23.iso
Once we have our ISO, we’re ready to do the fun bit and get a Virtual Machine up and running on our hypervisor! Whilst there are many options available when provisioning a new Virtual Machine, I’m going to include a simple one-liner below which will get you up and running.
virt-install --name fedora23 --ram 512 --file=/var/lib/libvirt/images/fedora.img --file-size=3 --vnc --cdrom=/home/iso/Fedora-Server-DVD-x86_64-23.iso
You should now see the following:
The above means that it’s waiting for you to proceed with the setup. We need to find out what VNC port the Virtual Machine Console is bound to. In order to do this run virsh vncdisplay fedora23. If this is the first Virtual Machine you’ve provisioned, then it’s likely it will return with “:0”. This means it’s listening on port 5900. If it was “:1” then the port would be 5901.
Now that we have the port of the VNC Console, use your favourite VNC client to connect to the address of the hypervisor and port. In my case, this would be 192.168.10.109:5900.
As you can see from the above screenshot, the VNC viewer shows the console of our Virtual Machine, and we can also see that an IP from the network range we discussed earlier has been assigned successfully!
Listing existing Virtual Machines
Another tool at our disposal is ‘virsh’. This can be used to perform all sorts of operations on your Virtual Machines. For instance, if you wish to see a list of all of your Virtual Machines (started or stopped), all you need to do is run:
Final Thoughts
KVM is an incredibly powerful hypervisor and is used as the backbone of many virtualisation solutions out there (Openstack, for instance). We’ve only touched the surface of what KVM is capable of, but you now have the building blocks for getting your own virtualisation solution in place.
Resources
- A GUI can be used to manage your Virtual Machines. See here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/sect-Creating_guests_with_virt_manager.html
- More information on ‘virsh’ can be found here: http://linux.die.net/man/1/virsh
- More information on KVM networking can be found here: http://www.linux-kvm.org/page/Networking
About Keith Rogers
Keith Rogers is an IT professional with over 10 years’ experience who currently works for a large broadcasting company out of the UK. His long-standing passion in computing has led to him taking up multiple extra-curricular activities to further his knowledge and fuel his interest.
Keith has spent years working with Linux by utilizing Apache, MySQL and PHP to build full web stacks along with creating more complex load balanced and redundant solutions suitable for high availability. In the last 2 to 3 years he has found himself using new cloud- based infrastructures such as those provided by AWS and Azure to assist in achieving these goals.
Currently, he’s working in the DevOps space with a focus on utilizing new automation tools such as Terraform / Ansible / Cloud-Init to efficiently and consistently deploy infrastructure. Along with this, he has been focusing on improving the bridge between Operations and Development by deploying new tools like Graylog to make it easier to parse log data and visualize any patterns within these logs.
In his spare time, he likes to spend time furthering his tech knowledge by utilizing new technologies at home.
Last updated: March 16, 2023