Courseiva

CCNA Full Virtualization Questions

15 of 90 questions · Page 2/2 · Full Virtualization topic · Answers revealed

Practice these questionsExam hubAll questions
76
Multi-Selecthard

Which THREE of the following XML elements are used to define a virtual disk in a domain?

Select 3 answers
A.<driver name='qemu' type='qcow2'/>
B.<mount-point path='/'>
C.<filesystem name='...'>
D.<target dev='vda' bus='virtio'/>
E.<source file='...'/>
AnswersA, D, E

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.

Why this answer

In libvirt domain XML, a virtual disk is defined inside a <disk> element, and the three marked options are its core components. Option A, <driver name='qemu' type='qcow2'/>, specifies the hypervisor driver (qemu) and the disk image format (qcow2), which tells libvirt how to handle the backing file. Option D, <target dev='vda' bus='virtio'/>, defines the guest-visible device name and the bus/controller (virtio) used to attach the disk to the VM.

Option E, <source file='...'/>, points to the host-side disk image file that backs the virtual disk. The unmarked options do not belong: <mount-point path='/'> and <filesystem name='...'> are used in filesystem/container or guest-agent contexts (e.g., <filesystem> devices for virtio-9p or virtiofs), not for defining a standard virtual disk in a domain.

Exam trap

305-300 often tests the confusion between storage-related XML elements, tricking candidates into selecting <filesystem> or mount-point tags for disk definitions when only <source>, <target>, and <driver> belong inside a <disk> element.

Practice this question →
77
Multi-Selecthard

Which THREE of the following steps are involved in performing a manual disk migration of a VM?

Select 3 answers
A.Editing the domain XML on the target host
B.Reformatting the disk image
C.Redefining the domain using virsh define
D.Copying the disk image to the target host
E.Updating the host kernel
AnswersA, C, D

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.

Why this answer

Manual disk migration of a VM requires copying the VM's disk image to the target host (D), since the storage must be present there before the domain can run; this is typically done with tools like rsync, scp, or cp. The target host's domain XML must then be edited (A) to point to the new disk path and any host-specific settings, because the original XML references the source host's storage location. Finally, the domain is registered on the target host with virsh define (C), which loads the edited XML into libvirt so the VM can be started.

Options B and E are not part of the process: reformatting the disk image would destroy the guest's data and filesystem, and updating the host kernel is unrelated to migrating a VM's disk and domain definition.

Exam trap

The trap here is assuming migration is a single copy operation; candidates forget that the libvirt domain definition must be edited and redefined on the target, not just the disk image copied.

Practice this question →
78
MCQmedium

Which command is used to display the XML configuration of a running VM domain named 'webserver'?

A.virsh export webserver
B.virsh show-config webserver
C.virsh dumpxml webserver
D.virsh get-xml webserver
AnswerC

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

Why this answer

virsh dumpxml outputs the full XML definition of a domain, and when the domain is running it reflects the live configuration. This is the standard libvirt command for inspecting a VM's XML. The other options are not valid virsh subcommands for this purpose.

Exam trap

305-300 often tests exact virsh subcommand names, so candidates pick plausible-sounding but nonexistent commands like show-config or get-xml instead of the real dumpxml.

How to eliminate wrong answers

Option A is wrong because virsh export is not a valid subcommand for retrieving domain XML; export-like functionality is not part of the virsh domain inspection command set. Option B is wrong because virsh show-config is not a real virsh subcommand; configuration display is done via dumpxml. Option D is wrong because virsh get-xml does not exist; the correct verb is dumpxml.

Practice this question →
79
MCQmedium

You are setting up a KVM guest that requires very low latency for a real-time workload. You want to dedicate a physical CPU core to the guest and prevent the host from scheduling other tasks on that core. Which libvirt domain XML configuration achieves this?

A.<cputune><vcpupin vcpu='0' cpuset='2'/></cputune> combined with host kernel parameters isolcpus=2 and nohz_full=2.
B.<cputune><vcpupin vcpu='0' cpuset='2'/><iothreadpin iothread='1' cpuset='3'/></cputune> and <cpu mode='host-passthrough'/>
C.<vcpupin vcpu='0' cpuset='2'/> and <emulatorpin cpuset='2'/>
D.<cputune><vcpupin vcpu='0' cpuset='2'/></cputune> and <numatune><memnode cellid='0' mode='strict' nodeset='1'/></numatune>
AnswerA

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.

Why this answer

To dedicate and isolate a physical core for a guest, you must both pin the vCPU to that core using vcpupin and configure the host kernel to exclude that core from general scheduling with isolcpus and nohz_full. Pinning alone only restricts where the guest runs; it does not prevent the host from using the core for other tasks. The combination provides the required isolation.

Exam trap

The trap here is believing that vcpupin alone isolates a CPU core; in reality, the host scheduler can still place other processes on that core unless isolcpus is used.

Practice this question →
80
MCQhard

A VM is hanging because of a specific hardware emulation bug in QEMU. You need to enable the 'qxl' video device to see if it resolves display issues. What is the XML tag to define the video device in the domain config?

A.<video><model type='qxl'/></video>
B.<display model='qxl'/>
C.<graphics type='qxl'/>
D.<device type='video' model='qxl'/>
AnswerA

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.

Why this answer

In libvirt domain XML, video devices are defined with the <video> element containing a <model type='...'/> child, where the type attribute specifies the emulated adapter such as qxl, vga, cirrus, or virtio. The correct syntax <video><model type='qxl'/></video> is what libvirt's schema expects and what virsh edit will accept. This is the standard way to switch a guest's display adapter to QXL for improved SPICE performance.

Exam trap

The trap is confusing the <graphics> element (which defines the display protocol like SPICE or VNC) with the <video> element (which defines the emulated video adapter), leading candidates to pick the graphics-based distractor.

How to eliminate wrong answers

Option B is wrong because <display> is not a valid libvirt domain XML element — display configuration is handled through <graphics> and <video>, not a standalone <display> tag. Option C is wrong because <graphics type='qxl'/> misuses the graphics element, which is for specifying the display protocol (spice, vnc, sdl, etc.), not the video adapter model. Option D is wrong because <device type='video' model='qxl'/> is not the libvirt schema — video devices use the dedicated <video> element, not the generic <device> wrapper.

Practice this question →
81
Multi-Selectmedium

Which TWO of the following are benefits of using the QCOW2 image format?

Select 2 answers
A.Multi-host file locking
B.Hardware acceleration
C.Dynamic allocation (sparse files)
D.Native encryption for all filesystems
E.Snapshot support
AnswersC, E

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.

Why this answer

Option C is correct because QCOW2 (QEMU Copy-On-Write version 2) is a sparse image format: it allocates disk blocks only as guest data is actually written, so a 100 GB virtual disk consumes only as much host space as the data stored in it, and it can grow dynamically up to the configured virtual size. Option E is correct because QCOW2 natively supports internal snapshots (stored inside the image file) and external snapshots, allowing point-in-time states of a VM disk to be created and reverted without copying the whole image. Option A is wrong because multi-host file locking is a feature of clustered/shared storage filesystems such as GFS2 or OCFS2, not of the QCOW2 format itself; QCOW2 images are not designed for concurrent write access from multiple hosts.

Option B is wrong because hardware acceleration (for example KVM, Intel VT-x/AMD-V, or virtio) is provided by the hypervisor and CPU, not by the image file format. Option D is wrong because QCOW2 does not provide native encryption for all filesystems; encryption in QEMU/KVM is typically handled via LUKS or the qcow2 encryption extension (AES-CBC with a single key), which is not a general 'all filesystems' encryption feature.

Exam trap

The trap is assuming QCOW2 provides hardware acceleration or multi-host locking, when those are hypervisor or storage-layer features, not image-format features.

Practice this question →
82
Multi-Selectmedium

Which TWO of the following commands are used for VM disk image management?

Select 2 answers
A.qemu-img list
B.qemu-img create
C.qemu-img status
D.qemu-img format
E.qemu-img info
AnswersB, E

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

Why this answer

Option B, `qemu-img create`, is correct because it is the standard qemu-img subcommand used to create a new VM disk image, specifying the format (e.g., qcow2, raw) and size. Option E, `qemu-img info`, is correct because it displays metadata about an existing disk image, such as its virtual size, disk size, format, and backing file. The other options are not valid qemu-img subcommands: `qemu-img list` (A) does not exist for enumerating images, `qemu-img status` (C) is not a qemu-img operation, and `qemu-img format` (D) is not a subcommand — formatting is done via the `-f`/`-O` options on create/convert.

Exam trap

The trap is confusing qemu-img subcommands — candidates may pick 'qemu-img format' instead of 'qemu-img convert', or assume 'list' and 'status' exist when they do not.

Practice this question →
83
MCQmedium

You have an active domain named 'myvm'. How do you gracefully shut it down?

A.virsh stop myvm
B.virsh poweroff myvm
C.virsh destroy myvm
D.virsh shutdown myvm
AnswerD

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.

Why this answer

'virsh shutdown myvm' sends an ACPI shutdown signal to the guest, allowing the guest OS to run its shutdown sequence gracefully. This is the correct way to power off a domain cleanly. It requires the guest to have ACPI support and a running acpid/systemd to honor the request.

Exam trap

The trap is assuming 'destroy' means graceful deletion — in libvirt, destroy is the forceful power-off, while shutdown is the graceful ACPI request.

How to eliminate wrong answers

Option A is wrong because 'virsh stop' is not a valid virsh subcommand — there is no stop verb in virsh. Option B is wrong because 'virsh poweroff' is not a valid virsh subcommand either; poweroff is not exposed by virsh (it exists in other tools like virsh's destroy semantics but not as a named command). Option C is wrong because 'virsh destroy' performs an immediate, hard power-off (equivalent to pulling the plug), which is not graceful and can corrupt the guest filesystem.

Practice this question →
84
MCQeasy

What does 'QEMU' stand for?

A.Quantum Emulator
B.Quick Execution Machine Utility
C.Quick Emulator
D.Quality Emulator
AnswerC

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.

Why this answer

QEMU is an open-source emulator and virtualizer that performs hardware virtualization. The name 'QEMU' is an acronym for 'Quick Emulator', reflecting its original design goal of fast emulation of a complete computer system. It is widely used in conjunction with KVM (Kernel-based Virtual Machine) to provide full virtualization on Linux, and it can also run standalone as a pure emulator for cross-platform development and testing.

Exam trap

The trap here is that candidates might confuse 'QEMU' with other emulators or assume the 'Q' stands for 'Quality' or 'Quantum', but the correct expansion is 'Quick Emulator'.

How to eliminate wrong answers

Option A is wrong because 'Quantum Emulator' is not a recognized term in computing; QEMU has no relation to quantum computing. Option B is wrong because 'Quick Execution Machine Utility' is a fabricated expansion that does not correspond to any known software; QEMU's name is not derived from these words. Option D is wrong because 'Quality Emulator' is a misleading expansion; while QEMU is a high-quality emulator, the 'Q' stands for 'Quick', not 'Quality'.

Practice this question →
85
Multi-Selectmedium

Which TWO of the following are key features of the QEMU-KVM hypervisor?

Select 2 answers
A.Hardware-assisted virtualization
B.Comprehensive device emulation
C.Automated host patching
D.Integrated disk backup service
E.Built-in web server
AnswersA, B

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.

Why this answer

QEMU-KVM is a combination of the KVM kernel module and the QEMU userspace emulator, and its defining feature is hardware-assisted virtualization: KVM leverages CPU virtualization extensions such as Intel VT-x (vmx) and AMD-V (svm) to run guest code directly on the host CPU, which is why option A is correct. Option B is also correct because QEMU provides comprehensive device emulation, presenting virtual hardware such as IDE/SCSI controllers, NICs (e.g., e1000, virtio-net), VGA adapters, and USB controllers to guests, and it also supports paravirtualized virtio devices for performance. The remaining options do not belong: automated host patching (C) is a configuration-management function handled by tools like Ansible, Puppet, or yum/dnf, not by the hypervisor itself; an integrated disk backup service (D) is not part of QEMU-KVM, since backups are performed with external tools such as qemu-img, libvirt snapshots, or third-party backup software; and a built-in web server (E) is not a QEMU-KVM feature, as remote management is typically provided by separate stacks like libvirt, virt-manager, or oVirt/Proxmox.

Exam trap

The trap is attributing management or convenience features like patching or backup to the hypervisor; candidates might confuse QEMU-KVM with full-fledged virtualization platforms that include such tools.

Practice this question →
86
MCQmedium

How can you force a refresh of a libvirt storage pool named 'isos'?

A.virsh pool-refresh isos
B.virsh refresh-pool isos
C.virsh pool-update isos
D.virsh pool-reload isos
AnswerA

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.

Why this answer

Option A is correct because 'virsh pool-refresh isos' is the exact libvirt command to refresh a storage pool named 'isos'. This command rescans the pool's underlying storage (e.g., a directory or LVM volume group) and updates libvirt's internal list of available volumes, making new files visible without restarting libvirtd.

Exam trap

The trap is mixing up virsh subcommand syntax — candidates often guess 'refresh-pool' or 'pool-reload' instead of the correct 'pool-refresh'.

How to eliminate wrong answers

Option B is wrong because 'virsh refresh-pool' is not a valid virsh subcommand — the correct syntax is 'pool-refresh'. Option C is wrong because 'virsh pool-update' does not exist; the correct command to modify pool parameters is 'pool-edit' or 'pool-set'. Option D is wrong because 'virsh pool-reload' is not a valid command; libvirt uses 'pool-refresh' for rescanning, not 'reload'.

Practice this question →
87
Multi-Selectmedium

Which TWO of the following are valid libvirt storage pool lifecycle commands?

Select 2 answers
A.pool-halt
B.pool-start
C.pool-reboot
D.pool-destroy
E.pool-pause
AnswersB, D

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.

Why this answer

Option B, pool-start, is correct because it is a genuine virsh subcommand that activates a previously defined but inactive storage pool, making its backing storage available for allocation to guests. Option D, pool-destroy, is correct because it is the valid virsh command that stops an active storage pool, tearing down its runtime state without deleting its persistent definition. The other options are not libvirt commands: pool-halt (A) and pool-reboot (C) are not virsh storage pool subcommands at all, and pool-pause (E) does not exist, since libvirt storage pools have no pause state — only active/inactive and defined/undefined states managed via pool-start, pool-destroy, pool-define, and pool-undefine.

Exam trap

The trap here is confusing domain lifecycle commands (like destroy, start, reboot, pause) with storage pool commands; candidates might assume pool-halt or pool-pause exist because similar commands exist for domains.

Practice this question →
88
MCQmedium

You are managing a Xen host and need to live-migrate a domain between two physical servers. The migration fails with a domain lock error. Which command is the standard way to initiate a live migration while ensuring the target host is prepared to receive the domain?

A.xl save <domain> <file> && xl restore <file>
B.xen-migrate --live <domain> <target_host>
C.xl migrate <domain> <target_host>
D.virsh migrate --live <domain> <target_host>
AnswerC

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.

Why this answer

The xl migrate command is the standard Xen tool for live-migrating a domain to another host, and it handles the necessary preparation on the target host (such as creating the domain configuration and transferring memory state) to receive the domain. It is the direct counterpart to xm migrate in the newer xl toolstack.

Exam trap

The trap is confusing Xen native tools (xl) with libvirt tools (virsh) — candidates often pick virsh migrate because it's more familiar, but the question specifies a Xen host, where xl migrate is the correct command.

How to eliminate wrong answers

Option A is wrong because xl save and xl restore perform a save/restore operation, which is not a live migration — it suspends the domain, writes it to a file, and restores it elsewhere, causing downtime. Option B is wrong because xen-migrate is not a standard command in the xl toolstack; the correct command is xl migrate. Option D is wrong because virsh migrate is a libvirt command used with KVM/QEMU, not the native Xen toolstack command for Xen hosts.

Practice this question →
89
MCQmedium

When managing storage pools using virsh, which command would you use to list all defined storage pools, including those that are inactive?

A.virsh list-pools --inactive
B.virsh pool-info --all
C.virsh pool-show --all
D.virsh pool-list --all
AnswerD

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.

Why this answer

The correct command is `virsh pool-list --all`. In libvirt's virsh CLI, `pool-list` is the dedicated subcommand for enumerating storage pools, and the `--all` flag extends the default output (which shows only active pools) to include inactive pools as well. This mirrors the pattern used by `virsh list --all` for domains, making it the canonical way to see every defined pool regardless of state.

Exam trap

The trap here is confusing virsh's noun-first subcommand naming (`pool-list`) with verb-first alternatives (`list-pools`) and assuming `--all` works on `pool-info` the way it does on `list` — candidates who pattern-match from other CLIs pick A or B.

How to eliminate wrong answers

Option A is wrong because `list-pools` is not a valid virsh subcommand — virsh uses noun-first syntax like `pool-list`, not verb-first `list-pools`; additionally `--inactive` is not a recognized flag for pool listing. Option B is wrong because `pool-info` requires a specific pool name or UUID as an argument and reports details for a single pool; it does not enumerate pools and does not accept `--all`. Option C is wrong because `pool-show` does not exist in virsh — the closest real commands are `pool-dumpxml` and `pool-info`, neither of which lists all pools.

Practice this question →
90
MCQhard

You are using libvirt to manage a QEMU VM. You want to pass a specific host USB device with vendor ID 1234 and product ID 5678 to the guest. Which XML element is used inside the <devices> block to define this?

A.<controller type='usb' index='0'><address vendor='1234'/></controller>
B.<device type='usb'>1234:5678</device>
C.<usb-passthrough vendor='1234' product='5678'/>
D.<hostdev mode='subsystem' type='usb'><source><vendor id='0x1234'/><product id='0x5678'/></source></hostdev>
AnswerD

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.

Why this answer

Libvirt's canonical way to pass a host USB device to a guest is the <hostdev> element with mode='subsystem' and type='usb', containing a <source> block with <vendor id='0x1234'/> and <product id='0x5678'/>. This tells QEMU to detach the device from the host and attach it to the guest via USB redirection, and the IDs must be in hexadecimal with the 0x prefix.

Exam trap

The trap is that candidates pick a plausible-sounding custom element like <usb-passthrough> instead of remembering that libvirt unifies all host device passthrough (PCI, USB, SCSI) under the <hostdev> element.

How to eliminate wrong answers

Option A is wrong because <controller type='usb'> defines a USB controller for the guest, not a passthrough of a specific host device — the address attribute shown is not valid for USB controllers. Option B is wrong because <device type='usb'> is not a valid libvirt device element; the correct element is <hostdev>. Option C is wrong because <usb-passthrough> is not a libvirt XML element at all — it is a fabricated tag that does not exist in the domain schema.

Practice this question →
← PreviousPage 2 of 2 · 90 questions total

Ready to test yourself?

Try a timed practice session using only Full Virtualization questions.

Start 20-question session