Full Virtualization practice questions

-remote 192.168.1.50:4444

Why it fails: QEMU has no -remote argument; migration is driven by -incoming on the destination and the migrate monitor command on the source. It is tempting because it reads like a direct host pointer, and would fit a tool exposing an explicit remote-target flag.

-live-migrate 192.168.1.50:4444

Why it fails: This is not a valid QEMU argument.

-incoming tcp:192.168.1.50:4444

Why it fails: -incoming configures the destination to accept a migration; it does not initiate one from the source host. It is tempting because it names the correct tcp:host:port syntax, and would be right on the receiving machine listening for the incoming stream.

--shared-storage

Why it fails: --shared-storage tells libvirt the disk is already accessible on both hosts, so it skips disk transfer; it does not copy RAM. It is tempting for shared-storage migrations, where the disk need not move and only memory state transfers.

--migrate-disk

Why it fails: The `--migrate-disk` flag controls storage migration, copying disk images between hosts rather than transferring the guest's RAM contents. Live memory transfer over the network is handled by the default live migration path, or explicitly via `--live` combined with a transport such as `--p2p` or `--tunnelled`. `--migrate-disk` suits shared-nothing storage relocation scenarios.

--memory-copy

Why it fails: This flag does not exist in virsh.

/var/lib/libvirt/network/default.xml

Why it fails: The network's persistent XML stores configuration such as the bridge name, DHCP range and forward mode, not the runtime iptables chains libvirt creates. It is tempting because it defines the NAT network itself, and would be the right file to edit to change the network's forward mode or addressing.

/etc/sysconfig/network-scripts/ifcfg-virbr0

Why it fails: This file defines the bridge interface, not the NAT rules.

/etc/iptables/rules.v4

Why it fails: This file holds rules saved by the iptables-persistent package at boot, which libvirt does not write to; libvirt's NAT rules live in its own network XML and runtime chains. It is tempting as the standard place for persisted firewall rules, and would be correct for inspecting administrator-saved rules on Debian.

qemu-img create -f qcow2 -b image.qcow2 snapshot.qcow2

Why it fails: The -b flag creates a new overlay backed by image.qcow2, but that is a fresh disk, not a point-in-time snapshot of the running VM's current state. It tempts because backing files do enable copy-on-write chains, which suit provisioning derived disks rather than live snapshots.

qemu-img snapshot -c snapshot_name image.qcow2

Why it fails: qemu-img snapshot -c writes an internal snapshot into the image file, which requires the image to be inactive; it cannot capture a running VM. It tempts because it is the literal snapshot sub-command, and would be correct for an offline image.

virsh checkpoint-create vm_name

Why it fails: virsh checkpoint-create captures internal VM snapshots for incremental backup, not disk-image snapshots. It is tempting because it snapshots a running domain without downtime, but it operates on libvirt checkpoint metadata, not the QCOW2 file itself; qemu-img snapshot is the correct sub-command.

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

/etc/sysconfig/network-scripts/ifcfg-br0

Why it fails: This is for RHEL-based systems.

/etc/libvirt/qemu/networks/br0.xml

Why it fails: This file defines a virtual network, not the host interface.

SIGINT

Why it fails: SIGINT requests graceful termination, which QEMU may intercept and handle without exiting. 'virsh destroy' instead sends SIGKILL, immediately terminating the guest without shutdown. SIGINT would be tempting when you want a process to attempt orderly cleanup, such as interrupting a foreground command, but it cannot guarantee the forced stop this scenario requires.

SIGHUP

Why it fails: SIGHUP is a hangup signal used to reload configuration or terminate a process when its controlling terminal closes; it does not stop a QEMU guest. 'virsh destroy' sends SIGKILL, immediately terminating the domain. SIGHUP would be relevant for restarting a daemon after config changes, not for forcibly powering off a virtual machine.

SIGTERM

Why it fails: SIGTERM requests graceful termination, which QEMU may intercept to shut down the guest cleanly, so it does not match `virsh destroy`'s forced stop. It is tempting because SIGTERM is the conventional polite signal for stopping daemons, and would suit a graceful shutdown command such as `virsh shutdown`.

virsh show-console vm_name

Why it fails: Not a valid command.

virsh view vm_name

Why it fails: Not a valid command.

<disable-dns/>

Why it fails: disable-dns is not part of the libvirt network schema, so the definition is rejected rather than disabling anything. It tempts as an intuitive toggle, but DNS is disabled by removing the <dns> element (or its forwarder entries) from the network definition.

<service name='dns' enabled='no'/>

Why it fails: No service element with a dns name and enabled attribute exists in the libvirt network schema, so libvirt rejects the definition. It tempts because it resembles systemd-style service toggles, whereas DNS is controlled by the presence or absence of the <dns> element itself.

<forward mode='bridge' dns='no'/>

Why it fails: The forward element accepts only mode, dev and managed attributes; dns='no' is invalid and the network fails to define. It tempts because forward mode='bridge' genuinely configures bridging, but DNS suppression is achieved by omitting the <dns> element rather than an attribute here.

A static IP for the VM

Why it fails: IP addressing is independent of migration.

A local disk file on the destination

Why it fails: Local disks would require a manual copy of the image.

virsh set-boot-auto vm_name

Why it fails: Not a valid command.

virsh config-start vm_name

Why it fails: Not a valid command.

switch

Why it fails: A libvirt virtual network offers bridge, NAT, routed, isolated and open modes — not "switch", which names a Layer 2 device rather than a libvirt network mode. It is tempting because switching describes how bridged networks forward frames between guests and the physical LAN, so a bridge-mode network would be the correct selection here.

peer

Why it fails: Not a libvirt network mode.

router

Why it fails: libvirt defines bridge, NAT, routed, isolated and open modes; "router" is not one of them, so it cannot be selected. It tempts because a routed libvirt network does forward traffic between subnets, but the mode is named "routed", not "router".

Identical network card models

Why it fails: Live migration abstracts virtual NICs, so the guest sees the same emulated or virtio device regardless of the physical card in each host; identical models are unnecessary. Matching NIC models would matter for bare-metal failover or bonding configurations, not for KVM live migration between hosts.

Matching guest kernel versions

Why it fails: Live migration transfers the running guest's memory and CPU state; the guest kernel runs unchanged on the destination, so kernel versions need not match. Matching kernels would be relevant when rebuilding or redeploying a guest, not when migrating a live domain between hosts.

virtio-keyboard

Why it fails: virtio-keyboard is not a defined virtio device type; input is handled through virtio-input with keyboard as a sub-type. It tempts because keyboards are common emulated devices, and virtio-input would be the correct choice when passing keyboard events to a guest.

virtio-mouse

Why it fails: virtio-mouse is not a defined virtio device type; pointer input is handled through virtio-input with mouse as a sub-type. It tempts because mice are common emulated devices, and virtio-input would be correct when passing pointer events to a guest.

Hub-based switching

Why it fails: Hub-based switching is not a valid VM networking configuration; virtual switches, bridged, NAT and host-only modes are. It tempts because 'hub' evokes physical network topologies, but hypervisors implement virtual switches, not hub-based forwarding, for VM connectivity.

VLAN tagging on bridge

Why it fails: libvirt has no bridge VLAN-tagging option; VLANs are configured on the host bridge itself or via a vlan interface, not as a VM networking mode. It is tempting because VLAN tagging genuinely isolates guest traffic, and would be right when segmenting VMs at layer 2 on a shared bridge.

Direct routing

Why it fails: Direct routing is not a libvirt network mode; libvirt offers bridge, NAT, routed, isolated, and macvtap. It is tempting because routed networking forwards traffic between subnets without NAT, which suits environments where guests need externally routable addresses on separate subnets.

--mode force

Why it fails: Not a valid mode.

--mode hard

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

virsh pool-mount

Why it fails: virsh has no pool-mount sub-command; pools are started with pool-start and stopped with pool-destroy. It is tempting because mounting describes attaching storage, and filesystem-level mounts exist, but virsh manages pools through define, build, start, destroy and delete verbs instead.

virsh pool-resize

Why it fails: pool-resize changes a pool's capacity allocation, not its definition, so it cannot create, define, start or destroy pools. It is tempting because resizing is genuine virsh pool management, and it would be the right subcommand when a running pool needs its target capacity adjusted.

virsh pool-format

Why it fails: No pool-format subcommand exists in virsh; pool formatting is handled by the underlying storage tooling, not libvirt. The name is tempting because pool-create-as accepts a --format argument for specifying the pool's source format, so formatting genuinely appears in pool management syntax.

--persistent

Why it fails: This handles domain persistence, not CPU compatibility.

--undefine-source

Why it fails: This removes the domain from the source, not a compatibility feature.

--live

Why it fails: This is a performance flag, not a compatibility flag.

qemu-img create -f raw -o preallocation=full win10.img 80G

Why it fails: The raw format does not support the preallocation option; that option is specific to qcow2 and similar formats. Passing it with -f raw causes qemu-img to fail with an unsupported option error, so no image is created. The scenario requires a fully allocated raw image, which must instead be produced by writing zeros across the whole file, for example with dd or fallocate followed by mkfs.

qemu-img create -f raw -o size=80G win10.img

Why it fails: The -o size= option is not a valid qemu-img create parameter; size is given as a positional argument, not as an option. Supplying it as an option causes an error and no image is produced. Even if corrected, a plain raw create would be sparse rather than fully allocated, which does not meet the preallocation requirement.

qemu-img create -f qcow2 -o preallocation=full win10.img 80G

Why it fails: This creates a qcow2 image with metadata and data preallocated, which does reduce fragmentation, but the format is qcow2, not raw. The requirement explicitly asks for a raw image, and qcow2 adds a mapping layer that changes on-disk layout and performance characteristics. While preallocation=full is valid for qcow2, the resulting file is not a raw image.

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.