How many Troubleshooting Scenario Questions questions are on this page?

This page has 14 Troubleshooting Scenario Questions scenario questions for the 305-300 exam, each with detailed explanations and wrong-answer analysis.

How should I approach 305-300 scenario questions?

Read the full scenario before looking at the answer options. Identify the constraint or requirement in the scenario, then eliminate options that are generally true but wrong for this specific case. Scenario questions reward careful reading over pattern matching.

← Back to LPIC-3 Exam 305: Virtualization and Containerization (305-300) (305-300) questions

Scenario-based practice

Troubleshooting Scenario Questions

Practise LPIC-3 Exam 305: Virtualization and Containerization (305-300) (305-300) practice questions — original exam-style scenarios covering every exam domain, with detailed explanations, wrong-answer analysis, and common exam traps.

Start full practice test Read exam guide

scenario questions

305-300

exam code

LPI

vendor

Scenario guide

How to approach troubleshooting scenario questions

These questions describe a network symptom and ask you to identify the root cause or the correct fix. They appear across all certification exams and reward systematic thinking over memorisation. The best candidates follow a consistent troubleshooting framework even under time pressure.

Quick answer

Troubleshooting Scenario Questions questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Practice scenarios

Question 1hardmultiple choice

Full question →

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?

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.

Full breakdown with real-world context →

Question 2hardmultiple choice

Full question →

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?

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.

Full breakdown with real-world context →

Question 3mediummultiple choice

Full question →

A KVM host runs a Windows guest whose virtual disk is backed by a raw image file on an NFS mount. After a host reboot, the guest fails to start with 'Permission denied' on the disk path, although the file exists and is readable by root. The host uses SELinux enforcing mode. Which action resolves the problem?

A
Add 'security_driver = "none"' to /etc/libvirt/qemu.conf and restart libvirtd.
Why it fails: Disabling the security driver removes SELinux confinement from all guests on the host, which is a broad, unnecessary weakening of the host's security posture. It would mask the symptom but is not the correct or proportionate fix for a single NFS-backed disk. The intended, targeted control is the virt_use_nfs boolean, which grants only the needed access.
B
Change the disk image ownership to 'qemu:qemu' with 'chown qemu:qemu' on the NFS-mounted file.
Why it fails: Ownership is not the blocker here because the error is an SELinux denial, and the file is already readable by the user that needs it. Changing ownership on an NFS export also depends on the export's root-squash and idmap settings, so the chown may silently fail or be ineffective. It does not address the confinement policy that denies NFS access to the QEMU process.
C
Set the SELinux boolean 'virt_use_nfs' with 'setsebool -P virt_use_nfs on'.
libvirt's QEMU process runs as a confined domain, and by default it is not permitted to access NFS-mounted storage. The virt_use_nfs boolean grants that access, and the -P flag makes it persistent across reboots. Enabling it lets the guest start immediately without relabeling files or disabling SELinux, which is the least-disruptive correct fix for this scenario.
D
Run 'restorecon -R -v /var/lib/libvirt/images' to reset file contexts on the local image directory.
Why it fails: restorecon resets SELinux contexts based on the local file-context policy for the path, but the image lives on an NFS mount, not under /var/lib/libvirt/images. Running it against the local directory changes labels on unrelated files and leaves the NFS-backed image with the wrong context, so the guest still cannot open the disk and the Permission denied error persists.

Full breakdown with real-world context →

Question 4hardmultiple choice

Full question →

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?

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.

Full breakdown with real-world context →

Question 5hardmultiple choice

Full question →

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?

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.

Full breakdown with real-world context →

Question 6mediummulti select

Full question →

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

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.

Full breakdown with real-world context →

Question 7hardmultiple choice

Full question →

A Packer template targets the qemu builder to produce a KVM-compatible image. The build completes without error, but when the resulting qcow2 file is booted with `qemu-system-x86_64 -drive file=image.qcow2,if=virtio`, the guest kernel panics with "VFS: Unable to mount root fs" because it cannot see any block device. The template defines only `iso_url`, `iso_checksum`, `ssh_username`, and `ssh_password`. Which change to the template is MOST likely to resolve this?

A
Add a `boot_command` that boots the installer with `inst.modprobe=virtio_blk` (or install a kernel/initramfs that includes the virtio_blk module) so the guest can see the virtio disk.
The kernel panic occurs because the guest initramfs has no virtio_blk driver, so the root filesystem on the virtio disk is invisible. Injecting the module via the installer boot command, or ensuring the installed initramfs includes it, lets the kernel enumerate the disk and mount root. This is the standard fix when a KVM image built by Packer fails to boot under `-drive if=virtio`.
B
Add `disk_interface = "virtio"` to the builder's configuration so the disk controller matches the boot command line.
Why it fails: The Packer qemu builder already defaults to virtio for disks and does not expose a `disk_interface` option; the disk is attached as virtio-blk by default. Adding an unsupported key either triggers a validation error or is silently ignored. The real problem is inside the guest, where the initramfs lacks the virtio_blk module, so changing the builder cannot fix it.
C
Add `qemuargs = [["-device", "virtio-blk-pci"]]` to force an explicit virtio controller during the build.
Why it fails: The build already attaches a virtio disk, so forcing another `-device virtio-blk-pci` duplicates the controller and can fail with a PCI slot or device-id conflict. Even if the build succeeds, the resulting image is identical to the one that panics. The missing piece is the guest-side driver, not an additional QEMU device argument.
D
Set `format` to `raw` so the disk is written as a plain image instead of qcow2.
Why it fails: The qcow2 container is not what hides the disk from the kernel; QEMU presents the same virtual hardware regardless of the on-disk format. Switching to raw only changes how the file is stored and loses qcow2's thin-provisioning and snapshot benefits. The guest still receives a virtio-blk device it has no driver for, so the panic persists.

Full breakdown with real-world context →

Question 8hardmultiple choice

Full question →

You are using Packer to build an image for a private cloud. The build uses the 'qemu' builder and a 'shell' provisioner. The provisioner script runs but fails to install a package because the package repository is unreachable. You suspect the VM has no network connectivity during provisioning. Which Packer feature should you verify to ensure the VM has network access?

A
The 'accelerator' setting in the qemu builder configuration.
Why it fails: The 'accelerator' setting controls hardware acceleration (e.g., KVM, TCG) for the VM. It affects performance, not network connectivity. Even with acceleration enabled, the VM could still have no network access if the network device is not properly configured. This setting is unrelated to the provisioning network issue.
B
The 'http_directory' setting in the builder configuration.
Why it fails: The 'http_directory' setting is used to serve files over HTTP to the VM during the build, typically for kickstart or preseed files. It does not provide network connectivity to the VM itself. Even if the HTTP server is running, the VM must have its own network access to reach external repositories.
C
The 'net_device' setting in the qemu builder configuration.
In the qemu builder, the 'net_device' setting specifies the network device model and can also configure the network backend. If it is set to 'none' or misconfigured, the VM will have no network connectivity. By default, Packer configures a user-mode network, but if overridden, the VM may lack access. Verifying this setting ensures the VM can reach external repositories.
D
The 'communicator' setting in the builder configuration.
Why it fails: The 'communicator' setting determines how Packer connects to the VM (e.g., SSH or WinRM) to run provisioners. It does not control the VM's network access to external resources. A working communicator only means Packer can execute commands, but the VM itself might still lack internet connectivity for package downloads.

Full breakdown with real-world context →

Question 9mediummultiple choice

Full question →

A Docker container running a web server is unable to serve traffic on port 8080. You verify the Dockerfile exposes port 80. What is the correct way to map this for external access?

A
docker run -p 80:8080
Why it fails: -p 80:8080 maps host port 80 to container port 8080, but the server listens on 80 inside the container, so traffic reaches nothing. It is tempting because 8080 is the failing external port, yet the mapping order is host:container, giving -p 8080:80.
B
docker run -p 8080:80
The -p 8080:80 flag publishes host port 8080 to container port 80, where the web server actually listens per the Dockerfile. EXPOSE alone only documents the port; explicit publishing is required for external access, satisfying the stem's mapping requirement.
C
docker run --net host
Why it fails: --net host removes port mapping entirely, sharing the host network namespace so the container binds host port 80, not 8080. It is tempting as a way to bypass NAT, but the requirement is publishing container port 80 on host port 8080 via -p 8080:80.
D
docker run --expose 8080
Why it fails: --expose only documents a port inside the container's network namespace; it publishes nothing to the host, so external clients still cannot reach 8080. It is tempting because --expose is genuinely used to declare ports for inter-container links, but publishing requires -p host:container.
E
docker run -P 8080
Why it fails: -P publishes all EXPOSEd ports to random host ports; passing 8080 as an argument is invalid syntax and does not map host 8080 to container 80. It tempts because -P does publish ports automatically, which suits throwaway containers where the assigned host port is irrelevant.

Full breakdown with real-world context →

Question 10hardmultiple choice

Full question →

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?

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.

Full breakdown with real-world context →

Question 11hardmultiple choice

Full question →

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?

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.

Full breakdown with real-world context →

Question 12hardmultiple choice

Full question →

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

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.

Full breakdown with real-world context →

Question 13hardmultiple choice

Full question →

You are using Packer to build a KVM-compatible QEMU image for an on-premises OpenStack cloud. The build completes successfully, but the resulting image fails to boot because the virtual disk is not recognized. You verify that the QEMU builder is configured with accelerator 'kvm' and the correct machine type. Which QEMU builder option should you review to ensure the disk image is created in a format that OpenStack can use?

A
net_device
Why it fails: The net_device option specifies the network device model presented to the guest, such as virtio-net or e1000. It affects network performance and driver compatibility, not disk image format. While important for networking, it does not influence whether OpenStack can boot the disk. Therefore it is irrelevant to the described disk recognition failure.
B
format
The format option in the QEMU builder defines the output disk image format, such as qcow2 or raw. OpenStack Glance commonly requires qcow2 for KVM-based instances. If the format is set incorrectly, the image may not be recognized. Reviewing and setting format to qcow2 ensures compatibility with OpenStack's default disk format expectations.
C
disk_image
Why it fails: The disk_image option in the QEMU builder specifies whether to create a disk image instead of using a raw disk. It does not control the output format. Setting it to true creates a disk image file, but the format is determined by other options. It is not the primary setting for ensuring OpenStack compatibility, as the format must match what Glance expects.
D
headless
Why it fails: The headless option controls whether QEMU runs without a graphical display. It is useful for automation but has no impact on disk image format or bootability. Setting it to true simply suppresses the GUI. It does not affect how the virtual disk is created or whether OpenStack can use it, so it is not the correct option to review.

Full breakdown with real-world context →

Question 14mediummultiple choice

Read the full DNS explanation →

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?

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.

Full breakdown with real-world context →

These 305-300 practice questions are part of Courseiva's free LPI certification practice question bank. Courseiva provides original exam-style 305-300 questions with detailed explanations, topic-based practice, mock exams, readiness tracking, and study analytics.

Troubleshooting Scenario Questions

How to approach troubleshooting scenario questions

Quick answer

Related 305-300 topic practice pages

Full Virtualization practice questions

Container Virtualization practice questions

VM Deployment And Provisioning practice questions

305-300 fundamentals practice questions

305-300 scenario practice questions

305-300 troubleshooting practice questions

Practice scenarios

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?

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?

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

A Docker container running a web server is unable to serve traffic on port 8080. You verify the Dockerfile exposes port 80. What is the correct way to map this for external access?

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?

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?

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

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?