Configuring and managing virtualization

Next steps

• To start using virtualization in Red Hat Enterprise Linux 9, see Enabling virtualization in Red Hat Enterprise Linux 9.
• In addition to Red Hat Enterprise Linux 9 virtualization, Red Hat offers a number of specialized virtualization solutions, each with a different user focus and features. For more information, see Red Hat virtualization solutions.

• 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.

• 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 7 guest OS, you can run applications released for RHEL 7 on a RHEL 9 host system.

  Note

  Not all operating systems are supported as a guest OS in a RHEL 9 host. For details, see Recommended features in RHEL 9 virtualization.

• 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.

• The RHEL 9 web console, also known as Cockpit, provides a remotely accessible and easy to use graphical user interface for managing VMs and virtualization hosts.

  For instructions on basic virtualization management with the web console, see Managing virtual machines in the web console.

Prerequisites

• Red Hat Enterprise Linux 9 is installed and registered on your host machine.

• Your system meets the following hardware requirements to work as a virtualization host:

  • The architecture of your host machine supports KVM virtualization.

  • 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

• 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 a z13 CPU or later.

• RHEL 9 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

• 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.

Next steps

• Creating virtual machines

• For Linux VMs, see Enabling QEMU Guest Agent on Linux guests.
• For Windows VMs, see Enabling QEMU Guest Agent on Windows guests.

Prerequisites

• Virtualization is enabled on your host system.
• You have a sufficient amount of system resources to allocate to your VMs, such as disk space, RAM, or CPUs. The recommended values may 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 9. If you select a CD-ROM or DVD-ROM as the installation source when using any VM installation method available in RHEL 9, 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.

• Optional: A Kickstart file can be provided for faster and easier configuration of the installation.

• --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

• 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 --os-variant win10 \
      --cdrom /home/username/Downloads/Win10install.iso

• The following command creates a VM named demo-guest2 that uses the /home/username/Downloads/rhel9.iso image to run a RHEL 9 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 --os-variant rhel9.0 \
      --cdrom /home/username/Downloads/rhel9.iso

• The following command creates a RHEL 9 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 \
      --os-variant rhel9.0 --import \
      --disk /home/username/backup/disk.qcow2

  Note that the --os-variant option is highly recommended when importing a disk image. If it is not provided, the performance of the created VM will be negatively affected.

• 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 \
      --os-variant rhel9.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 9 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

• The following command creates a VM named demo-guest5 that installs from a RHEL9.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 \
      --os-variant rhel9.0 --location RHEL9.iso \
      --graphics none --extra-args='console=ttyS0'

• The following command creates a VM named demo-guest6, 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-guest6 --memory 16384 \
      --vcpus 16 --disk size=280 --os-variant rhel9.0 --location RHEL9.iso \
      --graphics none --extra-args='console=ttyS0'

• The following command creates a VM named demo-guest-7, 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-guest7 --memory 16384 --vcpus 16 --disk size=280 \
      --os-variant rhel9.0 --location RHEL9.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.

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:

    # {PackageManagerCommand} 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:

      # {PackageManagerCommand} 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

• An inactive VM that is already defined.
• The name of the VM.

• For remote VMs:

  • The IP address of the host where the VM is located.
  • Root access privileges to the host.

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 9 web console.

  For instructions, see Installing and enabling the web console.

• The web console VM plug-in is installed on your system.
• An inactive VM that is already defined.
• The name of the VM.

Prerequisites

• A created virtual machine

• To interact with the VM’s graphical interface in the web console, use the graphical console.
• To interact with the VM’s graphical interface in a remote viewer, use the graphical console in remote viewers.
• To interact with the VM’s CLI in the web console, use the serial console.

Prerequisites

• Your system, as well as the VM you are connecting to, must support graphical displays.
• If the target VM is located on a remote host, connection and root access privileges to the host are needed.
• Optional: If the target VM is located on a remote host, set up your libvirt and SSH for more convenient access to remote hosts.

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
  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 interaces

• 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
     ...

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
  Id    Name                           State
  ----------------------------------------------------
  2     testguest1                    running
  -     testguest2                    shut off

• Does not provide VNC protocols, and thus does not offer video display for GUI tools.
• Does not have a network connection, and thus cannot be interacted with 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-3.10.0-948.el7.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)

• You can edit the /etc/libvirt/libvirt.conf file and set the value of the uri_default parameter to example-qemu-host-alias as a default libvirt target.

  # These can be used in cases when no URI is supplied by the application
  # (@uri_default also prevents probing of the hypervisor driver).
  #
  uri_default = "example-qemu-host-alias"

  As a result, all libvirt-based commands will automatically be performed on the specified remote host.

  $ virsh list
  root@192.0.2.1's password:
  
  Id   Name              State
  ---------------------------------
  1   example-remote-guest      running

• When connecting to a remote host, you can avoid providing the root password to the remote system. To do so, use one or more of the following methods:

  • Set up key-based SSH access to the remote host
  • Use SSH connection multiplexing to connect to the remote system
  • Kerberos authentication in Identity Management
• The -c (or --connect) option can be used to run the virt-install, virt-viewer, and virsh commands on a remote host.

Prerequisites

• The VM that you want to protect with a VNC password has VNC graphics configured.

  To ensure that this is the case, use the virsh dumpxml command as follows:

  # virsh dumpxml <vm-name> | grep graphics
  
   <graphics type='vnc' ports='-1' autoport=yes listen=127.0.0.1>
   </graphics>

Shutting down a responsive VM

• If you are connected to the guest, use a shutdown command or a GUI element appropriate to the guest operating system.

  Note

  In some environments, such as in Linux guests that use the GNOME Desktop, using the GUI power button for suspending or hibernating the guest might instead shut down the VM.

• Alternatively, use the virsh shutdown command on the host:

  • If the VM is on a local host:

    # virsh shutdown demo-guest1
    Domain 'demo-guest1' is being shutdown

  • If the VM is on a remote host, in this example 192.0.2.1:

    # virsh -c qemu+ssh://root@192.0.2.1/system shutdown demo-guest1
    
    root@192.0.2.1's password:
    Domain 'demo-guest1' is being shutdown

Verification

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

  # virsh list --all
  
   Id    Name                 State
  ------------------------------------------
   1     demo-guest1          shut off

Prerequisites

• Back up important data from the VM.
• Shut down the VM.
• Make sure no other VMs use the same associated storage.

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.

Prerequisites

• You have installed the RHEL 9 web console.

  For instructions, see Installing and enabling the web console.

• You have installed the RHEL 9 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.

Next steps

• For instructions on enabling VMs management in your web console, see Setting up the web console to manage virtual machines.
• For a comprehensive list of VM management actions that the web console provides, see Virtual machine management features available in the web console.

Prerequisites

• You have installed the RHEL 9 web console.

  For instructions, see Installing and enabling the web console.

Procedure

• Install the cockpit-machines plug-in.

  # dnf install cockpit-machines

Prerequisites

• You have installed the RHEL 9 web console.

  For instructions, see Installing and enabling the web console.

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

Verification

• Check that the new VM name has appeared in the Virtual Machines interface.

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
   /boot        vda1   xfs

• 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 virtual network interfaces on your host:

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

  For information about a specific interface:

  # virsh net-info default
  Name:           default
  UUID:           c699f9f6-9202-4ca8-91d0-6b8cb9024116
  Active:         yes
  Persistent:     yes
  Autostart:      yes
  Bridge:         virbr0

  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

• Ensure you have sufficient disk space to save the VM and its configuration. Note that the space occupied by the VM depends on the amount of RAM allocated to that VM.
• Ensure the VM is persistent.
• Optional: Back up important data from the VM if required.

Procedure

• Use the virsh managedsave utility.

  For example, the following command stops the demo-guest1 VM and saves its configuration.

  # virsh managedsave demo-guest1
  Domain 'demo-guest1' saved by libvirt

  The saved VM file is located by default in the /var/lib/libvirt/qemu/save directory as demo-guest1.save.

  The next time the VM is started, it will automatically restore the saved state from the above file.

Verification

• List the VMs that have managed save enabled. In the following example, the VMs listed as saved have their managed save enabled.

  # virsh list --managed-save --all
  Id    Name                           State
  ----------------------------------------------------
  -     demo-guest1                    saved
  -     demo-guest2                    shut off

  To list the VMs that have a managed save image:

  # virsh list --with-managed-save --all
  Id    Name                           State
  ----------------------------------------------------
  -     demo-guest1                    shut off

  Note that to list the saved VMs that are in a shut off state, you must use the --all or --inactive options with the command.

Troubleshooting

• If the saved VM file becomes corrupted or unreadable, restoring the VM will initiate a standard VM boot instead.

Prerequisites

• An inactive VM that is already defined.
• The name of the VM.

• For remote VMs:

  • The IP address of the host where the VM is located.
  • Root access privileges to the host.

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 9 web console.

  For instructions, see Installing and enabling the web console.

• The web console VM plug-in is installed on your system.
• An inactive VM that is already defined.
• The name of the VM.

• 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.
• 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-clone.qcow2'                                      | 78.0 GB  00:05:37
    Allocating 'disk-2-example-VM-2-clone.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/

Prerequisites

• You have installed the RHEL 9 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 appears 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

Prerequisites

• Hypervisor: The source host and the destination host both use the KVM hypervisor.
• Network connection: The source host and the destination host are able to reach each other over the network. Use the ping utility to verify this.

• 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 16509 is needed for connecting to the destination host by using TLS.
  • Port 16514 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.
• Hosts: For the migration to be supportable by Red Hat, the source host and destination host must be using specific operating systems and machine types. To ensure this is the case, see Supported hosts for virtual machine migration.
• 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:

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

    # virsh domdirtyrate-calc <example_VM> 30

  • After the monitoring finishes, obtain its results:

    # virsh domstats <example_VM> --dirtyrate
    Domain: 'example-VM'
      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, Red Hat recommends that your network bandwidth is 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.

• Connection protocol: When performing a VM migration, the virsh client on the source host can use one of several protocols to connect to the libvirt daemon on the destination host. Examples in the following procedure use an SSH connection, but you can choose a different one.

  • If you want libvirt to use an SSH connection, ensure that the virtqemud socket is enabled and running on the destination host.

    # systemctl enable --now virtqemud.socket

  • If you want libvirt to use a TLS connection, ensure that the virtproxyd-tls socket is enabled and running on the destination host.

    # systemctl enable --now virtproxyd-tls.socket

  • If you want libvirt to use a TCP connection, ensure that the virtproxyd-tcp socket is enabled and running on the destination host.

    # systemctl enable --now virtproxyd-tcp.socket

Offline migration

• The following command migrates a 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

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 utilizing 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 recommended 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>

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.

  Given the potential complications of a post-copy migration, it is recommended to use the following command that starts 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

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 9 web console.

  For instructions, see Installing and enabling the web console.

• The web console VM plugin 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 16509 is needed for connecting to the destination host by using TLS.
  • Port 16514 is needed for connecting to the destination host by using TCP.
  • Ports 49152-49215 are needed by QEMU for transfering 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 in your command-line interface:

  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, Red Hat recommends that your network bandwidth is 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.

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 firmware versions.

• 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 interface

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: Setting up NVIDIA vGPU devices

  Note

  It is also possible to live migrate a VM with multiple vGPU devices attached.

• The host uses RHEL 9.4 or later as the operating system.
• 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 interface

Limitations

• 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, vGPU live migration fails if the vGPU driver version differs on the source and destination hosts.

• 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 interface

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 and is recommended by Red Hat.
• 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 interface
• Live-migrating a virtual machine by using the web console

• Your host is using RHEL 9.4 or later.
• 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 --live --memspec options.

• 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

• Your host is using RHEL 9.4 or later.

• 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.

    Warning

    Red Hat recommends not saving the memory of a running VMs 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 snapshot 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.

Procedure

• To create a VM snapshot with the required parameters, use the virsh snapshot-create-as command.

  # virsh snapshot-create-as <vm-name> <snapshot-name> <optional-description> <additional-parameters>

  • To create a snapshot of a shut-down VM, use the --disk-only parameter. For example, the following command creates Snapshot1 from the current disk-state of the shut-down Testguest1 VM:

    # virsh snapshot-create-as Testguest1 Snapshot1 --disk-only
    Domain snapshot Snapshot1 created.

  • To create a snapshot that saves the disk-state of a running VM but not its memory, use the --disk-only --quiesce parameters. For example, the following command creates Snapshot2 from the current disk state of the running Testguest2 VM, with the description clean system install:

    # virsh snapshot-create-as Testguest2 Snapshot2 "clean system install" --disk-only --quiesce
    Domain snapshot Snapshot2 created.

  • To create a snapshot that pauses a running VM and saves its disk-state and memory, use the --memspec parameter. For example, the following command pauses the Testguest3 VM and creates Snapshot3 from the current disk and memory state of the VM. The VM memory is saved in the /var/lib/libvirt/images/saved_memory.img file. When the snapshot is complete, the VM automatically resumes operation.

    # virsh snapshot-create-as Testguest3 Snapshot3 --memspec /var/lib/libvirt/images/saved_memory.img
    Domain snapshot Snapshot3 created.

    Pausing the VM during the snapshot process creates downtime, but might work more reliably than creating a live snapshot of a running VM (by using the --live option), especially for VMs under a heavy load.

  • To create a snapshot that saves the disk-state of a running VM as well as its live memory, use the --live --memspec parameters. For example, the following command creates Snapshot4 from the current disk and memory state of the running Testguest4 VM, and saves the memory state in the /var/lib/libvirt/images/saved_memory2.img file.

    # virsh snapshot-create-as Testguest4 Snapshot4 --live --memspec /var/lib/libvirt/images/saved_memory2.img
    Domain snapshot Snapshot4 created.

Prerequisites

• You have installed the RHEL 9 web console.

  For instructions, see Installing and enabling the web console.

• Your host is using RHEL 9.4 or later.
• 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 interface.
• 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:

  # 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 9 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 interface.
• 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 9 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 in order 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.

• View devices
• Attach devices
• Remove devices

Prerequisites

• You have a system with IBM Z hardware architecture supported with the FICON protocol.
• You have a target VM of a Linux operating system.

• The driverctl package is installed.

  # dnf install driverctl

• The necessary vfio kernel modules have been loaded on the host.

  # lsmod | grep vfio

  The output of this command must contain the following modules:

  • vfio_ccw
  • vfio_mdev
  • vfio_iommu_type1

• You have a spare DASD device for exclusive use by the VM, and you know the identifier of the device.

  The following procedure uses 0.0.002c as an example. When performing the commands, replace 0.0.002c with the identifier of your DASD device.

Prerequisites

• You have installed the RHEL 9 web console.

  For instructions, see Installing and enabling the web console.

• You have installed the web console VM plug-in on your system. For more information, see Section 8.2, “Setting up the web console to manage virtual machines”.

Verification

• The action you selected is visible next to the Watchdog field in the Overview pane.

Prerequisites

• You have a host system with the IBM Z hardware architecture.
• You have a target VM of Linux operating system.

• The necessary vfio kernel modules have been loaded on the host.

  # lsmod | grep vfio

  The output of this command must contain the following modules:

  • vfio_pci
  • vfio_pci_core
  • vfio_iommu_type1

• Storage pools
• Storage volumes
• Managing storage using libvirt
• Overview of VM storage
• Supported and unsupported storage pool types

• View storage pool information

• Create storage pools

  • Create directory-based storage pools by using the CLI
  • Create disk-based storage pools by using the CLI
  • Create filesystem-based storage pools by using the CLI
  • Create iSCSI-based storage pools by using the CLI
  • Create LVM-based storage pools by using the CLI
  • Create NFS-based storage pools by using the CLI
  • Create SCSI-based storage pools with vHBA devices by using the CLI
• Remove storage pools