LPIC-3 Exam 305: Virtualization and Containerization (305-300) (305-300) (305-300) — Questions 151–210

The -d flag detaches the container, running it in the background and returning the container ID to the shell. This satisfies the detached-mode requirement, unlike -it which attaches an interactive TTY to the foreground process.

`lxc-snapshot -n container_name` invokes the LXC snapshot utility against the named container, capturing the root file system state through the container's backing storage. It satisfies the stem's requirement to snapshot an LXC container's root file system directly, without manual copy or export steps.

NUMPROC directly caps the process count within an OpenVZ container, satisfying the requirement to limit process creation. Set in the container configuration file, it enforces this per-container barrier independently of host-wide limits, unlike CPU or memory parameters that govern different resources entirely.

The dir pool type stores volumes as ordinary files within an existing host directory, and libvirt supports it natively alongside disk, logical, iSCSI, and similar backends. It satisfies the stem's requirement for a valid libvirt storage pool type.

The `-D` flag sets the container's root directory, satisfying the requirement to specify a different root filesystem. It accepts a path to a directory tree or image, which systemd-nspawn then uses as the container's root, rather than defaulting to a machine-name-derived location under `/var/lib/machines`.

An image is an immutable, layered filesystem template stored locally or in a registry; a container instance is that image instantiated as a running process with a writable layer. This template-versus-process distinction directly answers the stem's request for the primary difference.

virsh shutdown sends an ACPI shutdown signal to the guest, requesting a graceful shutdown. The guest OS will then initiate its normal shutdown process, closing services and unmounting filesystems. This is the correct way to gracefully shut down a guest. It requires that the guest OS supports ACPI and has the necessary drivers, which is typical for modern operating systems.

ENTRYPOINT sets the executable that runs when the container starts, satisfying the stem's requirement. Unlike CMD, which supplies default arguments that a docker run command can override, ENTRYPOINT fixes the process itself, with CMD values passed to it as parameters.

The kvm kernel module provides the hardware-assisted virtualisation layer, exposing Intel VT-x or AMD-V extensions to userspace so guests execute near-natively. Without it, QEMU falls back to slow software emulation, failing the stem's requirement for a genuine KVM environment. It is the foundational component every other KVM tool depends upon.

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.

`docker logs [container]` retrieves stdout and stderr captured by the container's configured logging driver, streaming them to your terminal without entering the container. This satisfies the scenario's requirement to view a running container's logs directly, since Docker retains that output for the container's lifetime.

Combining update, install and cache removal in a single RUN layer prevents apt metadata persisting in the final image, directly satisfying the minimise-image-size constraint. Separate instructions would each commit a layer, retaining the lists irreversibly. The `rm -rf` executes before the layer is committed, so nothing is left behind.

virsh start instructs libvirt to boot a previously defined but inactive domain, matching the requirement to start an already-defined VM. Alternatives such as virsh define or create either register or transiently launch domains rather than starting a persistent definition.

The virsh net-define subcommand parses the supplied XML and registers a persistent libvirt network definition without starting it, satisfying the requirement to define a new network from net.xml. It creates the configuration only; a separate net-start is needed to activate it.

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.

The openstack post-processor authenticates to the OpenStack APIs and uploads the built artefact to Glance, registering it as an image. It is the only post-processor type that targets Glance directly, satisfying the requirement to publish the Packer output there.

The `<driver>` element specifies the hypervisor's disk image format and backend, here qemu with qcow2. This satisfies the stem's requirement for an XML element defining a virtual disk, since libvirt uses `<driver>` within the disk device to declare how the storage is presented and handled.

Docker inspect returns the container's full configuration as JSON, including the NetworkSettings object with IP address, gateway, MAC address, port bindings and connected networks. That directly satisfies the stem's requirement to inspect container network settings, unlike commands that only list or alter them.

Rocket runs application containers grouped as pods, using a pluggable execution stage and signature-verified images to isolate workloads securely. This pod-centric, pluggable design satisfies the scenario's requirement for running pods in a secure, pluggable manner, distinguishing it from single-container runtimes.

Manual migration requires the target host's domain XML to reference the copied disk's new path and correct host-specific devices. Editing that XML on the target is therefore a necessary step before the domain can be redefined and started there.

docker inspect returns detailed JSON metadata about a container, including its network settings (IP address), environment variables, mounts, and much more. It is the primary tool for retrieving low-level configuration and runtime information. The output can be filtered with --format to extract specific fields. This command satisfies all the requirements in the scenario with a single invocation.

`docker history` reads an image's manifest and prints each layer with its ID, size and originating instruction, directly satisfying the requirement to show layer history. Unlike `docker inspect`, which returns JSON metadata about the whole image, it enumerates the individual build steps, making it the precise command for this scenario.

`virsh dumpxml webserver` queries the libvirt daemon and outputs the full XML definition of the running domain named webserver, satisfying the requirement to display its live configuration. Unlike editing commands, it is read-only, and unlike `virsh list`, it returns the complete XML rather than a summary.

A bind mount maps an existing directory on the host directly into the container. Data written by the container appears immediately in that host directory, and it persists independently of the container lifecycle. This satisfies both requirements: data survives container removal and is directly accessible on the host filesystem without needing Docker-specific tools to locate it.

Named volumes are stored outside the container's writable layer, under Docker's managed volume directory, so data survives container deletion and can be mounted by several containers simultaneously via the same volume name — satisfying both the sharing and persistence constraints in the stem.

Using RUN to delete cache files in the same layer where they were created ensures the files are not persisted in the final image. If the deletion occurs in a separate RUN instruction, the cache files remain in the earlier layer and still contribute to the image size. Combining installation and cleanup in a single RUN instruction is the recommended practice.

Pinning the vCPU to CPU 2 with vcpupin, together with host kernel parameters isolcpus=2 and nohz_full=2, removes CPU 2 from the general scheduler and reduces timer interrupts. This provides true isolation, ensuring the guest's vCPU has a dedicated core with minimal host interference, which is essential for low-latency real-time workloads.

docker history displays the intermediate layers of an image along with the commands that created them, their sizes, and creation timestamps. It provides a concise view of the image's build history, which is exactly what is needed to understand how the image was constructed. This command is specifically designed for this purpose and is the correct choice.

The cloud-init log records each module's execution and any YAML parsing errors encountered while processing user-data, including write_files failures. Examining it reveals the exact syntax or schema fault, which the instance console output and syslog do not capture in equivalent detail.

The Dockerfile supplies the declarative build instructions — base image, RUN commands, COPY directives and ENTRYPOINT — that docker build executes layer by layer. It defines the image contents, satisfying the requirement to specify how the container image is constructed.

The `<video>` element with a nested `<model type='qxl'/>` correctly defines the QEMU video device in the domain XML, satisfying the requirement to enable the qxl emulated display adapter. The `type` attribute selects the specific emulation model, so libvirt passes `-vga qxl` to QEMU and resolves the display bug.

This configuration sets the box to ubuntu/jammy64 and defines a forwarded port mapping from host port 8080 to guest port 80. The syntax uses the network forwarded_port option with guest and host parameters, which is the standard Vagrant way to forward ports. It directly satisfies the requirement for a single VM with the specified box and port forwarding.

Sparse files let QCOW2 allocate host disk blocks only as guest data is actually written, so a large virtual disk consumes minimal physical storage initially. This satisfies the question's benefit criterion by avoiding pre-allocation of the full virtual size, unlike raw images.

overlay2 is a valid Docker storage driver that stacks image layers using the OverlayFS union filesystem, supporting copy-on-write between lower and upper directories. It is the default and recommended driver on modern Linux hosts, making it a legitimate answer for managing image layers.

CAP_NET_BIND_SERVICE allows a non-root process to bind to ports below 1024, including port 80. In rootless Podman, the container process runs as an unprivileged user on the host, so without this capability the bind to port 80 fails with a permission denied error. Adding this capability via --cap-add=NET_BIND_SERVICE grants exactly the needed privilege while keeping the rest of the container unprivileged.

`qemu-img create` provisions a new, empty virtual disk image, defining its format (qcow2, raw) and virtual size without attaching it to a running guest. This satisfies the stem's disk image management requirement by creating the image file itself, distinct from runtime operations such as snapshotting or live migration.

The runcmd module executes arbitrary shell commands during instance initialisation, after other cloud-init stages complete. Commands are listed in the cloud-config under 'runcmd' and run in order, letting administrators perform custom configuration beyond the built-in modules.

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.

docker info queries the daemon directly, returning host-wide details such as storage driver, kernel version, CPU and memory totals, and running container counts. This satisfies the stem's system-wide scope, unlike docker version, which reports only client and server version numbers.

The packages module is a standard cloud-init module that installs listed packages during first boot, satisfying the stem's requirement for a genuine cloud-init module. It runs in the config stage and is distinct from bootcmd or write_files, which handle commands and file content instead.

name is the mandatory identifying directive within cloud-init's users section, specifying the account to create or modify. It satisfies the stem by being a core valid user-configuration key, required whenever a user entry is defined.

`--network host` places the container directly in the host's network namespace, so its interfaces and packet-capture capabilities are the host's own. This satisfies the stem's requirement for direct namespace access, unlike bridge or overlay networks, which isolate the container behind NAT and a separate stack.

virsh shutdown issues an ACPI shutdown signal to the guest, letting the domain's operating system terminate cleanly and flush buffers. This satisfies the graceful requirement, unlike virsh destroy, which cuts power abruptly and risks filesystem corruption.

The -d flag detaches the container, running it in the background so the terminal returns immediately instead of attaching to the process output. This matches the stem's requirement precisely; without it, docker run stays in the foreground.

Quick Emulator accurately expands the QEMU acronym, matching the virtualisation tool that performs hardware emulation and dynamic binary translation. This satisfies the stem's requirement for the correct expansion, distinguishing it from unrelated terms such as queue management or quality metrics.

ENTRYPOINT defines the fixed executable launched when the container starts, letting the image run as a self-contained command. Unlike CMD, its arguments are not overridden by docker run parameters, so the container behaves as the packaged application itself.

Hardware-assisted virtualization uses Intel VT-x or AMD-V extensions, letting guest instructions execute directly on the CPU rather than through binary translation. This satisfies the stem's requirement for a key QEMU-KVM feature, since KVM operates as a Linux kernel module exposing these CPU virtualisation extensions to QEMU virtual machines.

virsh pool-refresh isos rescans the pool's underlying storage, updating libvirt's record of available volumes without restarting the pool. It satisfies the stem's refresh requirement directly, unlike pool-start, which activates an inactive pool, or pool-info, which only reports status.

vzctl set applies configuration changes to a running or stopped OpenVZ container from the host, and the --hostname parameter sets the container's hostname directly. This avoids entering the container, satisfying the requirement to configure it from the host.

The primary configuration file.

The json-file driver writes each container's stdout/stderr to JSON files and honours max-size and max-file options, capping both individual file size and retained file count. This directly satisfies the stem's requirement to limit log number and size.

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.

Container orchestration platforms schedule containers onto nodes and manage their lifecycle automatically, satisfying the stem's requirement for automated deployment. The scheduler evaluates resource requests, affinity rules and node health before placing workloads, then restarts or reschedules failed containers without manual intervention, which is precisely the automation the question asks about.

pool-start activates a previously defined but inactive libvirt storage pool, making its volumes available to guests. It is a genuine lifecycle command, complementing pool-destroy, and satisfies the stem's request for valid storage pool lifecycle operations.

xl migrate initiates live migration of the named domain to the target host, coordinating the transfer and preparing the destination to receive it. This is the standard Xen toolstack command, resolving the domain lock error caused by an unprepared target.

Placing COPY requirements.txt before RUN pip install allows Docker to cache the dependency layer. When only app.py changes, the cached pip install layer is reused, drastically speeding up rebuilds. Copying the rest of the source after the RUN ensures that source changes do not invalidate the dependency installation layer, which is the core optimization for build caching.

docker ps -q lists only the IDs of running containers, and command substitution feeds that list to docker stop, halting each one. This satisfies the stem's requirement to stop all running containers in a single command.

The --all flag overrides pool-list's default behaviour of showing only active pools, causing libvirt to enumerate every defined storage pool regardless of state. Without it, inactive pools remain hidden, so this satisfies the stem's requirement to include inactive entries.

The amazon-ebs builder provisions an EC2 instance, runs provisioners against it, then stops it and creates an Amazon Machine Image (AMI) from the resulting EBS snapshot. This directly satisfies the requirement for an AWS-specific image, producing a native AMI rather than a generic artefact requiring later conversion.

The hostdev element with mode='subsystem' and type='usb' passes the physical USB device through to the guest, matching vendor and product IDs in hexadecimal. This satisfies the requirement to hand the specific 1234:5678 device to the VM.