From bb66b8d11bd5881147c3b4198a900fd487e67a13 Mon Sep 17 00:00:00 2001 From: Jerry James Date: Mar 20 2024 22:43:59 +0000 Subject: Update docs/modules/ROOT/pages/virtualization/installation.adoc Typo and grammar fixes. - Use `grep -E` instead of `egrep` to avoid obsolescence warnings --- diff --git a/docs/modules/ROOT/pages/virtualization/installation.adoc b/docs/modules/ROOT/pages/virtualization/installation.adoc index 799d8f8..c52d809 100644 --- a/docs/modules/ROOT/pages/virtualization/installation.adoc +++ b/docs/modules/ROOT/pages/virtualization/installation.adoc @@ -13,7 +13,7 @@ Fredrik Arneving; Peter Boy; Jan Kuparinen [abstract] -Qemu-kvm in combination with Libvirt management toolkit is the standard virtualization methodology in Fedora. This optionally includes a local virtual network that you may use for protected communication between the virtual guest systems with each other and with the host. Its default configuration enables also natted access to the public network, specifically usful for virtual machines or containers without its own direct access to the public interface. +Qemu-kvm in combination with Libvirt management toolkit is the standard virtualization methodology in Fedora. This optionally includes a local virtual network that you may use for protected communication between the virtual guest systems and between the guests and the host. Its default configuration enables access to the public network via NAT, which is useful for virtual machines or containers without direct access to the public network interface. == Preparation @@ -23,13 +23,13 @@ Qemu-kvm in combination with Libvirt management toolkit is the standard virtuali QEMU / KVM require hardware virtualization support. The first thing to do is to make sure that it is available. [source,bash] ---- -[…]# egrep --color 'vmx|svm' /proc/cpuinfo +[…]# grep -E --color 'vmx|svm' /proc/cpuinfo ---- The command will return one line per cpu core if virtualization is enabled. If not, you should first check in the BIOS whether virtualization is disabled. === Storage set up -Libvirt stores its data including the image files of the virtual hard disk(s) for the guest systems in /var/lib/libvirt. If you adhere to the default partitioning concept, the libvirt application data is stored in its own logical volume that you have to create in advance. You need to specify the size of the storage area, a unique name, and the accommodating VG (fedora_fedora in case of default partitioning). In the new logical volume, create an xfs file system and mount at /var/lib/libvirt. +Libvirt stores its data including the image files of the virtual hard disk(s) for the guest systems in /var/lib/libvirt. If you adhere to the default partitioning layout, the libvirt application data is stored in its own logical volume that you have to create in advance. You need to specify the size of the storage area, a unique name, and the accommodating VG (fedora_fedora in case of default partitioning). In the new logical volume, create an xfs file system and mount it at /var/lib/libvirt. ==== Cockpit @@ -50,7 +50,7 @@ After completion, the file system is immediately available and is also permanent ==== Command line -Some administrators may prefer the command line for easy scripting. Create a Logical Volume of appropriate size, 50 GiB in thies esample, either in the system Volume Group (named fedora by default) or in the user data VG if created during installation. Adjust size and VG name as required. +Some administrators may prefer the command line for easy scripting. Create a Logical Volume of appropriate size, 50 GiB in this esample, either in the system Volume Group (named fedora by default) or in the user data VG if created during installation. Adjust size and VG name as required. [source,] ---- […]# lvcreate -L 50G -n libvirt fedora @@ -70,9 +70,9 @@ Installing the software is quite simple. ---- […]# dnf install qemu-kvm-core libvirt virt-install cockpit-machines guestfs-tools ---- -Check to really install `guestfs-tools`, not `libguestfs-tools` (unless you need additional windows guests related software). The package `guestfs-tools` provides a basic set of various useful tools to maintain virtual disks. Additional packages provide support for specific use cases, e.g. various file systems or forensic support. Use `dnf search guestfs` to get a list of available packages. +Be sure to install `guestfs-tools`, not `libguestfs-tools` (unless you need additional windows guest related software). The package `guestfs-tools` provides a basic set of various useful tools to maintain virtual disks. Additional packages provide support for specific use cases, e.g. various file systems or forensic support. Use `dnf search guestfs` to get a list of available packages. -Do never install the group `@virtualization` onto a Fedora Server. It includes various graphical programs and libraries that are not usable on headless servers. +Do not install the group `@virtualization` onto a Fedora Server. It includes various graphical programs and libraries that are not usable on headless servers. Next check the SELinux labels [source,bash] @@ -80,14 +80,14 @@ Next check the SELinux labels […]# ls -alZ /var/lib/libvirt ---- -Usually, the installation adjusts the SELinux labels accordingly. Otherwise, adjustment it manually. +Usually, installation sets the SELinux labels properly. Otherwise, set them manually. [source,bash] ---- […]# restorecon -R -vF /var/lib/libvirt ---- If everything is correct, the next step is to activate autostart after re-boot and start KVM and libvirtd. -With Fedora 35 libvirt switched to a _modular archtecture_ (since version 7.6.0-3) while used a single monolithic libvirt daemon up to Fedora 34 (version 7.0.0-x). The installation procedure is the same because the packaging system takes care of the differences. But activation and start up differs as well as installation and configuration of an internal protected virtual network between VMs und host and VMs. +With Fedora 35 libvirt switched to a _modular archtecture_ (since version 7.6.0-3) while used a single monolithic libvirt daemon up to Fedora 34 (version 7.0.0-x). The installation procedure is the same because the packaging system takes care of the differences. But activation and start up differs as well as installation and configuration of an internal protected virtual network between VMs and the host. === Activation and startup with Fedora 34 @@ -97,7 +97,7 @@ Enable automatic startup at boot and start libvirt. […]# systemctl enable libvirtd --now ---- -By default, libvirt creates a (virtual) bridge with an interface virbr0, the IP 192.168.122.1 and the libvirt-internal name default. In addition, a separate firewall zone libvirt is set up and assigned to the internal interface. Check if everything is running as expected. +By default, libvirt creates a (virtual) bridge with an interface virbr0, the IP 192.168.122.1 and the libvirt-internal name as default. In addition, a separate firewall zone libvirt is set up and assigned to the internal interface. Check if everything is running as expected. [source,bash] ---- […]# ip a @@ -106,18 +106,18 @@ By default, libvirt creates a (virtual) bridge with an interface virbr0, the IP === Activation and startup with Fedora 35 and up -The libvirt Fedora installation procedure provides systemd startup scripts that take care of enabling and starting the various unix sockets and services as needed. This includes support for qemu, xen and lxc. Configuration of vbox is disabled by default. The drivers determine during startup whether the required prerequisites are met and abort otherwise. The default services, in case of Fedora Server qemu and lxc, are started at boot time. If not used for about one minute they are deactivated, but will restart on demand as soon as a virtual machine gets started (either by command line or Cockpit service). No need for administrator intervention at all. +The libvirt Fedora installation procedure provides systemd startup scripts that take care of enabling and starting the various unix sockets and services as needed. This includes support for qemu, xen and lxc. Configuration of vbox is disabled by default. The drivers determine during startup whether the required prerequisites are met and abort otherwise. The default services, qemu and lxc in case of Fedora Server, are started at boot time. If not used for about one minute they are deactivated, but will restart on demand as soon as a virtual machine is started (either by command line or Cockpit service). There is no need for administrator intervention at all. -The network configuration is slightly different. The services don't start at boot time, like qemu, lxc, etc., but on demand at first access. Therefore, you won't get an interface virbr0 until any libvirt servive request it. That's sometimes inconvenient, e.g. if you use that interface for non-libvirt services, too (e.g. lxd or nspawn container).You may prefer to enable virt-network service anyway: +The network configuration is slightly different. The services don't start at boot time, like qemu, lxc, etc., but on demand at first access. Therefore, you won't get an interface virbr0 until some libvirt service requests it. That's sometimes inconvenient, e.g. if you use that interface for non-libvirt services, too (e.g. lxd or nspawn container). You may prefer to enable the virt-network service anyway: 1. Optionally, if you are planning to use the virtual network independently from starting virtual machines or you need the virbr0 interface at boot time anyway, enable libvirt's internal network. Otherwise you may skip this step. + [source,bash] ---- -[…]# systemctl enable virtnetworkd.service --now +[…]# systemctl enable virtnetworkd.service --now ---- + -Alternatively, you may want do completly discard libvirt's internal network. You'll take this path, if you set up an internal network with NetworkManager tools, +Alternatively, you may want to completely discard libvirt's internal network. You'll take this path if you set up an internal network with NetworkManager tools. + [source,bash] ---- @@ -126,7 +126,7 @@ Alternatively, you may want do completly discard libvirt's internal network. You 2. Reboot the system to activate and test the virtualization functionality -3. Check the successful start via a status query +3. Check successful start via a status query + [source,bash] ---- @@ -158,7 +158,7 @@ The virtualization services virtqemud.service, etc will be dormant it no VM has The default configuration of the internal network (virbr0) activates just a DHCP Server. If the virtual machines should also be able to communicate with each other and the host, then adding a DNS server is at least very advantageous. It is easier and less error-prone to address VMs and the host by name instead of IP numbers. -The first step is to decide about a domain name. A top-level ".local" is explicitly not recommended, nor taking one of the official top-level names. But for example, you can take the official domain name and replace the last, top-level part with 'lan' or 'internal' of `localnet`. An official domain example.com would translate to an internal domain example.lan. We use that one throughout this tutorial. The host gets the internal name host.example.lan. +The first step is to choose a domain name. A top-level ".local" is explicitly not recommended, nor taking one of the official top-level names. But for example, you can take the official domain name and replace the last, top-level part with 'lan' or 'internal' or `localnet`. An official domain example.com would translate to an internal domain example.lan. We use that one throughout this tutorial. The host gets the internal name host.example.lan. Use the libvirt tool to adjust the default network. Replace names and placeholders as required. Delete the line with "forward mode = 'nat'" if you do not want to allow access to the public network via the virtual network. [source,xml] @@ -203,14 +203,14 @@ Check if the DNS resolution works. == Adjusting the hosts DNS resolution configuration -In order for the host to initiate communication with its virtual machines, it must query the name server set up in the previous step for internal domains. So we need Split DNS. The default systemd-resolved DNS client in Fedora is basically split-DNS capable. Unfortunately it currently doesn't cooperate well with libvirt's virtual network and needs additional administrative efforts.. and its usage is quite unstable. Therefore we recommend to switch to dnsmasq for the time being to provide stable split DNS. +In order for the host to initiate communication with its virtual machines, it must query the name server set up in the previous step for internal domains. So we need Split DNS. The default systemd-resolved DNS client in Fedora is basically split-DNS capable. Unfortunately it currently doesn't cooperate well with libvirt's virtual network and needs additional administrative efforts.. and its usage is quite unstable. Therefore we recommend switching to dnsmasq for the time being to provide stable split DNS. [WARNING] ==== The following procedure doesn't work for Fedora 35-39. Don't use it with these releases. Switch to dnsmasq for the time being as described in the next chapter instead. ==== -1. The name resolver service _systemd-resolved_ introduced with Fedora 33 can do this automatically. But libvirt handles its interfaces on its own and must therefore inform systemd-resolved about it. A script in a hook provided by libvirt can take care of this. You have to adjust the local domain name (as of ${example.lan} in the script below) accordingly! +1. The name resolver service _systemd-resolved_ introduced with Fedora 33 can do this automatically. But libvirt handles its interfaces on its own and must therefore inform systemd-resolved about it. A script in a hook provided by libvirt can take care of this. You have to adjust the local domain name (${example.lan} in the script below) accordingly! + [source,] ---- @@ -263,7 +263,7 @@ fi […]# chmod +x /etc/libvirt/hooks/network.d/40-config-resolved.sh ---- -2. Check, if /etc/resolv.conf is a link and not a file. +2. Check if /etc/resolv.conf is a link and not a file. Activate modified local DNS resolving + [source,bash] @@ -289,7 +289,7 @@ In case it is a file, fix it: P1: default - P2: started - P3: begin @ Mon Mar ... ---- -4. It is useful to modify the host's search path resolve a short single hostname to the internal network. +4. It is useful to modify the host's search path to resolve a short single hostname to the internal network. + [source,bash] ---- @@ -310,7 +310,7 @@ Everything should work fine now. == Switch to NetworkManager's dnsmasq plugin -The NetworkManager Dnsmasq plugin is an easy way to add a local caching DNS server which is split DNS enabled. It provides the host with a lightweight, capable DNS server as an alternative to use system-resolved. By default it forwards all queries to an external, 'official' DNS server. We just have to configure the local libvirt domain. +The NetworkManager Dnsmasq plugin is an easy way to add a local caching DNS server which is split DNS enabled. It provides the host with a lightweight, capable DNS server as an alternative to using systemd-resolve. By default it forwards all queries to an external, 'official' DNS server. We just have to configure the local libvirt domain. Activate dnsmasq plugin @@ -363,7 +363,7 @@ Check the functionality of name resolution with internal and external addresses. == Finishing Cockpit-machines configuration -Open your browser and connect to the Cockpit instance of your host server. Consult the xref:installation/postinstallation-tasks.adoc[post-installation guide] to find out the possible connection paths. Log in as root or with your administrative account. In the overview (start) page select `__Virtual Machines__` in the left navigation column. +Open your browser and connect to the Cockpit instance of your host server. Consult the xref:installation/postinstallation-tasks.adoc[post-installation guide] to learn about the possible connection paths. Log in as root or with your administrative account. In the overview (start) page select `__Virtual Machines__` in the left navigation column. If there is no entry `__Virtual Machines__` in the navigation column, the cockpit-machines module was left off in the installation step above. Select `__Applications__` further down and then `__Machines__` for installation. @@ -380,7 +380,7 @@ When first used, the list of virtual machines displayed in the center of the pag Typically you use one Pool for installation media, stored at /var/lib/libvirt/boot. "Installation media" would be a suitable descriptive pool name. Select 0 Storage pools in the box and then Create storage pool. A new form opens. -If you are logged in as an adminstrative user (even if having used sudo su - ), you are asked to select a connection type, "system" or "session". This selection is presented in various configuration forms, so some explanation here. Use "system" for a production deployments, what you do in most cases. Select "sesssion" in the special case of testing, development, and experimentation. The "session" option does not support any custom or advanced networking, but works pretty much everwhere (including containers) and without any privileges. The libvirt project provides additional information for developers. If you are logged in directly as root, this line doesn’t show up. Instead, everything is treated as system. i.e. production deployment (never do development or experimentation as root). +If you are logged in as an adminstrative user (even if having used sudo su - ), you are asked to select a connection type, "system" or "session". This selection is presented in various configuration forms, so we explain here. Use "system" for production deployments, the common case. Select "session" in the special case of testing, development, and experimentation. The "session" option does not support any custom or advanced networking, but works pretty much everwhere (including containers) and without any privileges. The libvirt project provides additional information for developers. If you are logged in directly as root, this line doesn’t show up. Instead, everything is treated as system; i.e. production deployment (never do development or experimentation as root). Next enter "Installation media" as the name, "Filesystem directory" as the type, and /var/lib/libvirt/boot as the target path. @@ -388,11 +388,11 @@ In most cases, the (virtual) hard disk used for a virtual machine is a disk imag Activate both pools in the drop down menu of each pool. -You may create additional pools as needed, e.g. disk images via iSCSI in a SAN or as a logical volume in a volume group (LVM) on the host’s local disk. The latter offers a better performance in theory, but the practical gain is usually rather small, if any. We will not go into further detail here for the time being. +You may create additional pools as needed, e.g. disk images via iSCSI in a SAN or as a logical volume in a volume group (LVM) on the host’s local disk. The latter offers better performance in theory, but the practical gain is usually rather small, if any. We will not go into further detail here for the time being. === Networks -A box on the right above the virtual machines list shows `__1 Network__` and lists the networks managed by libvirt. By default, it contains the internal network _default_ with the interface __virbr0__. The list does not contain the external interface. It is managed by the server. Nevertheless, it is as well available for virtual machines. +A box on the right above the virtual machines list shows `__1 Network__` and lists the networks managed by libvirt. By default, it contains the internal network _default_ with the interface __virbr0__. The list does not contain the external interface. It is managed by the server. Nevertheless, it is available for virtual machines. == Completed Virtualization is now ready to use on the server and you can start setting up guest VMs.