#Troubleshooting Boot and Image Import

#Reading the guest boot log

When a virtual machine fails to boot (kernel panic, missing root disk, stuck at the bootloader), the graphical and serial consoles may not show enough. Enable serial-console logging so the guest's boot output is captured to the launcher pod's logs:

spec:
  template:
    spec:
      domain:
        devices:
          logSerialConsole: true

After the virtual machine restarts, the launcher pod gains a guest-console-log container. Read the captured boot output with:

kubectl logs <virt-launcher-pod> -c guest-console-log -n <namespace>

#Diagnosing a stuck image import

A bootable volume or virtual machine disk that stays in Importing usually has a DataVolume problem. Inspect the DataVolume's phase and conditions:

kubectl get datavolume <name> -n <ns> \
  -o jsonpath='phase={.status.phase} {range .status.conditions[*]}{.type}={.status} {end}{"\n"}'
# A healthy completed import: phase=Succeeded Bound=True Ready=True Running=False

kubectl describe datavolume <name> -n <ns>   # events show pull / auth / space errors

The Bound condition reflects the PVC, Running reflects the importer pod, and Ready indicates the disk is usable. A Running=False with a message points at the importer pod's failure — image not found, registry authentication, or insufficient space.

#Capturing a virtual machine memory dump

To analyze a hung or crashed (but still running) virtual machine, capture its guest RAM to a PVC for offline analysis:

virtctl memory-dump get web-01 --claim-name=web-01-memory -n demo

The dump is written to the named PVC, which you can then download and inspect. See Using the virtctl Command-Line Tool.