305-300 Full Virtualization — Timed 20 Questions

Question 1

You need to migrate a running QEMU VM to a remote host using live migration. Which command-line argument for QEMU-KVM initiates a migration to a target host at 192.168.1.50 on port 4444?

Accepted Answer

-migrate tcp:192.168.1.50:4444. QEMU's live migration is initiated with the -migrate option, which takes a URI describing the destination. The URI tcp:192.168.1.50:4444 tells QEMU to migrate the running VM over TCP to host 192.168.1.50 on port 4444. The target host must be started with the matching -incoming tcp:0.0.0.0:4444 (or similar) to accept the migration stream.

Answer

-remote 192.168.1.50:4444

Answer

-live-migrate 192.168.1.50:4444

Answer

-incoming tcp:192.168.1.50:4444

Question 2

When migrating a Libvirt domain using 'virsh migrate --live', which option must be specified to ensure the guest's memory state is copied over the network?

Accepted Answer

--copy-storage-all. The --live option manages the memory transfer, but the --copy-storage-all or --block-incremental option is required if the disks are not on shared storage.

Answer

--shared-storage

Answer

--migrate-disk

Answer

--memory-copy

Question 3

You are troubleshooting a libvirt network issue where the virtual machines cannot reach the external gateway. The virtual network uses a NAT configuration. Which file would you inspect to verify the iptables rules generated by libvirt for this network?

Accepted Answer

/etc/libvirt/qemu/networks/default.xml. libvirt stores the persistent XML definition of each virtual network under /etc/libvirt/qemu/networks/, with default.xml being the definition for the default NAT network. This file contains the element and any DHCP ranges that libvirt uses to program iptables. Inspecting it lets you verify the intended NAT configuration that libvirt translates into iptables rules.

Answer

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

Answer

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

Answer

/etc/iptables/rules.v4

Question 4

You need to create a snapshot of a QCOW2 disk image without stopping the virtual machine. Which qemu-img sub-command should be used?

Accepted Answer

virsh snapshot-create-as --domain vm_name --name snap1 --disk-only. virsh snapshot-create-as with --disk-only creates a live disk snapshot of a running domain by writing a new overlay file while the VM keeps running, which is exactly what is needed for a QCOW2 image without downtime. This leverages libvirt's snapshot API against the QEMU/KVM backend. The other options either create a static overlay manually, snapshot only internal state, or use an unrelated checkpoint mechanism.

Answer

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

Answer

qemu-img snapshot -c snapshot_name image.qcow2

Answer

virsh checkpoint-create vm_name

Question 5

You are performing a live migration of a VM using libvirt. The source and destination hosts share a common storage pool (NFS). Which option should be used with 'virsh migrate' to ensure only the memory state is transferred?

Accepted Answer

--copy-storage-none. When source and destination hosts share storage (e.g., an NFS pool), the disk image is already accessible to both, so only the VM's memory state and device state need to be transferred. The '--copy-storage-none' option tells virsh migrate not to copy any storage, which is exactly the shared-storage scenario. This minimizes migration time and network traffic.

Answer

--shared-storage

Answer

--migrate-memory-only

Answer

--unsafe

Question 6

You are configuring a libvirt bridge network. Which file should you edit on a Debian/Ubuntu system to create a bridge interface 'br0' that includes 'eth0'?

Accepted Answer

/etc/network/interfaces. /etc/network/interfaces is the standard location for configuring network bridges on Debian-based systems.

Answer

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

Answer

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

Question 7

Which signal is sent to a QEMU process when you run 'virsh destroy'?

Accepted Answer

SIGKILL. The `virsh destroy` command performs a forced, immediate power-off of a virtual machine, analogous to pulling the power plug. In libvirt, this action sends a SIGKILL signal to the QEMU process, which cannot be caught or ignored, ensuring the VM terminates instantly. This is distinct from `virsh shutdown`, which sends an ACPI shutdown request for a graceful guest-initiated stop.

Answer

SIGINT

Answer

SIGHUP

Answer

SIGTERM

Question 8

Which command do you use to view the console output of a running guest VM?

Accepted Answer

virt-viewer vm_name. virsh console allows you to connect to the serial console of a guest.

Answer

virsh show-console vm_name

Answer

virsh view vm_name

Question 9

You are configuring a virtual network with a bridge. You want to disable DNS services for that network. What XML element within the <network> definition do you remove or comment out?

Accepted Answer

. In libvirt's network XML, the element inside defines DNS forwarders and host entries served by libvirt's dnsmasq instance. Removing or commenting out disables the custom DNS configuration, so the network no longer provides DNS services to guests. This is the correct element to strip when you want guests to rely on external DNS instead.

Answer

<disable-dns/>

Answer

Answer

Question 10

You are migrating a disk-based VM. You need to ensure the destination host can access the disk image. What must you configure?

Accepted Answer

A shared storage pool accessible by both hosts. Both the source and destination must have access to the same storage path or a shared storage pool.

Answer

A static IP for the VM

Answer

A local disk file on the destination

Question 11

How do you configure a VM to automatically start when the host boots?

Accepted Answer

virsh autostart vm_name. virsh autostart vm_name ensures the VM starts with the host.

Answer

virsh set-boot-auto vm_name

Answer

virsh config-start vm_name

Question 12

Which TWO of the following are valid network modes for a libvirt virtual network?

Accepted Answer

bridge. Option B (bridge) is correct because libvirt supports a bridged network mode where the guest's virtual NIC is attached directly to a host bridge (e.g., virbr0 or br0), placing the VM on the same L2 segment as the physical LAN. Option D (nat) is correct because libvirt's default virtual network uses NAT mode, where guests get addresses from a private subnet and traffic is masqueraded out through the host's interface via dnsmasq and iptables/nftables rules. The other options are not libvirt network modes: 'switch' (A) is not a libvirt forward mode, 'peer' (C) is not a defined libvirt network mode, and 'router' (E) is not one of libvirt's supported forward modes (the valid ones are nat, route, bridge, private, vepa, passthrough, and hostdev).

Answer

switch

Answer

peer

Answer

router

Question 13

Which THREE of the following are required for a successful live migration between two KVM hosts using libvirt?

Accepted Answer

Shared storage. Option A (Shared storage) is required because live migration with libvirt/KVM must transfer the running guest's memory state while its disk image remains accessible to both source and destination; typically this is provided via NFS, iSCSI, or Fibre Channel so the destination can resume the VM without copying the disk. Option B (SSH connectivity between hosts) is required because libvirt's default migration transport uses qemu+ssh:// to establish the connection and authenticate between the two hosts, enabling the control channel and data transfer. Option E (Identical CPU models or CPU pass-through) is required because the guest's CPU state must be compatible on the destination; libvirt/QEMU will refuse migration if the target CPU lacks features the guest is using, unless the CPU model is identical or host-passthrough is used with matching hardware. Option C (Identical network card models) is not required because the guest sees a virtual NIC whose model is defined in the domain XML and is recreated on the destination; the physical NIC model need not match. Option D (Matching guest kernel versions) is not required because migration operates at the QEMU/KVM level and the guest OS kernel is unaware of and unaffected by the host migration.

Answer

Identical network card models

Answer

Matching guest kernel versions

Question 14

Which THREE of the following are valid virtio device types?

Accepted Answer

virtio-scsi. virtio-scsi (A) is a valid virtio device type that provides a SCSI host bus adapter to the guest, allowing it to attach multiple SCSI devices and use features like SCSI passthrough and advanced command queuing. virtio-blk (C) is a valid virtio block device that exposes a paravirtualized block device directly to the guest for high-performance disk I/O. virtio-net (E) is a valid virtio network device that provides a paravirtualized Ethernet adapter, typically paired with a tap backend on the host. The unmarked options virtio-keyboard (B) and virtio-mouse (D) are not standard virtio device types; input devices in virtualized environments are normally handled through emulated PS/2 or USB HID controllers rather than dedicated virtio input drivers.

Answer

virtio-keyboard

Answer

virtio-mouse

Question 15

Which TWO of the following are valid ways to configure VM networking?

Accepted Answer

NAT. Option B (NAT) is correct because NAT is a standard virtual networking mode where the hypervisor translates VM traffic to the host's IP address, allowing VMs to reach external networks while remaining on a private internal subnet. Option D (Bridging) is correct because bridging attaches a virtual switch to a physical NIC so VMs obtain addresses directly from the external network and appear as separate hosts on the LAN. These two are widely supported VM networking configurations in hypervisors such as VMware, Hyper-V, and VirtualBox. Option A (Hub-based switching) is not a standard hypervisor VM networking mode, as hubs are legacy shared-medium devices rather than a configuration method. Option C (VLAN tagging on bridge) describes a feature that can be applied to a bridged setup rather than a distinct valid VM networking configuration on its own. Option E (Direct routing) is a routing technique, not a hypervisor VM network attachment mode.

Answer

Hub-based switching

Answer

VLAN tagging on bridge

Answer

Direct routing

Question 16

Which THREE of the following are valid options for 'virsh shutdown'?

Accepted Answer

--mode acpi. The virsh shutdown command accepts a --mode option that selects how the guest is asked to power down: --mode acpi (A) sends an ACPI power-button event so the guest OS performs a clean, orderly shutdown; --mode agent (B) uses the QEMU guest agent (qemu-guest-agent) to request shutdown from inside the guest; and --mode initctl (C) triggers the shutdown via the guest's initctl/systemd mechanism. These three are the documented valid values for --mode in virsh shutdown. Options D (--mode force) and E (--mode hard) are not valid values for virsh shutdown; forced or hard power-off is performed with virsh destroy, not by a shutdown mode.

Answer

--mode force

Answer

--mode hard

Question 17

Which TWO of the following are valid ways to manage storage pools using virsh?

Accepted Answer

virsh pool-create-as. Option C, virsh pool-create-as, is correct because it both defines a new storage pool from the given command-line parameters (name, type, and source/target details) and immediately starts it in one step, making it a valid way to create and manage a pool. Option D, virsh pool-define-as, is correct because it defines a persistent storage pool from command-line arguments without starting it, which is a standard virsh method for managing pool definitions (later activated with virsh pool-start). The other options are not valid virsh subcommands: virsh pool-mount (A) does not exist, virsh pool-resize (B) is not a real subcommand (resizing is done via virsh pool-set or editing the XML and redefining), and virsh pool-format (E) is not a virsh command for managing storage pools.

Answer

virsh pool-mount

Answer

virsh pool-resize

Answer

virsh pool-format

Question 18

When migrating a domain with virsh, which TWO of the following options can be used to ensure the migration is successful if the destination host has a different CPU architecture or feature set?

Accepted Answer

--cpu-mode host-model. Option B (--cpu-mode host-model) is correct because it exposes a CPU model that mirrors the destination host's capabilities, allowing libvirt to present a compatible CPU definition so the guest can start on a host with a different feature set. Option E (--cpu-mode custom) is correct because it lets you supply an explicit, tailored CPU model/feature list (via the domain XML <cpu> element) that matches the destination host's architecture and features, ensuring the migrated domain boots successfully. Options A (--persistent) and C (--undefine-source) only control the persistence of the domain definition and cleanup of the source, not CPU compatibility, so they do not address differing architectures or feature sets. Option D (--live) merely requests a live migration and says nothing about reconciling CPU differences, so it does not ensure success across heterogeneous hosts.

Answer

--persistent

Answer

--undefine-source

Answer

--live

Question 19

A KVM host runs a Windows guest that performs many random writes. The host's storage backend is a local LVM volume group. You want to avoid host-side fragmentation and reduce write amplification by preallocating the entire guest disk image at creation time. Which command creates a raw image named win10.img of 80 GiB with full allocation?

Accepted Answer

dd if=/dev/zero of=win10.img bs=1M count=81920 conv=fsync. A raw image is fully allocated when every block is written to the underlying filesystem. The dd approach writes zeros across the entire 80 GiB, forcing allocation and eliminating sparse regions that can fragment over time. The qcow2 variant would satisfy preallocation but produces the wrong format, and the two malformed qemu-img invocations either use an unsupported option or an invalid syntax.

Answer

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

Answer

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

Answer

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

Question 20

You are preparing a KVM guest for a live migration with virsh migrate --live and want the guest's disk writes to be tracked on the source host so that only dirty blocks are transferred after the memory copy begins. The guest disk is a raw image on a local LVM logical volume, and the destination host can reach the source's storage via a shared Fibre Channel LUN, but the LUN is not yet visible on the destination. Which action must you take on the source host before starting the migration to enable dirty-block tracking for this disk?

Accepted Answer

Start a block copy job with virsh blockcopy --domain guest --path vda --dest /dev/mapper/vg_lun --wait --verbose to mirror writes to the shared LUN.. Live migration with only dirty blocks transferred requires a mechanism that records writes while the guest runs. A block copy job using virsh blockcopy mirrors the disk to the destination and maintains a dirty bitmap, so the final pass copies only changed blocks. The destination must be able to see the target LUN, which the shared Fibre Channel setup provides once the copy job points to it.

Answer

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

Answer

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

Answer

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