Chapter 19. Diagnosing virtual machine problems

When working with virtual machines (VMs), you may encounter problems with varying levels of severity. Some problems may have a quick and easy fix, while for others, you may have to capture VM-related data and logs to report or diagnose the problems.

The following sections provide detailed information about generating logs and diagnosing some common VM problems, as well as about reporting these problems.

19.1. Generating virtual machine debug logs

To diagnose virtual machine (VM) problems, it is helpful to generate and review the debug logs. Attaching debug logs is also useful when asking for support to resolve VM-related problems.

The following sections explain what debug logs are, how you can set them to be persistent, enable them during runtime, and attach them when reporting problems.

19.1.1. Understanding virtual machine debug logs

Debug logs are text files that contain data about events that occur during virtual machine (VM) runtime. The logs provide information about fundamental server-side functionalities, such as host libraries and the libvirtd service. The log files also contain the standard error output (stderr) of all running VMs.

Debug logging is not enabled by default and has to be enabled when libvirt starts. You can enable logging for a single session or persistently. You can also enable logging when a libvirtd daemon session is already running by modifying the daemon run-time settings.

Attaching the libvirt debug logs is also useful when requesting support with a VM problem.

19.1.2. Enabling persistent settings for virtual machine debug logs

You can configure virtual machine (VM) debug logging to be automatically enabled whenever libvirt starts by editing the libvirtd.conf configuration file which is located in the /etc/libvirt directory.

Procedure

  1. Open the libvirtd.conf file in an editor.
  2. Replace or set the filters according to your requirements.

    Setting the filter value to:

    • 1: logs all messages generated by libvirt.
    • 2: logs all non-debugging information.
    • 3: logs all warning and error messages. This is the default value.
    • 4: logs only error messages.

    For example, the following command:

    • Logs all error and warning messages from the remote, util.json, and rpc layers
    • Logs only error messages from the event layer.
    • Saves the filtered logs to /var/log/libvirt/libvirtd.log

      log_filters="3:remote 4:event 3:util.json 3:rpc"
      log_outputs="1:file:/var/log/libvirt/libvirtd.log"
  3. Save and exit.
  4. Restart the libvirtd service.

    $ systemctl restart libvirtd.service

19.1.3. Enabling virtual machine debug logs during runtime

You can modify the libvirt daemon’s runtime settings to enable debug logs and save them to an output file.

This is useful when restarting libvirtd is not possible because restarting fixes the problem, or because there is another process, such as migration or backup, running at the same time. Modifying runtime settings is also useful if you want to try a command without editing the configuration files or restarting the daemon.

Prerequisites

  • Make sure the libvirt-admin package is installed.

Procedure

  1. Optional: Back up the active set of log filters.

    # virt-admin daemon-log-filters >> virt-filters-backup
    Note

    It is recommended that you back up the active set of filters so that you can restore them after generating the logs. If you do not restore the filters, the messages will continue to be logged which may affect system performance.

  2. Use the virt-admin utility to enable debugging and set the filters according to your requirements.

    Setting the filter value to:

    • 1: logs all messages generated by libvirt.
    • 2: logs all non-debugging information.
    • 3: logs all warning and error messages. This is the default value.
    • 4: logs only error messages.

    For example, the following command:

    • Logs all error and warning messages from the remote, util.json, and rpc layers
    • Logs only error messages from the event layer.

      # virt-admin daemon-log-filters "3:remote 4:event 3:util.json 3:rpc"
  3. Use the virt-admin utility to save the logs to a specific file or directory.
    For example, the following command saves the log output to the libvirt.log file in the /var/log/libvirt/ directory.

    # virt-admin daemon-log-outputs "1:file:/var/log/libvirt/libvirtd.log"
  4. Optional: You can also remove the filters to generate a log file that contains all VM-related information. However, it is not recommended since this file may contain a large amount of redundant information produced by libvirt’s modules.

    • Use the virt-admin utility to specify an empty set of filters.

      # virt-admin daemon-log-filters
        Logging filters:
  5. Optional: Restore the filters to their original state using the backup file.
    Perform the second step with the saved values to restore the filters.

19.1.4. Attaching virtual machine debug logs to support requests

You may have to request additional support to diagnose and resolve virtual machine (VM) problems. Attaching the debug logs to the support request is highly recommended to ensure that the support team has access to all the information they need to provide a quick resolution of the VM-related problem.

Procedure

  • To report a problem and request support, open a support case.
  • Based on the encountered problems, attach the following logs along with your report:

    • For problems with the libvirt service, attach the /var/log/libvirt/libvirtd.log file from the host.
    • For problems with a specific VM, attach its respective log file.

      For example, for the testguest1 VM, attach the testguest1.log file, which can be found at /var/log/libvirt/qemu/testguest1.log.

Additional resources

19.2. Dumping a virtual machine core

To analyze why a virtual machine (VM) crashed or malfunctioned, you can dump the VM core to a file on disk for later analysis and diagnostics.

This section provides a brief introduction to core dumping and explains how you can dump a VM core to a specific file.

19.2.1. How virtual machine core dumping works

A virtual machine (VM) requires numerous running processes to work accurately and efficiently. In some cases, a running VM may terminate unexpectedly or malfunction while you are using it. Restarting the VM may cause the data to be reset or lost, which makes it difficult to diagnose the exact problem that caused the VM to crash.

In such cases, you can use the virsh dump utility to save (or dump) the core of a VM to a file before you reboot the VM. The core dump file contains a raw physical memory image of the VM which contains detailed information about the VM. This information can be used to diagnose VM problems, either manually, or by using a tool such as the crash utility.

Additional resources

19.2.2. Creating a virtual machine core dump file

A virtual machine (VM) core dump contains detailed information about the state of a VM at any given time. This information, essentially a snapshot of the VM, is extremely useful to detect problems in the event of a VM malfunction or a sudden VM shutdown.

Prerequisites

  • Make sure you have sufficient disk space to save the file. Note that the space occupied by the VM depends on the amount of RAM allocated to the VM.

Procedure

  • Use the virsh dump utility.

    For example, the following command dumps the lander1 VM’s cores, its memory and the CPU common register file to gargantua.file in the /core/file directory.

    # virsh dump lander1 /core/file/gargantua.file --memory-only
      Domain lander1 dumped to /core/file/gargantua.file
Important

The crash utility no longer supports the default file format of the virsh dump command. To analyze a core dump file using crash, you must create the file using the --memory-only option.

Additionally, you must use the --memory-only option when creating a core dump file to attach to a Red Hat Suport Case.

Additional resources

  • For other virsh dump arguments, see the virsh man page.
  • For information about opening a support case, see Open a Support Case

19.3. Backtracing virtual machine processes

When a process related to a virtual machine (VM) malfunctions, you can use the gstack command along with the process identifier (PID) to generate an execution stack trace of the malfunctioning process. If the process is a part of a thread group then all the threads are traced as well.

Prerequisites

  • Ensure that the GDB package is installed.

    For details about installing GDB and the available components, see Installing the GNU Debugger.

  • Make sure you know the PID of the processes that you want to backtrace.

    You can find the PID by using the pgrep command followed by the name of the process. For example:

    # pgrep libvirt
    22014
    22025

Procedure

  • Use the gstack utility followed by the PID of the process you wish to backtrace.

    For example, the following command backtraces the libvirt process with the PID 22014.

    # gstack 22014
    Thread 3 (Thread 0x7f33edaf7700 (LWP 22017)):
    #0  0x00007f33f81aef21 in poll () from /lib64/libc.so.6
    #1  0x00007f33f89059b6 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0
    #2  0x00007f33f8905d72 in g_main_loop_run () from /lib64/libglib-2.0.so.0
    ...

Additional resources

  • For other gstack arguments, see the gstack man page.
  • For more information about GDB, see GNU Debugger.

19.4. Additional resources for reporting virtual machine problems and providing logs

To request additional help and support, you can: