Hard Difficulty Questions

--path

Why it fails: --path is not a systemd-nspawn parameter; the root filesystem is specified with --directory or -D. The name suggests a filesystem location, which makes it tempting, but nspawn uses --directory for the container root, so passing --path triggers an unrecognised-option failure.

--root

Why it fails: systemd-nspawn has no --root switch; the root directory is set with --directory (or -D). --root resembles chroot-style naming, so it seems plausible, but it is not a recognised nspawn option and the command would fail with an unknown-parameter error.

-r

Why it fails: The -r short flag does not map to a root directory in systemd-nspawn; -D is the shorthand for --directory. Single-letter flags feel familiar from chroot and docker run, making -r tempting, but nspawn reserves -D for specifying the container's root filesystem path.

Shell

Why it fails: network-config accepts YAML (v1/v2) or ENI-style data, not shell scripts. Shell tempts because runcmd and bootcmd execute shell, but interface definitions need structured keys such as type, name and subnets, which shell cannot express declaratively.

INI

Why it fails: INI is used by cloud-config for some legacy formats, but network-config expects YAML or ENI-style network data. INI tempts because cloud-init's config files resemble INI sections, yet interface definitions require nested keys that INI cannot represent.

JSON

Why it fails: Cloud-init's network-config is YAML, the same serialisation used for user-data; JSON is accepted only as a subset because YAML parsers tolerate it. Choosing JSON is tempting since it is a familiar structured format, yet it cannot express the anchors and multi-document structure cloud-init expects for interface definitions.

config.env.set

Why it fails: Vagrant has no config.env.set method; that namespace does not exist, so the Vagrantfile would raise an error. It is tempting because the name reads like a natural setter for environment variables, and similar set-style methods do exist elsewhere in Vagrant's configuration API.

config.vm.env

Why it fails: config.vm.env does not exist in Vagrant's configuration API; environment variables for provisioners are supplied through the provisioner's env option or the shell provisioner's inline environment handling. It is tempting because vm is the namespace holding most machine settings, so an env key there appears logical.

vagrant.env.set

Why it fails: vagrant.env.set is not a Vagrantfile method; the vagrant namespace is not used for guest environment configuration. It is tempting because the vagrant prefix appears in CLI commands such as vagrant up, making a vagrant.env setter look like plausible configuration syntax.

Edit the domain XML and add <driver name='qemu' type='raw' cache='none' io='native'/> to the disk definition, then redefine the domain.

Why it fails: Changing the cache and I/O mode affects host page cache behavior and I/O scheduling, but it does not enable dirty-block tracking for migration. The disk remains a raw local LVM volume that the destination cannot access, so live migration would still fail or require a full disk copy. This XML change alone does not create the required shared storage visibility.

Convert the raw LVM volume to a qcow2 file with qemu-img convert -O qcow2, then start the migration.

Why it fails: Converting the volume changes the on-disk format but does not, by itself, enable dirty-block tracking for migration. The destination must still access the same storage path, and a local qcow2 file would require copying the entire image during migration. This action adds downtime and does not satisfy the requirement of transferring only dirty blocks after memory copy begins.

Run virsh domblkthreshold --domain guest --dev vda --threshold 0 to force libvirt to record writes.

Why it fails: domblkthreshold sets an event threshold for block device write notifications; it emits an event when the specified number of bytes is written, but it does not enable dirty-block tracking or change how migration copies data. It cannot make a raw LVM volume migrate incrementally, so the migration would still transfer the whole disk or fail if the destination cannot see the LUN.

cache=none

Why it fails: cache=none bypasses the host page cache and uses direct I/O, which makes the guest wait for the NFS server on every write. During an NFS stall, the guest I/O will block or fail immediately, worsening the reported errors. It is intended for workloads where data integrity is critical and the storage is reliable, not for tolerating network filesystem interruptions.

cache=unsafe

Why it fails: cache=unsafe ignores flush requests and may discard data even on local storage; while it can improve performance, it does not specifically address NFS stalls and risks data loss. It is not a recommended resilience setting for production guests, and it does not provide the controlled buffering that writeback offers for network-backed storage.

cache=directsync

Why it fails: cache=directsync uses direct I/O and only reports completion after data is on stable storage, similar to writethrough but with stricter semantics. This means every guest write waits for the NFS server, so transient outages will still cause immediate I/O errors. It is not suitable when the goal is to mask brief network filesystem interruptions.

virsh vol-list vmpool --create guest1 20G

Why it fails: vol-list only enumerates existing volumes in a pool and accepts no --create option or size argument. It is a read-only listing command, so it cannot provision storage. Using it here would produce an error and leave the requested 20 GB volume uncreated.

virsh vol-create-as vg_vms guest1.img 20G

Why it fails: vol-create-as creates a volume in a libvirt storage pool, but the pool name here would need to be the libvirt pool name, not the underlying LVM volume group. Additionally, logical pools create LVs, not .img files, so the naming and target are misleading and the command would target the wrong abstraction layer.

virsh pool-create-as vmpool logical 20G

Why it fails: pool-create-as defines and starts a new storage pool, not a volume inside an existing pool. Supplying 20G as a source argument is also invalid for a logical pool definition, which expects a source device or name. This command would attempt to create a pool rather than the required volume, so it fails the scenario.

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.

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.

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.

Use 'links' in the web service definition to point to the db service, and remove the shared network.

Why it fails: 'links' is a legacy feature that creates a one-way dependency and adds an entry to the web container's /etc/hosts, but it does not provide network-level isolation. The db container would still be on the same default network and could resolve and connect to the web container. Removing the shared network without defining a new one would break name resolution entirely, so this does not meet the requirement.

Attach the web container to a second user-defined network 'frontend_net', and attach the db container only to 'app_net'.

Why it fails: Adding a second network to the web container does not prevent the db container from reaching it on the shared 'app_net' network. Both containers would still have interfaces on 'app_net', and Docker's embedded DNS would resolve 'web' from the db container, allowing db to initiate connections. This approach expands connectivity rather than restricting it, so it does not satisfy the requirement.

Place the db container on an internal-only network and the web container on both the internal network and a frontend network.

Why it fails: An 'internal' network in Docker Compose prevents external access to the network, but it does not prevent containers on that network from communicating with each other. The db container could still reach the web container on the internal network. This configuration addresses external connectivity, not lateral movement between containers, so it fails to enforce the desired one-way restriction.

virsh save db1 /var/lib/libvirt/save/db1.save

Why it fails: The save command writes the domain's memory state to a file and stops the domain. It is a suspend-to-disk operation, not a snapshot, and the guest is no longer running afterward. It does not create a revertible snapshot while keeping the guest running, so it fails the scenario.

virsh snapshot-create-as db1 snap1 --memspec file=/var/lib/libvirt/save/db1.mem,snapshot=external

Why it fails: The --memspec option is used when defining an external snapshot that includes memory, but it requires the disk snapshot to also be external in the same command. Using it alone without --disk-only or an external disk specification produces a configuration error and does not create a valid state snapshot.

virsh snapshot-create-as db1 snap1 --disk-only

Why it fails: The --disk-only option creates a snapshot of the disk state only, excluding memory. While it works on a running guest, it does not capture RAM, so the guest cannot be reverted to the exact running state. The scenario requires memory state to be included.

Set the environment variable LOG_DIR=/var/log/app and expect the application to create it

Why it fails: Setting an environment variable does not create the directory or set its permissions. If the application attempts to create /var/log/app as a non-root user, it will fail because /var/log is typically owned by root and not writable by unprivileged users. The image must explicitly create the directory and assign ownership; relying on the application to do so is not a valid solution.

Add a VOLUME instruction for /var/log/app so the directory is writable at runtime

Why it fails: VOLUME creates an anonymous volume at runtime, but the ownership of the volume is typically root unless the image already has the directory owned by the non-root user. It does not change permissions or ownership, so the non-root user may still be unable to write. VOLUME also complicates image layering and is not the correct tool for setting directory ownership.

Use the --chown flag with a COPY instruction to copy a placeholder file into /var/log/app

Why it fails: The --chown flag on COPY sets ownership of copied files and their parent directory only if the parent directory is created by the copy. If /var/log/app already exists in a previous layer, COPY --chown may not change the directory ownership. This is unreliable and does not guarantee the directory is writable by the non-root user. A dedicated RUN chown is more explicit and predictable.

The Docker daemon's data-root directory is on a filesystem that is full.

Why it fails: If the data-root filesystem were full, the error would affect all containers and the daemon itself, not just one container. The scenario states the host has ample free disk space, so this is unlikely. While a full data-root can cause similar errors, the question specifies ample host space, pointing to a per-container limit rather than a host-wide issue.

The container image is corrupted and needs to be re-pulled.

Why it fails: A corrupted image typically results in checksum errors or failures during extraction, not 'no space left on device'. While re-pulling might resolve some issues, it does not address the specific error related to disk space. The error is about storage capacity, not data integrity, so image corruption is an incorrect diagnosis.

The overlay2 driver has run out of inodes on the host filesystem.

Why it fails: Running out of inodes would also produce 'no space left on device', but it would affect the entire filesystem, not just one container. The scenario says the host has ample free disk space, which usually implies both blocks and inodes are available unless specifically stated. Inode exhaustion is a host-wide condition, not container-specific, making this less likely than a per-container quota.

Move the Docker data directory to a filesystem with more free inodes by editing /etc/docker/daemon.json.

Why it fails: Changing the data-root in daemon.json can relocate Docker's storage, but it requires stopping the daemon and migrating existing data. It is a valid long-term solution if the original partition is too small, but it is not a direct fix for the immediate error and does not address the current filesystem's inode exhaustion without additional steps. It is more disruptive than necessary for the scenario.

Increase the size of the Docker container's writable layer by adding `--storage-opt size=10G`.

Why it fails: The `--storage-opt size` option is only supported by certain storage drivers like devicemapper and btrfs, and even then it sets a quota, not a way to increase available space. With overlay2, this option is not supported and will cause an error. It does not address the underlying partition or inode exhaustion issue on /var/lib/docker.

Restart the Docker daemon with `systemctl restart docker`.

Why it fails: Restarting the Docker daemon does not free disk space or inodes. It may temporarily clear some state, but the underlying filesystem remains full or inode-exhausted, so the container will still fail to start. This action does not resolve the root cause and is not a remedy for storage capacity issues.

Use the --cap-add=NET_BIND_SERVICE option when running the container.

Why it fails: In rootless Podman, adding capabilities within the container's user namespace does not allow binding to privileged ports on the host because the host's network namespace still enforces the unprivileged port restriction. The capability would only be effective if the container is in the host's network namespace and the user has the necessary privileges. Thus, this option alone is insufficient.

Run the container with the --privileged flag.

Why it fails: The --privileged flag gives the container full access to host devices and capabilities, but in rootless mode it does not grant the ability to bind to privileged ports because the user namespace still lacks the necessary capabilities in the initial namespace. The flag is also a security risk. For rootless port binding, adjusting the sysctl or using port forwarding is required instead.

Add the user to the docker group.

Why it fails: The docker group is specific to Docker and grants access to the Docker daemon socket, which is unrelated to Podman. Podman is daemonless and does not use a group for privileges. Adding a user to the docker group would not help with rootless Podman port binding and could introduce security risks. This option is incorrect for the scenario.

content_library_iso

Why it fails: content_library_iso is not a valid Packer configuration option. While the vsphere-iso builder supports content libraries, the correct option is not named this. Using an invalid option would cause a template parsing error or be ignored, leading to build failure.

iso_url

Why it fails: iso_url is used by builders like virtualbox-iso or qemu to download an ISO from a URL. The vsphere-iso builder does not use iso_url; it requires the ISO to be accessible on a datastore or content library. Specifying a URL would not work because the builder does not fetch remote ISOs.

iso_paths

Why it fails: iso_paths expects a list of datastore paths, such as '[datastore1] isos/ubuntu.iso'. It does not support content library item references. Using it would cause the builder to look for a file at the specified datastore path, which would fail if the ISO is only in the content library.

Reformatting the disk image

Why it fails: Reformatting the disk image destroys its filesystem contents, so the migrated data would be lost; manual migration copies the existing image intact. Formatting is a provisioning step for a fresh volume, not a migration one.

Updating the host kernel

Why it fails: The host kernel is independent of the guest's disk image, so updating it changes nothing about the migration itself. Kernel upgrades belong to host maintenance, not to moving a VM's storage between datastores or formats.

--mode force

Why it fails: Not a valid mode.

--mode hard

Why it fails: Not a valid mode (that's destroy).

Anonymous volume

Why it fails: Anonymous volumes receive a random hash name and are tied to a single container's lifecycle, so other containers cannot reference them reliably and Docker may prune them once no container uses them. They suit throwaway build caches, not shared persistent data.

Tmpfs

Why it fails: Tmpfs mounts live in host memory and vanish on container stop, so nothing survives container deletion and no second container can attach. Tmpfs suits sensitive scratch data, such as secrets or session files, that must never touch disk.

Bind mount

Why it fails: A bind mount maps an existing host path, so persistence depends on that directory rather than Docker managing the volume, and it is not a named volume shared by reference. Bind mounts suit injecting host config files or source code into containers.

<display model='qxl'/>

Why it fails: libvirt's video device is defined with a <video> element containing a <model type='qxl'/> child; <display> is not a valid domain XML element. The tempting model attribute appears in graphics or hostdev contexts, but the video emulation must sit inside <video> for QEMU to load the qxl driver.

<graphics type='qxl'/>

Why it fails: <graphics type='qxl'> is invalid because the graphics element accepts types such as spice, vnc or sdl, not qxl. It is tempting since qxl is display-related, but graphics defines the remote-access protocol, whereas the video device element declares the emulated adapter QEMU presents to the guest.

<device type='video' model='qxl'/>

Why it fails: libvirt domain XML has no generic <device type='video'> wrapper; video devices are declared as <video><model type='qxl'/></video>. The syntax is tempting because other devices use type attributes, but the schema rejects this form, so QEMU never receives the qxl model.

--shared-storage

Why it fails: No --shared-storage flag exists in virsh migrate; libvirt rejects it. When hosts share storage, the default migration already transfers only memory state, so no extra option is needed. The name is tempting because it describes the NFS setup, but the flag is not part of the virsh migrate syntax.

--migrate-memory-only

Why it fails: virsh migrate has no --migrate-memory-only option, so the command fails with an unrecognised argument. With shared storage, memory-only transfer is already the default behaviour. The name is tempting because it restates the requirement, but libvirt exposes no such flag; storage handling is controlled by --copy-storage-all or similar.

--unsafe

Why it fails: The --unsafe flag merely skips safety checks and forces migration to proceed even when it might fail; it does not control which state is transferred. It tempts because it sounds like a way to bypass storage copying, but shared NFS storage already means --live alone transfers only memory.

#!/bin/bash

Why it fails: cloud-config files must begin with #cloud-config; #!/bin/bash marks a shell script, which cloud-init treats as a user-data script, not cloud-config. The shebang tempts because it is the correct choice for executable user-data scripts, but YAML cloud-config directives require the #cloud-config header instead.

#cloud-init

Why it fails: cloud-init matches the exact header #cloud-config; #cloud-init is not a recognised marker, so the file is treated as a plain script and no config modules run. It is tempting because cloud-init is the tool's name, yet that header belongs to no valid user-data format.

---

Why it fails: A leading --- denotes a YAML document start, not the cloud-config marker cloud-init scans for; without #cloud-config the payload is ignored as user-data. It is tempting as valid YAML syntax, and would be correct inside a MIME multipart archive preceding a config part.