Troubleshooting practice questions

You are troubleshooting a KVM guest that fails to start with the error 'unsupported configuration: CPU mode 'host-passthrough' requires KVM'. Which of the following is the most likely cause?

Trap 1: The host CPU is too old and does not support the host-passthrough…

The host-passthrough mode does not depend on the CPU's age or specific features; it simply passes through the host CPU model. The limitation is not about CPU capabilities but about the hypervisor. Even an older CPU can use host-passthrough if KVM is available. Therefore, this is not the likely cause of the error.

Trap 2: The guest's XML configuration has a typo in the CPU mode attribute.

A typo in the CPU mode attribute would likely result in an XML validation error or an 'unknown CPU mode' message. The error specifically mentions 'host-passthrough' and 'requires KVM', which indicates that the mode is recognized but not supported by the current hypervisor. A typo would not produce this specific error.

Trap 3: The host CPU does not support hardware virtualization extensions.

If the host CPU did not support hardware virtualization, the error would typically be about KVM not being available or /dev/kvm missing. The specific error about host-passthrough requiring KVM indicates that the guest is configured to use host-passthrough CPU mode, but the hypervisor is not KVM. This is not about the CPU's virtualization capabilities but about the hypervisor in use.

A
The host CPU is too old and does not support the host-passthrough mode.
Why it fails: The host-passthrough mode does not depend on the CPU's age or specific features; it simply passes through the host CPU model. The limitation is not about CPU capabilities but about the hypervisor. Even an older CPU can use host-passthrough if KVM is available. Therefore, this is not the likely cause of the error.
B
The guest's XML configuration has a typo in the CPU mode attribute.
Why it fails: A typo in the CPU mode attribute would likely result in an XML validation error or an 'unknown CPU mode' message. The error specifically mentions 'host-passthrough' and 'requires KVM', which indicates that the mode is recognized but not supported by the current hypervisor. A typo would not produce this specific error.
C
The guest is configured to use a CPU mode that is only supported by the KVM hypervisor, but the hypervisor is not KVM (e.g., QEMU TCG).
The host-passthrough CPU mode exposes the host CPU features directly to the guest and requires hardware virtualization (KVM). If libvirt is using a different hypervisor, such as QEMU's TCG (software emulation), this mode is not supported. The error clearly states that host-passthrough requires KVM, so the most likely cause is that the guest is running under a non-KVM hypervisor, possibly due to KVM not being enabled or the domain XML specifying a different hypervisor.
D
The host CPU does not support hardware virtualization extensions.
Why it fails: If the host CPU did not support hardware virtualization, the error would typically be about KVM not being available or /dev/kvm missing. The specific error about host-passthrough requiring KVM indicates that the guest is configured to use host-passthrough CPU mode, but the hypervisor is not KVM. This is not about the CPU's virtualization capabilities but about the hypervisor in use.

Question 2hardmultiple choice

You are troubleshooting a Docker container that cannot reach the internet despite the host having connectivity. The container uses the default bridge network. Which iptables chain is most likely causing the block?

Trap 1: PREROUTING

PREROUTING handles DNAT for published container ports on inbound traffic, not outbound masquerading. It is tempting because Docker inserts rules there, but the block preventing containers reaching the internet stems from missing source NAT, which is applied in POSTROUTING.

Trap 2: POSTROUTING

POSTROUTING is where Docker's MASQUERADE rule rewrites container source addresses for outbound traffic; if that rule is missing or dropped, containers cannot reach the internet. It is tempting because it genuinely handles outbound NAT, yet the question asks which chain causes the block, and this is the chain that must function.

Trap 3: OUTPUT

OUTPUT governs traffic originating from the host itself, not packets forwarded from containers. It is tempting because it is a filter chain that can drop traffic, but container internet access traverses FORWARD and POSTROUTING, so OUTPUT cannot block it.

A
PREROUTING
Why it fails: PREROUTING handles DNAT for published container ports on inbound traffic, not outbound masquerading. It is tempting because Docker inserts rules there, but the block preventing containers reaching the internet stems from missing source NAT, which is applied in POSTROUTING.
B
POSTROUTING
Why it fails: POSTROUTING is where Docker's MASQUERADE rule rewrites container source addresses for outbound traffic; if that rule is missing or dropped, containers cannot reach the internet. It is tempting because it genuinely handles outbound NAT, yet the question asks which chain causes the block, and this is the chain that must function.
C
FORWARD
Docker's default bridge network routes container traffic through the host's FORWARD chain, since packets are forwarded between the bridge and the external interface. A restrictive FORWARD policy (DROP) blocks that path even though the host itself has connectivity, making FORWARD the chain responsible for the container's failed internet access.
D
OUTPUT
Why it fails: OUTPUT governs traffic originating from the host itself, not packets forwarded from containers. It is tempting because it is a filter chain that can drop traffic, but container internet access traverses FORWARD and POSTROUTING, so OUTPUT cannot block it.

Question 3hardmultiple choice

You are troubleshooting a Docker container that fails to start with the error message: 'Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting /proc: no such file or directory'. The host is running a recent Linux kernel and Docker is using the default runtime. What is the most likely cause?

Trap 1: The Docker daemon is not running with the correct seccomp profile.

Seccomp profiles restrict system calls and could cause permission errors, but the error here is a mount failure with 'no such file or directory', which indicates a missing mount point rather than a blocked syscall. Seccomp issues typically manifest as 'operation not permitted' or similar, not as a missing directory during mount.

Trap 2: The host's /proc filesystem is not mounted or is inaccessible.

The host's /proc is essential for the host itself and is almost always mounted. If it were missing, the host would have severe issues. The error refers to mounting /proc inside the container's mount namespace, which is a separate operation. The host's /proc being unavailable is highly unlikely and would not produce this specific container init error.

Trap 3: The container image is corrupted and needs to be pulled again.

A corrupted image typically results in checksum errors or missing layers during pull, not a failure to mount /proc. The error specifically points to a problem during container init when mounting /proc, which is a runtime filesystem setup issue, not an image integrity issue. Re-pulling the image would not resolve the mount failure.

A
The Docker daemon is not running with the correct seccomp profile.
Why it fails: Seccomp profiles restrict system calls and could cause permission errors, but the error here is a mount failure with 'no such file or directory', which indicates a missing mount point rather than a blocked syscall. Seccomp issues typically manifest as 'operation not permitted' or similar, not as a missing directory during mount.
B
The container's root filesystem is missing the /proc directory.
During container initialization, runc attempts to mount a new proc filesystem at /proc inside the container's root filesystem. If the /proc directory does not exist in the container image, the mount call fails with 'no such file or directory'. This is a common issue when building minimal images from scratch without creating the standard directories. The solution is to ensure the image includes an empty /proc directory.
C
The host's /proc filesystem is not mounted or is inaccessible.
Why it fails: The host's /proc is essential for the host itself and is almost always mounted. If it were missing, the host would have severe issues. The error refers to mounting /proc inside the container's mount namespace, which is a separate operation. The host's /proc being unavailable is highly unlikely and would not produce this specific container init error.
D
The container image is corrupted and needs to be pulled again.
Why it fails: A corrupted image typically results in checksum errors or missing layers during pull, not a failure to mount /proc. The error specifically points to a problem during container init when mounting /proc, which is a runtime filesystem setup issue, not an image integrity issue. Re-pulling the image would not resolve the mount failure.

Question 4hardmultiple choice

You are troubleshooting a Docker container that fails to start with the error 'no space left on device' even though `df -h` shows ample free space on the host's root filesystem. The Docker data root is on a separate partition. Which command should you use to check the actual disk usage of Docker's data root?

Trap 1: `docker events`

`docker events` streams real-time events from the Docker daemon, such as container start, stop, and image pull. It does not provide disk usage statistics. While it might show a container failing to start, it will not reveal how much space is consumed in the data root, so it does not address the root cause.

Trap 2: `docker stats`

`docker stats` provides live resource usage such as CPU, memory, and network I/O for running containers. It does not report disk space or storage consumption. Since the problem is about disk capacity rather than runtime resource usage, this command is not relevant to the troubleshooting step.

Trap 3: `docker info`

`docker info` displays daemon configuration, including the Docker root directory and storage driver, but it does not show per-object disk usage. It can confirm where the data root is located, but it will not quantify how much space images or volumes consume. It is useful for orientation but not for diagnosing space exhaustion.

A
`docker system df -v`
`docker system df -v` shows detailed disk usage of images, containers, volumes, and build cache, including which items consume space. Since the Docker data root is on a separate partition, `df -h` on the host root may not reflect it. This command reveals the actual consumption within Docker's storage area, helping identify the cause of the 'no space left' error.
B
`docker events`
Why it fails: `docker events` streams real-time events from the Docker daemon, such as container start, stop, and image pull. It does not provide disk usage statistics. While it might show a container failing to start, it will not reveal how much space is consumed in the data root, so it does not address the root cause.
C
`docker stats`
Why it fails: `docker stats` provides live resource usage such as CPU, memory, and network I/O for running containers. It does not report disk space or storage consumption. Since the problem is about disk capacity rather than runtime resource usage, this command is not relevant to the troubleshooting step.
D
`docker info`
Why it fails: `docker info` displays daemon configuration, including the Docker root directory and storage driver, but it does not show per-object disk usage. It can confirm where the data root is located, but it will not quantify how much space images or volumes consume. It is useful for orientation but not for diagnosing space exhaustion.

Question 5mediummulti select

You are troubleshooting a KVM guest that fails to boot after you changed its XML configuration. You want to verify and correct the guest's definition without starting it. Which TWO of the following actions are appropriate? (Choose two.)

Trap 1: Use virsh undefine guestname then virsh define guest.xml to replace…

Undefining the guest removes its persistent configuration entirely, including any associated metadata. While you could then define a new one, this is destructive and unnecessary. It also risks losing the original configuration if the new XML is invalid. This is not an appropriate troubleshooting step for correcting XML errors.

Trap 2: Use virsh dumpxml guestname > guest.xml, edit the file, then run…

virsh create starts a transient guest from the XML file, but it does not update the persistent definition. The changes would only apply to the running instance and would be lost on shutdown. To make persistent changes, you must use virsh define, not virsh create.

Trap 3: Use virsh start guestname --validate to check the XML and start the…

The virsh start command does not have a --validate option that checks XML without starting. It will attempt to start the guest, which is not desired when you only want to verify the configuration. This option is invalid and would not perform the required validation-only action.

A
Use virsh undefine guestname then virsh define guest.xml to replace the configuration.
Why it fails: Undefining the guest removes its persistent configuration entirely, including any associated metadata. While you could then define a new one, this is destructive and unnecessary. It also risks losing the original configuration if the new XML is invalid. This is not an appropriate troubleshooting step for correcting XML errors.
B
Use virsh define /path/to/guest.xml to update the persistent domain definition from an edited XML file.
virsh define loads a new persistent configuration for the domain from the specified XML file. This is the correct way to apply changes to a guest's definition without starting it. It replaces the existing persistent definition, so you can correct errors and then start the guest when ready.
C
Use virsh edit guestname to modify the domain XML in place, which validates the XML before saving.
virsh edit opens the domain's XML in the default editor and validates it against the schema before saving. This allows you to fix configuration errors interactively. It updates the persistent definition, so it is a valid method to correct a guest's configuration without booting it.
D
Use virsh dumpxml guestname > guest.xml, edit the file, then run virsh create guest.xml to apply changes persistently.
Why it fails: virsh create starts a transient guest from the XML file, but it does not update the persistent definition. The changes would only apply to the running instance and would be lost on shutdown. To make persistent changes, you must use virsh define, not virsh create.
E
Use virsh start guestname --validate to check the XML and start the guest if valid.
Why it fails: The virsh start command does not have a --validate option that checks XML without starting. It will attempt to start the guest, which is not desired when you only want to verify the configuration. This option is invalid and would not perform the required validation-only action.

Question 6hardmultiple choice

You are troubleshooting a container networking issue. You notice that traffic from the container is not being SNATed. What should you check in the iptables rules?

Trap 1: nat table, PREROUTING chain

The nat table's PREROUTING chain handles DNAT for inbound traffic before routing, so it cannot SNAT outbound container packets. It is tempting because PREROUTING is the first nat hook, but SNAT for egress is applied in POSTROUTING after the routing decision, which is where the missing rule belongs.

Trap 2: filter table, FORWARD chain

The filter table's FORWARD chain only accepts, drops or rejects packets traversing the host; it performs no address translation. It is tempting because container traffic does traverse FORWARD, so counters there reveal whether packets pass, but SNAT rewriting itself occurs in the nat table's POSTROUTING chain.

Trap 3: mangle table, OUTPUT chain

The mangle table's OUTPUT chain alters packet headers for locally generated traffic before routing, and mangle never performs NAT. It is tempting because mangle can rewrite header fields, but source address translation for forwarded container traffic belongs in the nat table's POSTROUTING chain.

A
nat table, PREROUTING chain
Why it fails: The nat table's PREROUTING chain handles DNAT for inbound traffic before routing, so it cannot SNAT outbound container packets. It is tempting because PREROUTING is the first nat hook, but SNAT for egress is applied in POSTROUTING after the routing decision, which is where the missing rule belongs.
B
nat table, POSTROUTING chain
Source NAT for outbound container traffic is performed in the nat table's POSTROUTING chain, where MASQUERADE or SNAT rules rewrite the source address after routing. Inspecting this chain reveals whether the SNAT rule is present, correctly matched, or bypassed by an earlier rule.
C
filter table, FORWARD chain
Why it fails: The filter table's FORWARD chain only accepts, drops or rejects packets traversing the host; it performs no address translation. It is tempting because container traffic does traverse FORWARD, so counters there reveal whether packets pass, but SNAT rewriting itself occurs in the nat table's POSTROUTING chain.
D
mangle table, OUTPUT chain
Why it fails: The mangle table's OUTPUT chain alters packet headers for locally generated traffic before routing, and mangle never performs NAT. It is tempting because mangle can rewrite header fields, but source address translation for forwarded container traffic belongs in the nat table's POSTROUTING chain.

Question 7hardmultiple choice

You are troubleshooting a libvirt migration that fails with 'Operation not supported: Migration requires a storage pool'. You need to perform a block migration where the storage is copied to the destination host. Which command-line flag enables this functionality?

Trap 1: --live-disk

--live-disk is not a recognised virsh migrate flag, so the command fails before any storage transfer begins. It is tempting because the name suggests copying disk contents, but block migration is enabled with --block-migrate, which copies the guest's storage to the destination host.

Trap 2: --migrate-storage

libvirt's virsh has no --migrate-storage flag; storage migration is triggered by --migrate-disks or the --copy-storage-all/--copy-storage-inc options, which copy disk contents to the destination. The name suggests a generic storage-copy switch, so it looks plausible, but it would only be right if such a flag existed for selecting a named pool.

Trap 3: --block-migrate

virsh migrate exposes no --block-migrate flag; block migration is requested via --copy-storage-all (full copy) or --copy-storage-inc (incremental), which transfer the guest disks to the destination. The term matches the scenario's wording, making it tempting, but it would be correct only if libvirt named the option after the block-copy operation itself.

A
--copy-storage-all
--copy-storage-all copies every guest disk to the destination as part of the migration, removing the shared-storage requirement that triggered the error. This enables true block migration when the destination has no access to the source's storage pool.
B
--live-disk
Why it fails: --live-disk is not a recognised virsh migrate flag, so the command fails before any storage transfer begins. It is tempting because the name suggests copying disk contents, but block migration is enabled with --block-migrate, which copies the guest's storage to the destination host.
C
--migrate-storage
Why it fails: libvirt's virsh has no --migrate-storage flag; storage migration is triggered by --migrate-disks or the --copy-storage-all/--copy-storage-inc options, which copy disk contents to the destination. The name suggests a generic storage-copy switch, so it looks plausible, but it would only be right if such a flag existed for selecting a named pool.
D
--block-migrate
Why it fails: virsh migrate exposes no --block-migrate flag; block migration is requested via --copy-storage-all (full copy) or --copy-storage-inc (incremental), which transfer the guest disks to the destination. The term matches the scenario's wording, making it tempting, but it would be correct only if libvirt named the option after the block-copy operation itself.

Question 8hardmultiple choice

You are troubleshooting a performance issue and want to pin a VM process to specific physical CPU cores. Which XML element is used?

Trap 1: <pinning vcpu='0' cores='0'/>

libvirt's CPU pinning uses <vcpupin vcpu='0' cpuset='0'/>; <pinning> is not a recognised element, so the domain XML fails schema validation. It tempts because the name describes the intent, and pinning is genuinely the right technique when isolating vCPU threads from host scheduling jitter.

Trap 2: <cpu-pinning vcpu='0' cpu='0'/>

The real element is <vcpupin>, with a cpuset attribute listing host cores; <cpu-pinning> and its cpu attribute do not exist in the domain schema, so parsing fails. The hyphenated name reads naturally, and pinning is indeed correct when a latency-sensitive vCPU must stay on dedicated physical cores.

Trap 3: <affinity vcpu='0' host-cpu='0'/>

libvirt expresses pinning through <vcpupin vcpu='0' cpuset='0'/>; <affinity> with host-cpu is not part of the domain XML, so the definition is rejected. The term echoes scheduler affinity, and affinity is genuinely what you configure when binding vCPU threads to specific host cores.

A
<pinning vcpu='0' cores='0'/>
Why it fails: libvirt's CPU pinning uses <vcpupin vcpu='0' cpuset='0'/>; <pinning> is not a recognised element, so the domain XML fails schema validation. It tempts because the name describes the intent, and pinning is genuinely the right technique when isolating vCPU threads from host scheduling jitter.
B
<cpu-pinning vcpu='0' cpu='0'/>
Why it fails: The real element is <vcpupin>, with a cpuset attribute listing host cores; <cpu-pinning> and its cpu attribute do not exist in the domain schema, so parsing fails. The hyphenated name reads naturally, and pinning is indeed correct when a latency-sensitive vCPU must stay on dedicated physical cores.
C
<cputune><vcpupin vcpu='0' cpuset='0-1'/></cputune>
The cputune element with vcpupin binds a virtual CPU to a host cpuset, satisfying the pinning requirement. Placing it under cputune rather than cpu or numa distinguishes per-vCPU affinity from topology definitions or memory placement.
D
<affinity vcpu='0' host-cpu='0'/>
Why it fails: libvirt expresses pinning through <vcpupin vcpu='0' cpuset='0'/>; <affinity> with host-cpu is not part of the domain XML, so the definition is rejected. The term echoes scheduler affinity, and affinity is genuinely what you configure when binding vCPU threads to specific host cores.

Read the full DNS explanation →

Question 9mediummultiple choice

A system administrator is troubleshooting a container that cannot resolve DNS names for other containers on the same user-defined Docker bridge network. The container's /etc/resolv.conf points to 127.0.0.11. Which Docker feature is responsible for providing this DNS resolution?

Trap 1: The Docker daemon's --dns flag

The --dns flag allows specifying external DNS servers for containers, but it does not provide name resolution for other containers. It is used to override the default DNS settings. The presence of 127.0.0.11 in /etc/resolv.conf is specific to Docker's embedded DNS, not an external server configured via --dns.

Trap 2: A DNS server running in a separate container

While you can run a DNS server in a container, Docker's embedded DNS is built into the daemon and automatically provided. The address 127.0.0.11 is reserved for Docker's internal DNS, not for a user-run container. Therefore, a separate DNS container is not responsible for this resolution unless explicitly configured, which is not the default.

Trap 3: The host's systemd-resolved service

systemd-resolved is a host-level DNS resolver, but it is not used by containers by default. Containers have their own network namespace and do not automatically use the host's resolver. While the host may use systemd-resolved, the container's /etc/resolv.conf pointing to 127.0.0.11 indicates Docker's embedded DNS, not the host's service.

A
The Docker daemon's --dns flag
Why it fails: The --dns flag allows specifying external DNS servers for containers, but it does not provide name resolution for other containers. It is used to override the default DNS settings. The presence of 127.0.0.11 in /etc/resolv.conf is specific to Docker's embedded DNS, not an external server configured via --dns.
B
A DNS server running in a separate container
Why it fails: While you can run a DNS server in a container, Docker's embedded DNS is built into the daemon and automatically provided. The address 127.0.0.11 is reserved for Docker's internal DNS, not for a user-run container. Therefore, a separate DNS container is not responsible for this resolution unless explicitly configured, which is not the default.
C
Docker's embedded DNS server
Docker runs an embedded DNS server for user-defined networks, which listens on 127.0.0.11 and resolves container names and aliases. It allows containers on the same network to communicate using their names. This server is automatically configured in the container's /etc/resolv.conf. It is the correct mechanism for service discovery within a user-defined bridge network.
D
The host's systemd-resolved service
Why it fails: systemd-resolved is a host-level DNS resolver, but it is not used by containers by default. Containers have their own network namespace and do not automatically use the host's resolver. While the host may use systemd-resolved, the container's /etc/resolv.conf pointing to 127.0.0.11 indicates Docker's embedded DNS, not the host's service.