The virt-manager, also known as the Virtual Machine Manager, is a graphical application for creating and managing guest virtual machines. The virt-manager application allows you to create new domains, install guest OS in virt-manager via a wizard or manually, configure domain resource allocation, and manage virtual hardware. It also presents an overview of running domains and their live performance.
Before going ahead, ensure that you have already installed the KVM hypervisor and that the host is ready for virtualization. If you haven’t already installed the KVM hypervisor on your Linux distribution, visit my previous blog on How to Install KVM on Linux and Run Guest OS Faster.
In this blog, I’ll show you how to install the guest OS using the virt-manager graphical application. However, if you would like to install the guest OS from the command-line interface, check out my other article How to Install a KVM Guest OS from the Command-Line.
The operating system I choose for this blog is Rocky Linux, but you may choose any other operating system. So, let’s begin.
1. Install Guest OS in virt-manager using the wizard
Open Virtual Machine Manager from the application menu or by typing virt-manager in the terminal.
Once it opens, click the computer icon in the top left corner.
This will start a wizard and let you create a new virtual machine in five easy steps.
1.1 Choose how you would like to install the operating system
- If you are installing the operating system from an ISO image, pick the first option.
- If you wish to install straight from the network, choose the second option and provide the URL of the installation tree, such as 'http://dl.rockylinux.org/pub/rocky/8.4/AppStream/x86 64/os/'.
- Choose the third option if you have downloaded the ready-to-use qcow2 image that is offered by most operating systems.
- And finally, if you would like to install manually, select the fourth option.
Since I’m installing Rocky Linux from an ISO image, I’ll choose the first option and click the Forward button.
1.2 Locating and configuring the installation media
Provide the location of the ISO installer image and the operating system for which the guest virtual machine must be optimized.
I choose Red Hat Enterprise Linux as Rocky Linux is based upon it. Click Forward to continue.
1.3 Configuring memory and CPU options
- Provide the amount of host RAM (in MiB) you would like to assign to the guest VM.
- The number of virtual CPUs you would like to assign to the guest VM.
Click the Forward button to continue.
1.4 Configuring the virtual machine’s storage
Specify the size of the disk space you would like to allocate to the virtual machine.
- I have set the disk image size to 30 GiB, but you may adjust it to meet your needs.
- Select the second option if you want to use a different disk image you created earlier.
Click the Forward button to continue.
1.5 Configure virtual machine name and network type
This is the final configuration screen of the Virtual Machine Creation Wizard.
- Enter the name of the guest virtual machine. It must be unique among all known guests of the hypervisor on the connection, including those not currently active.
- Check this box if you want to make any advanced changes before installing the operating system on the guest. If not, leave it unchecked.
- Select the network type for the guest virtual machine. If you haven’t configured another network, it will be the ‘default’ NAT network. If you’ve set up a network bridge, you can select it here. To configure a network bridge, check the 'Configure a network bridge' section on my other blog.
Click the Finish button to complete the setup wizard and start the installation of the guest operating system.
If you unchecked the option 'Customize configuration before install', you’ve reached the end of this blog. You can now quit reading the rest of the blog. However, if you have checked this option, continue reading.
2. Configuring the advanced options
In this section, I’ll simply go over some of the most important features. Examine these features and, if necessary, implement them; otherwise, discard them.
2.1 Choose the firmware type
Choose what kind of firmware you would like to have on your guest virtual machine.
BIOS: The BIOS mode will be selected by default. This firmware is fully supported by the KVM hypervisor. By selecting this firmware, you will be able to take internal snapshots, which are quite useful when experimenting with something. Unless you have a special need for a UEFI mode, it is strongly advised that you use this firmware.
OVMF_CODE.secboot.fd: Select this option if you want UEFI mode with a secure boot. This type of firmware is not supported by all operating systems. Examine the documentation to ensure that the operating system you’re installing supports this firmware. This firmware does not support internal snapshots, however, it does support external snapshots. At the time of writing, Rocky Linux does not support UEFI with a secure boot, but CentOS and Red Hat Enterprise Linux do.
OVMF_CODE.fd: Select this option if you want UEFI mode without a secure boot. Almost all operating system supports this type of firmware. This firmware also does not support internal snapshots, however, it does support external snapshots.
2.2 Choose a CPU model
In the CPUs section, a number of CPU-related settings can be set.
The KVM comes with a number of standard CPU models. If you need a specific CPU model for your guest virtual machine, you can choose from the list. The CPU models available to you will be determined by the kind of CPU present on your host computer. To view the list, check the image above or type the following command into the terminal.
$ virsh domcapabilities --arch $(uname -m) | grep "model usable='yes'"Alternatively, you can set the CPU type by specifying the mode. Type the following command to check what modes are available to you.
$ virsh domcapabilities --arch $(uname -m) | grep 'mode name'Copy host CPU configuration (Host Model): In this mode, a CPU model similar to the host CPU is automatically selected from the "CPU model" list. Then, to get as close as possible to the host CPU, extra features are added. This will not match the host CPU exactly as "host-passthrough" would, but it will provide many of the benefits of pass-through while also making live migration safe.
Host Passthrough: In this mode, the host CPU features are passed on to the guest virtual machine exactly. This is the recommended CPU to use. The disadvantage is that live migration to other hosts with different hardware is not possible.
2.3 Configure Storage
Disk bus: This option defines what kind of storage controller the guest virtual machine should have. KVM supplies multiple virtual storage controllers, such as 'SATA', 'SCSI', 'USB', and 'VirtIO'. The recommended option is VirtIO, which is also the default.
If you are creating a Microsoft Windows VM, you cannot use the VirtIO bus as Microsoft does not recognize it. To make the VirtIO drivers available to Windows guests, you must first download the virtio-win.iso image. Have a look at the section 'Install virtIO drivers for Windows guests' in my other blog post for more details.
Cache mode: KVM provides multiple storage caching strategies when configuring a guest VM. Each guest disk interface can have one of the following cache modes.
Source: Disk cache modes
- None: Recommended. The host page cache is bypassed and I/O happens directly between the hypervisor user space buffers and the storage device. Because the actual storage device may report a write as completed when placed in its write queue only, the guest's virtual storage adapter is informed that there is a writeback cache. The guest would be expected to send down flush commands as needed to manage data integrity. Performance-wise, it is equivalent to direct access to your host's disk.
- Writethrough: Writes are reported as completed only when the data has been committed to the storage device. The host page cache is used in what can be termed a writethrough caching mode. The guest's virtual storage adapter is informed that there is no writeback cache, so the guest would not need to send down flush commands to manage data integrity. The storage behaves as if there is a writethrough cache.
- Writeback: The host page cache is used and writes are reported to the guest as completed when they are placed in the host page cache. The normal page cache management will handle commitment to the storage device. Additionally, the guest's virtual storage adapter is informed of the writeback cache, so the guest would be expected to send down flush commands as needed to manage data integrity.
- Directsync: Writes are reported as completed only when the data has been committed to the storage device, and when it is also desirable to bypass the host page cache. Like writethrough, it is helpful to guests that do not send flushes when needed. It was the last cache mode added, completing the possible combinations of caching and direct access semantics.
- Unsafe: The key aspect of this “unsafe” mode, is that all flush commands from the guests are ignored. Using this mode implies that the user has accepted the trade-off of performance over risk of data loss in case of a host failure. Useful, for example, during guest installation, but not for production workloads.
Discard mode: There are two different modes here - ignore and unmap. When you delete files in the guest VM, the changes are immediately reflected in the guest file system. However, the qcow2 disk image associated with the VM does not shrink to reflect the newly freed space. With the unmap option selected, you can reclaim that free space.
In the host, enter the following command to reclaim the free space (while the guest is running).
$ virsh domfstrim <guest name> --minimum 0Detect zeroes: Optional. The value can be "off", "on" or "unmap". The first two values turn the detect zero write request to off or on, respectively. The third value "unmap" turns the detection on and additionally tries to discard such areas from the image based on the value of discard above (it will act as "on" if discard is set to "ignore").
2.4 Setup Video
You can choose which video device model will be attached to the guest here. Valid video settings vary depending on the hypervisor, however, some recent KVM choices include cirrus, vga, qxl, virtio, or vmvga (vmware).
The default is QXL. When using QXL as a video, I've noticed that it sometimes fails to display the LUKS passphrase screen when the guest VM boots. So I recommend using VirtIO for video. Visit this page for further information on which video model is most suited to your needs.
If you want the guest VM screen to have a certain resolution, add this line to the Video section's XML tab.
<resolution x="1280" y="720"/>
I'm using 1280x720 as an example, but you may change the screen size to suit your needs.
When you're finished, click the Begin Installation button in the upper left corner of the window to begin the guest operating system installation.
Follow the standard installation procedure of the guest operating system and you have successfully finished the installation of a guest virtual machine using the Virtual Machine Manager (virt-manager).
