Configuring and managing Linux virtual machines

• Safely test software configurations and features
• Run legacy software
• Optimize the workload efficiency of your hardware.

• Flexible and fine-grained allocation of resources

  A VM runs on a host machine, which is usually physical, and physical hardware can also be assigned for the guest OS to use. However, the allocation of physical resources to the VM is done on the software level, and is therefore very flexible. A VM uses a configurable fraction of the host memory, CPUs, or storage space, and that configuration can specify very fine-grained resource requests.

  For example, what the guest OS sees as its disk can be represented as a file on the host file system, and the size of that disk is less constrained than the available sizes for physical disks.

• Software-controlled configurations

  The entire configuration of a VM is saved as data on the host, and is under software control. Therefore, a VM can easily be created, removed, cloned, migrated, operated remotely, or connected to remote storage.

  In addition, the current state of the VM can be backed up as a snapshot at any time. A snapshot can then be loaded to restore the system to the saved state.

• Separation from the host

  A guest OS runs on a virtualized kernel, separate from the host OS. This means that any OS can be installed on a VM, and even if the guest OS becomes unstable or is compromised, the host is not affected in any way.

• Space and cost efficiency

  A single physical machine can host a large number of VMs. Therefore, it avoids the need for multiple physical machines to do the same tasks, and thus lowers the space, power, and maintenance requirements associated with physical hardware.

• Software compatibility

  Because a VM can use a different OS than its host, virtualization makes it possible to run applications that were not originally released for your host OS. For example, using a RHEL 8 guest OS, you can run applications released for RHEL 8 on a RHEL 10 host system.

• Metadata, such as the name of the VM, time zone, and other information about the VM.
• A description of the devices in the VM, including virtual CPUs (vCPUS), storage devices, input/output devices, network interface cards, and other hardware, real and virtual.
• VM settings, such as the maximum amount of memory it can use, restart settings, and other settings about the behavior of the VM.

• virsh - A versatile virtualization command-line utility and shell with a great variety of purposes, depending on the provided arguments. For example:

  • Starting and shutting down a VM - virsh start and virsh shutdown
  • Listing available VMs - virsh list
  • Creating a VM from a configuration file - virsh create
  • Entering a virtualization shell - virsh

  For more information, see the virsh(1) man page on your system.

• virt-install - A CLI utility for creating new VMs. For more information, see the virt-install(1) man page on your system.
• virt-xml - A utility for editing the configuration of a VM.
• guestfish - A utility for examining and modifying VM disk images. For more information, see the guestfish(1) man page on your system.

• To manage virtualization in RHEL 10 in a GUI, you can use the RHEL 10 web console, also known as Cockpit. The web console provides a remotely accessible and easy-to-use GUI for managing VMs and virtualization hosts.

• Advanced networking - You cannot set up system bridges or tap devices. You are limited to user-mode (passt) networking, and cannot configure full external visibility of the VM.
• PCI device passthrough - Modifying the device assignment of PCI host hardware for the VM is not possible.
• Autostart - VMs in the session connection cannot automatically start on system boot.
• System-level storage pools and VM logs - In the system connection, storage pools and VM log files are saved in system directories, such as /etc/libvirt and /var/lib/libvirt. In the session connection, the user is limited to files saved in their home directory. This prevents managing host-wide storage or viewing logs centrally.

Prerequisites

• Red Hat Enterprise Linux 10 is installed and registered on your host machine. For instructions, see the RHEL installation guide.

• The following minimum system resources are available:

  • 6 GB free disk space for the host, plus another 6 GB for each intended VM.
  • 2 GB of RAM for the host, plus another 2 GB for each intended VM.

Troubleshooting

• If KVM virtualization is not supported by your host CPU, virt-host-validate generates the following output:

  QEMU: Checking for hardware virtualization: FAIL (Only emulated CPUs are available, performance will be significantly limited)

  However, VMs on such a host system will fail to boot, rather than have performance problems.

  To work around this, you can change the <domain type> value in the XML configuration of the VM to qemu. Note, however, that Red Hat does not support VMs that use the qemu domain type, and setting this is highly discouraged in production environments.

Prerequisites

• Red Hat Enterprise Linux 10 is installed and registered on your host machine. For instructions, see the RHEL installation guide.

• The following minimum system resources are available:

  • 6 GB free disk space for the host, plus another 6 GB for each intended VM.
  • 2 GB of RAM for the host, plus another 2 GB for each intended VM.
  • 4 CPUs on the host. VMs can generally run with a single assigned vCPU, but Red Hat recommends assigning 2 or more vCPUs per VM to avoid VMs becoming unresponsive during high load.
• Your IBM Z host system is using an IBM z14 CPU or later.

• RHEL 10 is installed on a logical partition (LPAR). In addition, the LPAR supports the start-interpretive execution (SIE) virtualization functions.

  To verify this, search for sie in your /proc/cpuinfo file.

  # grep sie /proc/cpuinfo
  features        : esan3 zarch stfle msa ldisp eimm dfp edat etf3eh highgprs te sie

Troubleshooting

• If KVM virtualization is not supported by your host CPU, virt-host-validate generates the following output:

  QEMU: Checking for hardware virtualization: FAIL (Only emulated CPUs are available, performance will be significantly limited)

  However, VMs on such a host system will fail to boot, rather than have performance problems.

  To work around this, you can change the <domain type> value in the XML configuration of the VM to qemu. Note, however, that Red Hat does not support VMs that use the qemu domain type, and setting this is highly discouraged in production environments.

Prerequisites

• Red Hat Enterprise Linux 10 is installed and registered on your host machine. For instructions, see the RHEL installation guide.

• The following minimum system resources are available:

  • 6 GB free disk space for the host, plus another 6 GB for each intended guest.
  • 4 GB of RAM for the host, plus another 4 GB for each intended guest.

Prerequisites

• You have installed the RHEL 10 web console.

  For instructions, see Installing and enabling the web console.

Procedure

• Install the cockpit-machines plugin.

  # dnf install cockpit-machines

Prerequisites

• Virtualization is enabled on your host system. For instructions, see Preparing RHEL to host virtual machines.

Prerequisites

• Virtualization is enabled on your host system. For instructions, see Preparing RHEL to host virtual machines.
• You have a sufficient amount of system resources to allocate to your VMs, such as disk space, RAM, or CPUs. The recommended values might vary significantly depending on the intended tasks and workload of the VMs.

• An operating system (OS) installation source is available locally or on a network. This can be one of the following:

  • An ISO image of an installation medium

  • A disk image of an existing VM installation

    Warning

    Installing from a host CD-ROM or DVD-ROM device is not possible in RHEL 10. If you select a CD-ROM or DVD-ROM as the installation source when using any VM installation method available in RHEL 10, the installation will fail. For more information, see the Red Hat Knowledgebase.

    Also note that Red Hat provides support only for a limited set of guest operating systems.

• To create a VM that uses the system connection of libvirt, you must have root privileges or be in the libvirt user group on the host. For more information, see User-space connection types for virtualization.
• Optional: A Kickstart file can be provided for faster and easier configuration of the installation.

Procedure

• To create a VM and start its OS installation, use the virt-install command, along with the following mandatory arguments:

  --name

  the name of the new machine

  --memory

  the amount of allocated memory

  --vcpus

  the number of allocated virtual CPUs

  --disk

  the type and size of the allocated storage

  --cdrom or --location

  the type and location of the OS installation source

  --osinfo

  the OS type and version that you intend to install

  Note

  To list all available values for the --osinfo argument, run the virt-install --osinfo list command.

  For more details, you can also run the osinfo-query os command. However, you might need to install the libosinfo-bin package first.

  Based on the chosen installation method, the necessary options and values can vary. See the following examples for more details.

• Create a VM and install an OS from a local ISO file:

  • The following command creates a VM named demo-guest1 that installs the Windows 10 OS from an ISO image locally stored in the /home/username/Downloads/Win10install.iso file. This VM is also allocated with 2048 MiB of RAM and 2 vCPUs, and an 80 GiB qcow2 virtual disk is automatically configured for the VM.

    # virt-install \
        --name demo-guest1 --memory 2048 \
        --vcpus 2 --disk size=80 --osinfo win10 \
        --cdrom /home/username/Downloads/Win10install.iso

• Create a VM, install an OS from a live CD, and do not create a permanent disk:

  • The following command creates a VM named demo-guest2 that uses the /home/username/Downloads/rhel10.iso image to run a RHEL 10 OS from a live CD. No disk space is assigned to this VM, so changes made during the session will not be preserved. In addition, the VM is allocated with 4096 MiB of RAM and 4 vCPUs.

    # virt-install \
        --name demo-guest2 --memory 4096 --vcpus 4 \
        --disk none --livecd --osinfo rhel10.0 \
        --cdrom /home/username/Downloads/rhel10.iso

• Create a VM and import an existing disk image:

  • The following command creates a RHEL 10 VM named demo-guest3 that connects to an existing disk image, /home/username/backup/disk.qcow2. This is similar to physically moving a hard drive between machines, so the OS and data available to demo-guest3 are determined by how the image was handled previously. In addition, this VM is allocated with 2048 MiB of RAM and 2 vCPUs.

    # virt-install \
        --name demo-guest3 --memory 2048 --vcpus 2 \
        --osinfo rhel10.0 --import \
        --disk /home/username/backup/disk.qcow2

    Note that you must use the --osinfo option when importing a disk image. If it is not provided, the performance of the created VM will be negatively affected.

• Create a VM and install an OS from a remote URL:

  • The following command creates a VM named demo-guest4 that installs from the http://example.com/OS-install URL. For the installation to start successfully, the URL must contain a working OS installation tree. In addition, the OS is automatically configured by using the /home/username/ks.cfg kickstart file. This VM is also allocated with 2048 MiB of RAM, 2 vCPUs, and a 160 GiB qcow2 virtual disk.

    # virt-install \
        --name demo-guest4 --memory 2048 --vcpus 2 --disk size=160 \
        --osinfo rhel10.0 --location http://example.com/OS-install \
        --initrd-inject /home/username/ks.cfg --extra-args="inst.ks=file:/ks.cfg console=tty0 console=ttyS0,115200n8"

    In addition, if you want to host demo-guest4 on an RHEL 10 on an ARM 64 host, include the following lines to ensure that the kickstart file installs the kernel-64k package:

    %packages
    -kernel
    kernel-64k
    %end

• Create a VM and install an OS in a text-only mode:

  • The following command creates a VM named demo-guest5 that installs from a RHEL10.iso image file in text-only mode, without graphics. It connects the guest console to the serial console. The VM has 16384 MiB of memory, 16 vCPUs, and 280 GiB disk. This kind of installation is useful when connecting to a host over a slow network link.

    # virt-install \
        --name demo-guest5 --memory 16384 --vcpus 16 --disk size=280 \
        --osinfo rhel10.0 --location RHEL10.iso \
        --graphics none --extra-args='console=ttyS0'

• Create a VM and install an OS in graphical mode:

  • The following command creates a VM named demo-guest-6, which has the same configuration as demo-guest5, but provides the host device pci_0003_00_00_0 for networking and configures graphics for a graphical installation.

    # virt-install \
        --name demo-guest6 --memory 16384 --vcpus 16 --disk size=280 \
        --os-info rhel10.0 --location RHEL10.iso --graphics vnc,listen=0.0.0.0,5901 \
        --input keyboard,bus=virtio --input mouse,bus=virtio \
        --hostdev pci_0003_00_00_0 --network none

    Note that the name of the host device available for installation can be retrieved by using the virsh nodedev-list --cap pci command. To use the installation GUI, you can connect any VNC viewer to the host’s IP at VNC port 5901 when the installation starts. However, you might have to open this port in the firewall first, for example:

    # firewall-cmd --add-port 5901/tcp

• Create a VM on a remote host:

  • The following command creates a VM named demo-guest7, which has the same configuration as demo-guest5, but resides on the 192.0.2.1 remote host.

    # virt-install \
        --connect qemu+ssh://root@192.0.2.1/system --name demo-guest7 --memory 16384 \
        --vcpus 16 --disk size=280 --osinfo rhel10.0 --location RHEL10.iso \
        --graphics none --extra-args='console=ttyS0'

• Create a VM on a remote host and use a DASD mediated device as storage:

  • The following command creates a VM named demo-guest-8, which has the same configuration as demo-guest5, but for its storage, it uses a DASD mediated device mdev_30820a6f_b1a5_4503_91ca_0c10ba12345a_0_0_29a8, and assigns it device number 1111.

    # virt-install \
        --name demo-guest8 --memory 16384 --vcpus 16 --disk size=280 \
        --osinfo rhel10.0 --location RHEL10.iso --graphics none \
        --disk none --hostdev mdev_30820a6f_b1a5_4503_91ca_0c10ba12345a_0_0_29a8,address.type=ccw,address.cssid=0xfe,address.ssid=0x0,address.devno=0x1111,boot-order=1 \
        --extra-args 'rd.dasd=0.0.1111'

    Note that the name of the mediated device available for installation can be retrieved by using the virsh nodedev-list --cap mdev command.

• For additional options and examples of virt-install commands, see the virt-install (1) man page on your system.

Verification

• If the VM is created successfully, a virt-viewer window opens with a graphical console of the VM and starts the guest OS installation.

Troubleshooting

• If virt-install fails with a cannot find default network error:

  • Ensure that the libvirt-daemon-config-network package is installed:

    # dnf info libvirt-daemon-config-network
    Installed Packages
    Name         : libvirt-daemon-config-network
    [...]

  • Verify that the libvirt default network is active and configured to start automatically:

    # virsh net-list --all
     Name      State    Autostart   Persistent
    --------------------------------------------
     default   active   yes         yes

  • If it is not, activate the default network and set it to auto-start:

    # virsh net-autostart default
    Network default marked as autostarted
    
    # virsh net-start default
    Network default started

    • If activating the default network fails with the following error, the libvirt-daemon-config-network package has not been installed correctly.

      error: failed to get network 'default'
      error: Network not found: no network with matching name 'default'

      To fix this, re-install libvirt-daemon-config-network:

      # dnf reinstall libvirt-daemon-config-network

    • If activating the default network fails with an error similar to the following, a conflict has occurred between the default network’s subnet and an existing interface on the host.

      error: Failed to start network default
      error: internal error: Network is already in use by interface ens2

      To fix this, use the virsh net-edit default command and change the 192.0.2.* values in the configuration to a subnet not already in use on the host.

Prerequisites

• You have created a VM and installed a guest operating system. For details, see Creating virtual machines.
• The VM is defined and inactive.
• You know the name of the VM.

• For remote VMs:

  • You have the IP address of the host where the VM is located.
  • You have root access privileges to the host.
• If the VM uses a system connection of libvirt, you have root privileges or belong to the libvirt user group on the host. For details, see User-space connection types for virtualization.

Procedure

• For a local VM, use the virsh start utility.

  For example, the following command starts the demo-guest1 VM.

  # virsh start demo-guest1
  Domain 'demo-guest1' started

• For a VM located on a remote host, use the virsh start utility along with the QEMU+SSH connection to the host.

  For example, the following command starts the demo-guest1 VM on the 192.0.2.1 host.

  # virsh -c qemu+ssh://root@192.0.2.1/system start demo-guest1
  
  root@192.0.2.1's password:
  
  Domain 'demo-guest1' started

Prerequisites

• You have installed the RHEL 10 web console.

  For instructions, see Installing and enabling the web console.

• You have created a VM and installed a guest operating system. For details, see Creating virtual machines.
• The VM is defined and currently inactive.
• You know the name of the VM.
• The web console VM plug-in is installed on your system. For details, see Setting up the web console to manage virtual machines.
• If the VM uses a system connection of libvirt, you have root privileges or belong to the libvirt user group on the host. For details, see User-space connection types for virtualization.

Prerequisites

• You have created a virtual machine (VM) and installed a guest operating system. For details, see Creating virtual machines.

Prerequisites

• Your system and the VM that you are connecting to must support graphical displays.
• If the target VM is located on a remote host, you must have connection and root access privileges to the host.
• Optional: If the target VM is located on a remote host, it is helpful to set up libvirt and SSH for more convenient access to remote hosts. For instructions, see Setting up easier access to remote virtualization hosts.
• The VMs that you want to interact with are installed and started. For instructions, see Creating virtual machines and Starting virtual machines.

Procedure

• To connect to a local VM, use the following command and replace guest-name with the name of the VM you want to connect to:

  # virt-viewer guest-name

• To connect to a remote VM, use the virt-viewer command with the SSH protocol. For example, the following command connects as root to a VM called guest-name, located on remote system 192.0.2.1. The connection also requires root authentication for 192.0.2.1.

  # virt-viewer --direct --connect qemu+ssh://root@192.0.2.1/system guest-name

  Successful output:

  root@192.0.2.1's password:

Troubleshooting

• If clicking in the graphical console does not have any effect, expand the console to full screen. This is a known issue with the mouse cursor offset.

Prerequisites

• You have network connection and root access privileges to the target VM.
• If the target VM is located on a remote host, you also have connection and root access privileges to that host.

• Your VM network assigns IP addresses by dnsmasq generated by libvirt. This is the case for example in libvirt NAT networks.

  Notably, if your VM is using one of the following network configurations, you cannot connect to the VM by using SSH:

  • hostdev interfaces
  • Direct interfaces
  • Bridge interfaces

• The libvirt-nss component is installed and enabled on the VM’s host. If it is not, do the following:

  1. Install the libvirt-nss package:

     # dnf install libvirt-nss

  2. Edit the /etc/nsswitch.conf file and add libvirt_guest to the hosts line:

     ...
     passwd:      compat
     shadow:      compat
     group:       compat
     hosts:       files libvirt_guest dns
     ...

• The VMs that you want to interact with are installed and started. For instructions, see Creating virtual machines and Starting virtual machines.

Troubleshooting

• If you do not know the VM’s name, you can list all VMs available on the host by using the virsh list --all command:

  # virsh list --all

  Example output:

  Id    Name                           State
  ----------------------------------------------------
  2     testguest1                    running
  -     testguest2                    shut off

• The VM does not provide VNC protocols, so it does not offer video display for GUI tools.
• The VM does not have a network connection, so it cannot be interacted with by using SSH.

Prerequisites

• The GRUB boot loader on your host must be configured to use serial console. To verify, check that the /etc/default/grub file on your host contains the GRUB_TERMINAL=serial parameter.

  $ sudo grep GRUB_TERMINAL /etc/default/grub
  GRUB_TERMINAL=serial

• The VM must have a serial console device configured, such as console type='pty'. To verify, do the following:

  # virsh dumpxml vm-name | grep console
  
  <console type='pty' tty='/dev/pts/2'>
  </console>

• The VM must have the serial console configured in its kernel command line. To verify this, the cat /proc/cmdline command output on the VM should include console=<console-name>, where <console-name> is architecture-specific:

  • For AMD64 and Intel 64: ttyS0

  • For ARM 64: ttyAMA0

    Note

    The following commands in this procedure use ttyS0.

    # cat /proc/cmdline
    BOOT_IMAGE=/vmlinuz-6.12.0-0.el10_0.x86_64 root=/dev/mapper/rhel-root ro console=tty0 console=ttyS0,9600n8 rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb

    If the serial console is not set up properly on a VM, using virsh console to connect to the VM connects you to an unresponsive guest console. However, you can still exit the unresponsive console by using the Ctrl+] shortcut.

  • To set up serial console on the VM, do the following:

    1. On the VM, enable the console=ttyS0 kernel option:

       # grubby --update-kernel=ALL --args="console=ttyS0"

    2. Clear the kernel options that might prevent your changes from taking effect.

       # grub2-editenv - unset kernelopts

    3. Reboot the VM.

• The serial-getty@<console-name> service must be enabled. For example, on AMD64 and Intel 64:

  # systemctl status serial-getty@ttyS0.service
  
  ○ serial-getty@ttyS0.service - Serial Getty on ttyS0
       Loaded: loaded (/usr/lib/systemd/system/serial-getty@.service; enabled; preset: enabled)

• The VMs that you want to interact with are installed and started. For instructions, see Creating virtual machines and Starting virtual machines.

Prerequisites

• You have an existing VM that is configured to use the SPICE remote display protocol and is already shut-down.
• The VMs that you want to interact with are installed and started. For instructions, see Creating virtual machines and Starting virtual machines.

Procedure

• On the host, run the following command, and replace `<vm-name>` with the name of the VM that you want to convert to VNC.

  # virt-xml <vm-name> --edit --convert-to-vnc

  Successful output:

  Domain 'vm-name' defined successfully

  Important

  This also removes certain SPICE devices from the VM, such as audio and USB passthrough, because they do not have a suitable replacement in the VNC protocol. For more information, see Considerations in adopting RHEL 9.

Verification

• Inspect the configuration of the VM you converted, and make sure the graphics type is listed as vnc.

  # virsh dumpxml -xml <vm-name> | grep "graphics"

  Successful output:

  <graphics type='*vnc*' port='5900' autoport='yes' listen='127.0.0.1'>

Prerequisites

• You have a running VM on your host. For more information, see Starting virtual machines.

Verification

• On the host, display the list of your VMs to see their status.

  # virsh list --all

  Successful output:

   Id    Name                 State
  ------------------------------------------
   1     demo-guest1          shut off

Prerequisites

• You have installed the RHEL 10 web console.

  For instructions, see Installing and enabling the web console.

• The web console VM plug-in is installed on your system.
• You have a running VM on your host. For more information, see Starting virtual machines.

Troubleshooting

• If the VM does not shut down, click the Menu button ⋮ next to the Shut Down button and select Force Shut Down.
• To shut down an unresponsive VM, you can also send a non-maskable interrupt by clicking the Send non-maskable interrupt button in the Menu.

Prerequisites

• You have a running VM on your host. For more information, see Starting virtual machines.

Verification

• On the host, display the list of your VMs to see their status.

  # virsh list --all

  Successful output:

   Id    Name                 State
  ------------------------------------------
   1     demo-guest1          running

Prerequisites

• You have installed the RHEL 10 web console.

  For instructions, see Installing and enabling the web console.

• The web console VM plug-in is installed on your system.
• You have a running VM on your host. For more information, see Starting virtual machines.

Troubleshooting

• If the VM does not restart, click the Menu button ⋮ next to the Reboot button and select Force Reboot.
• To shut down an unresponsive VM, you can also send a non-maskable interrupt by clicking the Send non-maskable interrupt button in the Menu.

Prerequisites

• The VM is shut-down.
• No other VMs use the same associated storage.
• Optional: Important data from the VM have been backed up.

Procedure

• Use the virsh undefine utility:

  For example, the following command removes the guest1 VM, its associated storage volumes, and non-volatile RAM, if any.

  # virsh undefine guest1 --remove-all-storage --nvram
  Domain 'guest1' has been undefined
  Volume 'vda'(/home/images/guest1.qcow2) removed.

Verification

• Ensure that the VM is no longer present on your host:

  # virsh list --all

Prerequisites

• You have installed the RHEL 10 web console.

  For instructions, see Installing and enabling the web console.

• The web console VM plug-in is installed on your system.
• Back up important data from the VM.
• Make sure no other VM uses the same associated storage.
• Optional: Shut down the VM.

Procedure

• To obtain a list of VMs on your host:

  # virsh list --all
  Id   Name              State
  ----------------------------------
  1    testguest1             running
  -    testguest2             shut off
  -    testguest3             shut off
  -    testguest4             shut off

• To obtain basic information about a specific VM:

  # virsh dominfo _testguest1
  Id:             1
  Name:           testguest1
  UUID:           a973666f-2f6e-415a-8949-75a7a98569e1
  OS Type:        hvm
  State:          running
  CPU(s):         2
  CPU time:       188.3s
  Max memory:     4194304 KiB
  Used memory:    4194304 KiB
  Persistent:     yes
  Autostart:      disable
  Managed save:   no
  Security model: selinux
  Security DOI:   0
  Security label: system_u:system_r:svirt_t:s0:c486,c538 (enforcing)

• To obtain the complete XML configuration of a specific VM:

  # virsh dumpxml testguest2
  
  <domain type='kvm' id='1'>
    <name>testguest2</name>
    <uuid>a973434f-2f6e-4ěša-8949-76a7a98569e1</uuid>
    <metadata>
  [...]

  For an annotated example of a VM’s XML configuration, see Sample virtual machine XML configuration

• For information about a VM’s disks and other block devices:

  # virsh domblklist testguest3
   Target   Source
  ---------------------------------------------------------------
   vda      /var/lib/libvirt/images/testguest3.qcow2
   sda      -
   sdb      /home/username/Downloads/virt-p2v-1.36.10-1.el7.iso

  For instructions on managing a VM’s storage, see Managing storage for virtual machines.

• To obtain information about a VM’s file systems and their mountpoints:

  # virsh domfsinfo testguest3
  Mountpoint   Name   Type   Target
  ------------------------------------
   /            dm-0   xfs   vda
   /boot        vda2   xfs   vda
   /boot/efi    vda1   vfat  vda

• To obtain more details about the vCPUs of a specific VM:

  # virsh vcpuinfo testguest4
  VCPU:           0
  CPU:            3
  State:          running
  CPU time:       103.1s
  CPU Affinity:   yyyy
  
  VCPU:           1
  CPU:            0
  State:          running
  CPU time:       88.6s
  CPU Affinity:   yyyy

  To configure and optimize the vCPUs in your VM, see Optimizing virtual machine CPU performance.

• To list all network interfaces of a specific VM:

  # virsh domiflist testguest5
  Interface   Type      Source    Model    MAC
  -------------------------------------------------------------
   vnet0       network   default   virtio   52:54:00:ad:23:fd
   vnet1       bridge    br0       virtio   52:54:00:40:d4:9d

  For details about network interfaces, VM networks, and instructions for configuring them, see Configuring virtual machine network connections.

• For instructions on viewing information about storage pools and storage volumes on your host, see Viewing virtual machine storage information by using the CLI.

Prerequisites

• The web console VM plug-in is installed on your system.

Procedure

• Click Virtual Machines in the web console’s side menu.

  A dialog box appears with information about the available storage pools, available networks, and the VMs to which the web console is connected.

  The information includes the following:

  • Storage Pools - The number of storage pools, active or inactive, that can be accessed by the web console and their state.
  • Networks - The number of networks, active or inactive, that can be accessed by the web console and their state.
  • Name - The name of the VM.
  • Connection - The type of libvirt connection, system or session.
  • State - The state of the VM.
  • Resource usage - Memory and virtual CPU usage of the VM.

  • Disks - Detailed information about disks assigned to the VM.

    Note

    Changes to the virtual network interface settings take effect only after restarting the VM.

    Additionally, MAC address can only be modified when the VM is shut off.

• Unique settings, such as persistent network MAC configuration, which can prevent the clones from working correctly.
• Sensitive data, such as SSH keys and password files.

Prerequisites

• The source VM is shut down.
• Ensure that there is sufficient disk space to store the cloned disk images.
• The virt-install package is installed on the host.
• Optional: When creating multiple VM clones, remove unique data and settings from the source VM to ensure the cloned VMs work properly. For instructions, see Creating virtual machine templates.

Procedure

• Use the virt-clone utility with options that are appropriate for your environment and use case.

  Sample use cases

  • The following command clones a local VM named example-VM-1 and creates the example-VM-1-clone VM. It also creates and allocates the example-VM-1-clone.qcow2 disk image in the same location as the disk image of the original VM, and with the same data:

    # virt-clone --original example-VM-1 --auto-clone
    Allocating 'example-VM-1-clone.qcow2'                            | 50.0 GB  00:05:37
    
    Clone 'example-VM-1-clone' created successfully.

  • The following command clones a VM named example-VM-2, and creates a local VM named example-VM-3, which uses only two out of multiple disks of example-VM-2:

    # virt-clone --original example-VM-2 --name example-VM-3 --file /var/lib/libvirt/images/disk-1-example-VM-2.qcow2 --file /var/lib/libvirt/images/disk-2-example-VM-2.qcow2
    Allocating 'disk-1-example-VM-2.qcow2'                                      | 78.0 GB  00:05:37
    Allocating 'disk-2-example-VM-2.qcow2'                                      | 80.0 GB  00:05:37
    
    Clone 'example-VM-3' created successfully.

  • To clone your VM to a different host, migrate the VM without undefining it on the local host. For example, the following commands clone the previously created example-VM-3 VM to the 192.0.2.1 remote system, including its local disks. Note that you require root privileges to run these commands for 192.0.2.1:

    # virsh migrate --offline --persistent example-VM-3 qemu+ssh://root@192.0.2.1/system
    root@192.0.2.1's password:
    
    # scp /var/lib/libvirt/images/<disk-1-example-VM-2-clone>.qcow2 root@192.0.2.1/<user@remote_host.com>://var/lib/libvirt/images/
    
    # scp /var/lib/libvirt/images/<disk-2-example-VM-2-clone>.qcow2 root@192.0.2.1/<user@remote_host.com>://var/lib/libvirt/images/

    Note

    For additional details and examples of using virt-clone, see the virt-clone (1) man page on your system.

Prerequisites

• You have installed the RHEL 10 web console.

  For instructions, see Installing and enabling the web console.

• The web console VM plug-in is installed on your system.
• Ensure that the VM you want to clone is shut down.

Verification

• Confirm whether the cloned VM is displayed in the list of VMs available on your host.

• Storage located on a shared network
• The --copy-storage-all parameter for the virsh migrate command, which copies disk image contents from the source to the destination over the network.
• Storage area network (SAN) logical units (LUNs).
• Ceph storage clusters

• VMs that use certain features and configurations will not work correctly if migrated, or the migration will fail. Such features include:

  • Device passthrough
  • SR-IOV device assignment (With the exception of migrating a VM with an attached virtual function of a Mellanox networking device, which works correctly.)
  • Mediated devices, such as vGPUs (With the exception of migrating a VM with an attached NVIDIA vGPU, which works correctly.)
• A migration between hosts that use Non-Uniform Memory Access (NUMA) pinning works only if the hosts have similar topology. However, the performance on running workloads might be negatively affected by the migration.
• Both the source and destination hosts use specific RHEL versions that are supported for VM migration, see Supported hosts for virtual machine migration

• The physical CPUs, both on the source VM and the destination VM, must be identical, otherwise the migration might fail. Any differences between the VMs in the following CPU related areas can cause problems with the migration:

  • CPU model

    • Migrating between an Intel 64 host and an AMD64 host is unsupported, even though they share the x86-64 instruction set.
    • For steps to ensure that a VM will work correctly after migrating to a host with a different CPU model, see Verifying host CPU compatibility for virtual machine migration.
  • Physical machine firmware versions and settings
• Migrating VMs between ARM 64 hosts is currently only supported between hosts with identical CPUs, firmware, and memory page size. For more information, see How virtualization on ARM 64 differs from AMD64 and Intel 64.

Procedure

• Offline migration

  • To migrate a shut-off VM, use the virsh migrate --offline command. The following example migrates the shut-off example-VM VM from your local host to the system connection of the example-destination host by using an SSH tunnel.

    # virsh migrate \
       --offline --persistent <example_VM> \
       qemu+ssh://example-destination/system

• Live migration

  1. To migrate a running VM, use the virsh migrate --live command. The following example migrates the live example-VM VM from your local host to the system connection of the example-destination host by using an SSH tunnel.

     # virsh migrate \
        --live --persistent <example_VM> \
        qemu+ssh://example-destination/system

  2. Wait for the migration to complete. The process might take some time depending on network bandwidth, system load, and the size of the VM. If the --verbose option is not used for virsh migrate, the CLI does not display any progress indicators except errors.

     When the migration is in progress, you can use the virsh domjobinfo utility to display the migration statistics.

• Multi-FD live migration

  • You can use multiple parallel connections to the destination host during the live migration. This is also known as multiple file descriptors (multi-FD) migration. With multi-FD migration, you can speed up the migration by using all of the available network bandwidth for the migration process.

    # virsh migrate \
       --live --persistent \
       --parallel --parallel-connections 4 \
       <example_VM> qemu+ssh://<example-destination>/system

    This example uses 4 multi-FD channels to migrate the <example_VM> VM. It is a good practice to use one channel for each 10 Gbps of available network bandwidth. The default value is 2 channels.

• Live migration with an increased downtime limit

  • To improve the reliability of a live migration, you can set the maxdowntime parameter, which specifies the maximum amount of time, in milliseconds, the VM can be paused during live migration. Setting a larger downtime can help to ensure the migration completes successfully.

    # virsh migrate-setmaxdowntime \
       <example_VM> \
       <time_interval_in_milliseconds>

• Live migration with passwordless SSH authentication

  • To avoid the need to input the SSH password for the remote host during the migration, you can specify a private key file for the migration to use instead. This can be useful for example in automated migration scripts, or for peer-to-peer migration.

    # virsh migrate \
       --live --persistent <example_VM> \
       qemu+ssh://<example-destination>/system?keyfile=<path_to_key>

• Post-copy migration

  • If your VM has a large memory footprint, you can perform a post-copy migration, which transfers the source VM’s CPU state first and immediately starts the migrated VM on the destination host. The source VM’s memory pages are transferred after the migrated VM is already running on the destination host. Because of this, a post-copy migration can result in a smaller downtime of the migrated VM.

    However, the running VM on the destination host might try to access memory pages that have not yet been transferred, which causes a page fault. If too many page faults occur during the migration, the performance of the migrated VM can be severely degraded.

    Because of the potential complications of a post-copy migration, use the following command in most use cases. This uses a standard live migration and switches to a post-copy migration if the live migration cannot be finished in a specified amount of time.

    # virsh migrate \
       --live --persistent --postcopy \
       --timeout <time_interval_in_seconds> \
       --timeout-postcopy <example_VM> \
       qemu+ssh://<example-destination>/system

    In RHEL 10.1 and later, you can also live-migrate memory-intensive VMs by using a migration that starts with a multifd pre-copy phase and then switches to post-copy migration. This provides better migration performance and flexibility.

    # virsh migrate \
       --live --persistent --parallel \
       --postcopy --postcopy-after-precopy \
       <example_VM> \
       qemu+ssh://<example-destination>/system

• Auto-converged live migration

  • If your VM is under a heavy memory workload, you can use the --auto-converge option. This option automatically slows down the execution speed of the VM’s CPU. As a consequence, this CPU throttling can help to slow down memory writes, which means the live migration might succeed even in VMs with a heavy memory workload.

    However, the CPU throttling does not help to resolve workloads where memory writes are not directly related to CPU execution speed, and it can negatively impact the performance of the VM during a live migration.

    # virsh migrate \
       --live --persistent --auto-converge \
       <example_VM> qemu+ssh://<example-destination>/system

Verification

• For offline migration:

  • On the destination host, list the available VMs to verify that the VM was migrated successfully.

    # virsh list --all
    Id      Name             State
    ----------------------------------
    10    example-VM-1      shut off

• For live migration:

  • On the destination host, list the available VMs to verify the state of the destination VM:

    # virsh list --all
    Id      Name             State
    ----------------------------------
    10    example-VM-1      running

    If the state of the VM is listed as running, it means that the migration is finished. However, if the live migration is still in progress, the state of the destination VM will be listed as paused.

• For post-copy migration:

  1. On the source host, list the available VMs to verify the state of the source VM.

     # virsh list --all
     Id      Name             State
     ----------------------------------
     10    example-VM-1      shut off

  2. On the destination host, list the available VMs to verify the state of the destination VM.

     # virsh list --all
     Id      Name             State
     ----------------------------------
     10    example-VM-1      running

     If the state of the source VM is listed as shut off and the state of the destination VM is listed as running, it means that the migration is finished.

Prerequisites

• You have installed the RHEL 10 web console.

  For instructions, see Installing and enabling the web console.

• The web console VM plug-in is installed on your system.
• Hypervisor: The source host and the destination host both use the KVM hypervisor.
• Hosts: The source and destination hosts are running.

• Open ports: Ensure the following ports are open on the destination host.

  • Port 22 is needed for connecting to the destination host by using SSH.
  • Port 16514 is needed for connecting to the destination host by using TLS.
  • Port 16509 is needed for connecting to the destination host by using TCP.
  • Ports 49152-49215 are needed by QEMU for transferring the memory and disk migration data.
• CPU: The VM must be compatible with the CPU features of the destination host. To ensure this is the case, see Verifying host CPU compatibility for virtual machine migration.

• Storage: The disk images of VMs that will be migrated are accessible to both the source host and the destination host. This is optional for offline migration, but required for migrating a running VM. To ensure storage accessibility for both hosts, one of the following must apply:

  • You are using storage area network (SAN) logical units (LUNs).
  • You are using a Ceph storage clusters.
  • You have created a disk image with the same format and size as the source VM disk and you will use the --copy-storage-all parameter when migrating the VM.
  • The disk image is located on a separate networked location. For instructions to set up such shared VM storage, see Sharing virtual machine disk images with other hosts.

• Network bandwidth: When migrating a running VM, your network bandwidth must be higher than the rate in which the VM generates dirty memory pages.

  To obtain the dirty page rate of your VM before you start the live migration, do the following on the command line:

  1. Monitor the rate of dirty page generation of the VM for a short period of time.

     # virsh domdirtyrate-calc vm-name 30

  2. After the monitoring finishes, obtain its results:

     # virsh domstats vm-name --dirtyrate
     Domain: 'vm-name'
       dirtyrate.calc_status=2
       dirtyrate.calc_start_time=200942
       dirtyrate.calc_period=30
       dirtyrate.megabytes_per_second=2

     In this example, the VM is generating 2 MB of dirty memory pages per second. Attempting to live-migrate such a VM on a network with a bandwidth of 2 MB/s or less will cause the live migration not to progress if you do not pause the VM or lower its workload.

     To ensure that the live migration finishes successfully, your network bandwidth should be significantly greater than the VM’s dirty page generation rate.

     Note

     The value of the calc_period option might differ based on the workload and dirty page rate. You can experiment with several calc_period values to determine the most suitable period that aligns with the dirty page rate in your environment.

• Bridge tap network specifics: When migrating an existing VM in a public bridge tap network, the source and destination hosts must be located on the same network. Otherwise, the VM network will not work after migration.

• Confirm whether the VM appears in the list of VMs available on the destination host.
• Start the migrated VM and observe if it boots up.

• Calculating dirty memory page rate generation of the VM.

  Currently, when migrating a VM with an attached Mellanox VF, live migration data and statistics provided by virsh domjobinfo and virsh domdirtyrate-calc commands are inaccurate, because the calculations only count guest RAM without including the impact of the attached VF.

• Using a post-copy live migration.
• Using a virtual I/O Memory Management Unit (vIOMMU) device in the VM.

• A CX-7 device with the same Parameter-Set Identification (PSID) and the same firmware version must be used on both the source and the destination hosts.

  You can check the PSID of your device with the following command:

  # mstflint -d <device_pci_address> query | grep -i PSID
  
  PSID: MT_1090111019

• On one CX-7 physical function, you can use at maximum 4 VFs for live migration at the same time. For example, you can migrate one VM with 4 attached VFs, or 4 VMs with one VF attached to each VM.

Prerequisites

• You have a Mellanox CX-7 networking device with a firmware version that is equal to or greater than 28.36.1010.

  Refer to Mellanox documentation for details about supported firmware versions and ensure you are using an up-to-date version of the firmware.

• The host uses the Intel 64, AMD64, or ARM 64 CPU architecture.
• The Mellanox firmware version on the source host must be the same as on the destination host.

• The mstflint package is installed on both the source and destination host:

  # dnf install mstflint

• The Mellanox CX-7 networking device has VF_MIGRATION_MODE set to MIGRATION_ENABLED:

  # mstconfig -d <device_pci_address> query | grep -i VF_migration
  
  VF_MIGRATION_MODE                           MIGRATION_ENABLED(2)

  • You can set VF_MIGRATION_MODE to MIGRATION_ENABLED by using the following command:

    # mstconfig -d <device_pci_address> set VF_MIGRATION_MODE=2

• The openvswitch package is installed on both the source and destination host:

  # dnf install openvswitch

• All of the general SR-IOV devices prerequisites. For details, see Attaching SR-IOV networking devices to virtual machines
• All of the general VM migration prerequisites. For details, see Migrating a virtual machine by using the command line

Prerequisites

• You have an NVIDIA GPU with an NVIDIA Virtual GPU Software Driver version that supports this functionality. Refer to the relevant NVIDIA vGPU documentation for more details.
• You have a correctly configured NVIDIA vGPU assigned to a VM. For instructions, see: Managing NVIDIA vGPU devices.

• The host uses the Intel 64 or AMD64 CPU architecture.
• All of the vGPU migration prerequisites that are documented by NVIDIA. Refer to the relevant NVIDIA vGPU documentation for more details.
• All of the general VM migration prerequisites. For details, see Migrating a virtual machine by using the command line

• Certain NVIDIA GPU features can disable the migration. For more information, see the specific NVIDIA documentation for your graphics card.
• Some GPU workloads are not compatible with the downtime that happens during a migration. As a consequence, the GPU workloads might stop or crash. It is recommended to test if your workloads are compatible with the downtime before attempting a vGPU live migration.

• Currently, some general virtualization features cannot be used when live migrating a VM with an attached vGPU:

  • Calculating dirty memory page rate generation of the VM.

    Currently, live migration data and statistics provided by virsh domjobinfo and virsh domdirtyrate-calc commands are inaccurate when migrating a VM with an attached vGPU, because the calculations only count guest RAM without including vRAM from the vGPU.

  • Using a post-copy live migration.
  • Using a virtual I/O Memory Management Unit (vIOMMU) device in the VM.

Procedure

• For instructions on how to proceed with the live migration, see: Migrating a virtual machine by using the command line

  In most cases, no additional parameters for the migration command are required for the attached vGPU device.

• To live migrate a VM with a legacy vGPU based on a mediated device to a host that supports SR-IOV-based vGPUs, for example when migrating from a RHEL 9 host to a RHEL 10 host, you can change the vGPU type during migration:

  1. Create a copy of the XML configuration file of the VM:

     # cp /etc/libivrt/qemu/<vm_config>.xml /etc/libivrt/qemu/<vm_new_config>.xml

  2. Open the new copy of the XML configuration.

  3. Adjust the <hostdev> section of the mediated device (type='mdev') to instead use an SR-IOV device that is available on the destination host. For example:

     <hostdev mode='subsystem' type='pci' managed='no' display='on' ramfb='on'>
        <source>
          <address domain='0x0000' bus='0x41' slot='0x02' function='0x3'/>
       </source>
     </hostdev>

  4. Save the XML configuration.

  5. When performing the VM live migration, set the VM to use the adjusted XML on the destination host:

     # virsh migrate --live \
       --xml <vm_new_config>.xml \
       <vm-name> \
       qemu+ssh://<destination_host>/system

Prerequisites

• The VM intended for migration is shut down.
• Optional: A host system is available for hosting the storage that is not the source or destination host, but both the source and the destination host can reach it through the network. This is the optimal solution for shared storage.
• Make sure that NFS file locking is not used as it is not supported in KVM.
• The NFS protocol is installed and enabled on the source and destination hosts. See Deploying an NFS server.

• The virt_use_nfs SELinux boolean is set to on.

  # setsebool virt_use_nfs 1

Verification

• Start the VM on the source host and observe if it boots successfully.

Prerequisites

• Virtualization is installed and enabled on your system.
• You have administrator access to the source host and the destination host for the migration.

Next steps

• Sharing virtual machine disk images with other hosts
• Migrating a virtual machine by using the command line
• Live-migrating a virtual machine by using the web console

Prerequisites

• You have installed the RHEL 10 web console.

  For instructions, see Installing and enabling the web console.

• The web console VM plug-in is installed on your system.

Prerequisites

• Any virtual machines (VMs) that use the disk image must be shut down.

Prerequisites

• You have created a backup of the disk image.

• Any virtual machines (VMs) that use the disk image must be shut down.

  Warning

  Resizing the disk image of a running VM can cause data corruption or other issues.

• The hard disk of the host has sufficient free space for the intended disk image size.
• Optional: You have ensured that the disk image does not have data corruption or similar problems. For instructions, see Checking the consistency of a virtual disk.

Prerequisites

• Any virtual machines (VMs) that use the disk image must be shut down.
• The source disk image format must be supported for conversion by QEMU. For a detailed list, see Supported disk image formats.

Procedure

• Use the qemu-img convert command to convert an existing virtual disk image to a different format. For example, to convert a raw disk image to a QCOW2 disk image:

  # qemu-img convert -f raw <original-image.img> -O qcow2 <converted-image.qcow2>

• Detach the virtual disk from the VM.
• Delete the virtual disk and its content.
• Deactivate the storage pool related to the virtual disk.
• Delete the storage pool related to the virtual disk.

Verification

• To confirm that your changes to VM storage have been successful, inspect the current state of virtual storage on your host.

  For instructions, see Viewing virtual machine storage information by using the command line.

• Detach the virtual disk from the VM.
• Delete the virtual disk and its content.
• Deactivate the storage pool related to the virtual disk.
• Delete the storage pool related to the virtual disk.

Prerequisites

• You have installed the RHEL 10 web console.

  For instructions, see Installing and enabling the web console.

• The web console VM plug-in is installed on your system.

Verification

• To confirm that your changes to VM storage have been successful, inspect the current state of virtual storage on your host.

  For instructions, see Viewing virtual machine storage information by using the web console.

• qcow2 - Provides certain additional features, such as compression.
• raw - Might provide better performance.
• luks - Disk images encrypted by using the Linux Unified Key Setup (LUKS) specification.

• If required, you can convert your disk images between the raw and qcow2 formats by using the qemu-img convert command.
• If you require converting a vmdk disk image to a raw or qcow2 format, convert the VM that uses the disk to KVM by using the virt-v2v utility.

• To convert other disk image formats to raw or qcow2, you can use the qemu-img convert command. For a list of formats that work with this command, see the QEMU documentation.

  Note that in most cases, converting the disk image format of a non-KVM virtual machine to qcow2 or raw is not sufficient for the VM to correctly run on RHEL KVM. In addition to converting the disk image, corresponding drivers must be installed and configured in the guest operating system of the VM. For supported hypervisor conversion, use the virt-v2v utility.

• The VM is using file-based storage.

• You create the VM snapshot only in one of the following scenarios:

  • The VM is shut-down.
  • If the VM is running, you use the --disk-only --quiesce options or the --memspec option.

• Example output of a supported snapshot:

  <domainsnapshot>
    <name>sample-snapshot-name-1<name>
    <state>shutoff</state>
    <creationTime>1706658764</creationTime>
    <memory snapshot='no'/>
    <disks>
      <disk name='vda' snapshot='external' type='file'>
        <driver type='qcow2'/>
        <source file='/var/lib/libvirt/images/vm-name.sample-snapshot-name-1'/>
      </disk>
    </disks>
    <domain type='kvm'>
    [...]

• Example output of an unsupported snapshot:

  <domainsnapshot>
    <name>sample-snapshot-name-2</name>
    <state>running</state>
    <creationTime>1653396424</creationTime>
    <memory snapshot='internal'/>
    <disks>
      <disk name='vda' snapshot='internal'/>
      <disk name='sda' snapshot='no'/>
    </disks>
    <domain type='kvm'>
    [...]

Prerequisites

• The VM uses file-based storage. To check whether this is the case, use the following command and ensure that for the disk device, it displays disk type as file:

  # virsh dumpxml <vm-name> | grep "disk type"
      <disk type='file' device='disk'>
      <disk type='file' device='cdrom'>

• If you want to create a VM snapshot that includes the memory of a running VM, you must have sufficient disk space to store the memory of the VM.

  • The minimum recommended space for saving the memory of a VM is equal to the VM’s assigned RAM. For example, saving the memory of a VM with 32 GB RAM requires up to 32 GB of disk space.
  • If the VM is under heavy I/O load, significant additional disk space might be required.
  • If the VM has assigned VFIO passthrough devices, additional disk space might be required.

  • If a snapshot is created without pausing the VM, additional disk space might be required.

    Important

    Red Hat recommends not saving the memory of a running VM that is under very high workload or that uses VFIO passthrough devices. Saving the memory of such VMs might fill up the host disk and degrade the system. Instead, consider creating snapshots without memory for such VMs.

    In addition, note that not all VFIO devices are capable of creating snapshots with memory. Currently, creating a snapshot with memory works correctly only in the following situations:

    • The attached VFIO device is a Mellanox VF with the migration capability enabled.
    • The attached VFIO device is an NVIDIA vGPU with the migration capability enabled.

Prerequisites

• You have installed the RHEL 10 web console.

  For instructions, see Installing and enabling the web console.

• The web console VM plug-in is installed on your system.

• The VM uses file-based storage. To ensure that this is the case, perform the following steps:

  1. In the Virtual machines interface of the web console, click the VM of which you want to create a snapshot.
  2. In the Disks pane of the management overview, check the Source column of the listed devices. In all devices that list a source, this source must be File.

Prerequisites

• A snapshot of the VM is available, which you have previously created in the web console or by using the command line.
• Optional: You have created a snapshot of the current state of the VM. If you revert to a previous snapshot without saving the current state, changes performed on the VM since the last snapshot will be lost.

Procedure

• Use the virsh snapshot-revert utility and specify the name of the VM and the name of the snapshot to which you want to revert. For example, the following command reverts the Testguest2 VM to the clean-install snapshot.

  # virsh snapshot-revert Testguest2 clean-install
  
  Domain snapshot clean-install reverted

Verification

• Display the currently active snapshot for the reverted VM:

  # virsh snapshot-current Testguest2 --name
  
  clean-install

Prerequisites

• You have installed the RHEL 10 web console.

  For instructions, see Installing and enabling the web console.

• The web console VM plug-in is installed on your system.
• A snapshot of the VM is available, which you have previously created in the web console or by using the command line.
• Optional: You have created a snapshot of the current state of the VM. If you revert to a previous snapshot without saving the current state, changes performed on the VM since the last snapshot will be lost.

Verification

• In the Snapshots pane, if a green check symbol now displays on the left side of the selected snapshot, you have successfully reverted to it.

Prerequisites

• Optional: A child snapshot exists for the snapshot you want to delete.

  A child snapshot is created automatically when you have an active snapshot and create a new snapshot. If you delete a snapshot that does not have any children, you will lose any changes saved in the snapshot after it was created from its parent snapshot.

  To view the parent-child structure of snapshots in a VM, use the virsh snapshot-list --tree command. The following example shows Latest-snapshot as a child of Redundant-snapshot.

  # virsh snapshot-list --tree <vm-name>
  
  Clean-install-snapshot
    |
    +- Redundant-snapshot
        |
        +- Latest-snapshot

Procedure

• Use the virsh snapshot-delete command to delete the snapshot. For example, the following command deletes Redundant-snapshot from the Testguest1 VM:

  # virsh snapshot-delete Testguest1 Redundant-snapshot
  
  Domain snapshot Redundant-snapshot deleted

Verification

• To ensure that the snapshot that you deleted is no longer present, display the existing snapshots of the impacted VM and their parent-child structure:

  # virsh snapshot-list --tree <Testguest1>
  
  Clean-install-snapshot
    |
    +- Latest-snapshot

  In this example, Redundant-snapshot has been deleted and Latest-snapshot has become the child of Clean-install-snapshot.

Prerequisites

• You have installed the RHEL 10 web console.

  For instructions, see Installing and enabling the web console.

• The web console VM plug-in is installed on your system.

• Optional: A child snapshot exists for the snapshot you want to delete.

  A child snapshot is created automatically when you have an active snapshot and create a new snapshot. If you delete a snapshot that does not have any children, you will lose any changes saved in the snapshot after it was created from its parent snapshot.

  To check that the snapshot has a child, confirm that the snapshot is listed in the Parent snapshot column of the Snapshots in the web console overview of the VM.

Verification

• If the snapshot no longer appears in the Snapshots pane, it has been deleted successfully.

• the CPU
• memory
• a keyboard
• a network interface controller (NIC)
• various device controllers
• a video card
• a sound card

• an emulated controller
• virtio-scsi
• virtio-blk

• USB, PCI, and SCSI passthrough - expose common industry standard buses directly to VMs to make their specific features available to guest software.
• Single-root I/O virtualization (SR-IOV) - a specification that enables hardware-enforced isolation of PCI Express resources. This makes it safe and efficient to partition a single physical PCI resource into virtual PCI functions. It is commonly used for network interface cards (NICs).
• N_Port ID virtualization (NPIV) - a Fibre Channel technology to share a single physical host bus adapter (HBA) with multiple virtual ports.
• GPUs and vGPUs - accelerators for specific kinds of graphic or compute workloads. Some GPUs can be attached directly to a VM, while certain types also offer the ability to create virtual GPUs (vGPUs) that share the underlying physical hardware.

Prerequisites

• Ensure the device you want to pass through to the VM is attached to the host.

Prerequisites

• If your host is using the IBM Z architecture, the vfio kernel modules must be loaded on the host. To verify, use the following command:

  # lsmod | grep vfio

  The output must contain the following modules:

  • vfio_pci
  • vfio_pci_core
  • vfio_iommu_type1