LPI 305-300 LPIC-3: Virtualization and Containerization - Exam 305, version 3.0 Exam Practice Test

The command lxc-attach is used to execute a command in a running LXC container. It allows the user to start a process inside the container and attach to its standard input, output, and error streams1. For example, the command lxc-attach -n mycontainer -- ls -lh /home will list all the files and directories in the /home directory of the container named mycontainer1. The other options are not valid LXC commands. The command lxc-batch does not exist. The command lxc-run is an alias for lxc-start, which is used to start a container, not to execute a command in it2. The command lxc-enter is also an alias for lxc-attach, but it is deprecated and should not be used3. The command lxc-eval is also not a valid LXC command. References:

1: Executing a command inside a running LXC - Unix & Linux Stack Exchange.

2: lxc-start: start a container. - SysTutorials.

3: lxc-attach: start a process inside a running container. - SysTutorials.

Both Vagrant and Docker can share directories from the host file system to a guest. This allows the guest to access files and folders from the host without copying them. Vagrant uses the config.vm.synced_folder option in the Vagrantfile to specify the shared folders1. Docker uses the -v or --volume flag in the docker run command to mount a host directory as a data volume in the container2.

Both Vagrant and Docker can download required base images. Base images are the starting point for creating a guest environment. Vagrant uses the config.vm.box option in the Vagrantfile to specify the base image to use1. Docker uses the FROM instruction in the Dockerfile to specify the base image to use2. Both Vagrant and Docker can download base images from public repositories or local sources.

Both Vagrant and Docker can apply changes to a base image. Changes are modifications or additions to the base image that customize the guest environment. Vagrant uses provisioners to run scripts or commands on the guest after it is booted1. Docker uses instructions in the Dockerfile to execute commands on the baseimage and create a new image2. Both Vagrant and Docker can save the changes to a new image or discard them after the guest is destroyed.

Vagrant and Docker differ in how they start system images. Vagrant starts system images as virtual machines by default, using a provider such as VirtualBox, VMware, or Hyper-V1. Docker starts system images as containers by default, using the native containerization functionality on macOS, Linux, and Windows2. Containers are generally more lightweight and faster than virtual machines, but less secure and flexible. References: 1: Vagrant vs. Docker | Vagrant | HashiCorp Developer 2: Vagrant vs Docker: Which Is Right for You? (Could Be Both) - Kinsta® Web Development Tools

The virt-diff command-line tool can be used to list the differences between files in two virtual machines or disk images. The output shows the changes to a virtual machine’s disk images after it has been running. The command can also be used to show the difference between overlays1. To specify two guests, you have to use the -a or -d option for the first guest, and the -A or -D option for the second guest. For example: virt-diff -a old.img -A new.img1. Therefore, the correct command to list all differences between the disk images vm1-snap.img and vm1.img is: virt-diff -a vm1-snap.img -A vm1.img. The other commands are not related to finding differences between disk images. virt-delta is a tool to create delta disks from two disk images2. virt-cp-in is a tool to copy files and directories into a virtual machine disk image3. virt-cmp is a tool to compare two files or directories in a virtual machine disk image4. virt-history is a tool to show the history of a virtual machine disk image5. References:

21.13. virt-diff: Listing the Differences between Virtual Machine Files …

21.14. virt-delta: Creating Delta Disks from Two Disk Images …

21.6. virt-cp-in: Copying Files and Directories into a Virtual Machine Disk Image …

21.7. virt-cmp: Comparing Two Files or Directories in a Virtual Machine Disk Image …

21.8. virt-history: Showing the History of a Virtual Machine Disk Image …

 The correct way to start a new container that shares the /data volume with the datastore container is to use the --volumes-from flag. This flag mounts all the defined volumes from the referenced containers. In this case, the datastore container has a volume named /data, which is mounted in the service container at the same path. The other options are incorrect because they either use invalid flags, such as --share-with or --volume-backend, or they create new volumes instead of sharing the existing one, such as -v datastore:/data or -v /data. References:

Docker Docs - Volumes

Stack Overflow - How to map volume paths using Docker’s --volumes-from?

Docker Docs - docker run

The correct way to share data between several virtual machines running on the same Linux-based host system is by using a network file system or file transfer protocol. A network file system (NFS) is a distributed file system protocol that allows a user on a client computer to access files over a network in a manner similar to how local storage is accessed1. A file transfer protocol (FTP) is a standard network protocol used for the transfer of computer files between a client and server on a computer network2. Both methods allow data to be shared between virtual machines regardless of their underlying file systems or virtualization technologies. The other options are incorrect because they either do not work or are not feasible. Option A is wrong because each virtual machine has its own file system that is not directly accessible by other virtual machines. Option B is wrong because there is no such device as /dev/virt-disks/remote/ that can be used to mount other virtual machines’ file systems. Option C is wrong because a ramdisk is a volatile storage device that is not suitable for sharing data between virtual machines. Option E is wrong because attaching the same virtual hard disk to multiple virtual machines can cause data corruption and conflicts, and EXT4 does not have any sharing extensions that can prevent this. References:

The unshare command is used to run a process in a new Linux namespace12. It takes one or more flags to specify which namespaces to create or unshare from the parent process1. For example, to run a shell in a new mount, network, and PID namespace, one can use:

unshare -mnp /bin/bash

References:

1: unshare(1) - Linux manual page - man7.org

2: A gentle introduction to namespaces in Linux - Packagecloud

 Container-based virtualization is a method of operating system-level virtualization that allows multiple isolated user spaces (containers) to run on the same host system1. Each container shares the same operating system kernel as the host, but has its own file system, libraries, and processes2. Therefore, the statements A and C are false, as containers do not run their own kernels or rely on hardware support from the CPU. The statement E is also false, as Linux does support container-based virtualization through various technologies, such as cgroups, namespaces, LXC, Docker, etc12. The statement B is true, as different containers may use different distributions of the same operating system, such as Debian, Ubuntu, Fedora, etc., as long as they are compatible with the host kernel3. The statement D is also true, as all containers run within the operating system kernel of the host system, which provides isolation and resource management for them12. References:

1: Containerization (computing) - Wikipedia.

2: What are containers? | Google Cloud.

3: What is Container-Based Virtualization? - StackHowTo.

 The command vagrant init is used to initialize the current directory to be a Vagrant environment by creating an initial Vagrantfile if one does not already exist1. The Vagrantfile contains the configuration settings for the Vagrant box, such as the box name, box URL, network settings, synced folders, provisioners, etc. The command vagrant init does not execute any provisioning tool, start any box, install Vagrant on a Linux host, or download any box. Those actions are performed by other Vagrant commands, such as vagrant provision, vagrant up, vagrant install, and vagrant box add, respectively. References:

1: vagrant init - Command-Line Interface | Vagrant | HashiCorp Developer

The subcommand of virsh that opens the XML configuration of a virtual network in an editor in order to make changes to that configuration is net-edit1. This subcommand takes the name or UUID of the network as a parameter and opens the network XML file in the default editor, which is specified by the $EDITOR shell variable1. The changes made to the network configuration are applied immediately after saving and exiting the editor1.

References:

1: net-edit - libvirt.

The CPU flag that indicates the hardware virtualization capability on an AMD CPU is SVM. SVM stands for Secure Virtual Machine, and it is a feature of AMD processors that enables the CPU to run virtual machines with hardware assistance. SVM is also known as AMD-V, which is AMD’s brand name for its virtualization technology. SVM allows the CPU to support a hypervisor, which is a software layer that creates and manages virtual machines. A hypervisor can run multiple virtual machines on a single physical machine, each with its own operating system and applications. SVM improves the performance and security of virtual machines by allowing the CPU to directly execute privileged instructions and handle memory access, instead of relying on software emulation or binary translation. SVM also provides nested virtualization, which is the ability to run avirtual machine inside another virtual machine. To use SVM, the CPU must support it and the BIOS must enable it. The user can check if the CPU supports SVM by looking for the svm flag in the /proc/cpuinfo file or by using the lscpu command. The user can also use the virt-host-validate command to verify if the CPU and the BIOS are properly configured for hardware virtualization123. References:

How to check if CPU supports hardware virtualization (VT technology)1

Processor support - KVM3

How to Enable Virtualization in BIOS for Intel and AMD4

The purpose of the kubelet service in Kubernetes is to run containers on the worker nodes according to the Kubernetes configuration. The kubelet is an agent or program that runs on each node and communicates with the Kubernetes control plane. It receives a set of PodSpecs that describe the desired state of the pods that should be running on the node, and ensures that the containers described in those PodSpecs are running and healthy. The kubelet also reports the status of the node and the pods back to the control plane. The kubelet does not manage containers that were not created by Kubernetes. References:

Kubernetes Docs - kubelet

Learn Steps - What is kubelet and what it does: Basics on Kubernetes

The CPU architecture of a QEMU virtual machine is independent of the host system’s architecture. QEMU can emulate many CPU architectures, including x86, ARM, Alpha, and SPARC, regardless of the host system’s architecture1. This allows QEMU to run guest operating systems that are not compatible with the host system’s hardware. Therefore, option A is correct. QEMU virtual machines support multiple virtual CPUs in order to run SMP systems. QEMU uses the concept of virtual CPUs (vCPUs) to map the virtual machines to physical CPUs. Each vCPU is a thread that runs on a physical CPU core. QEMU allows the user to specify the number of vCPUs and the CPU model for each virtual machine. QEMU can run SMP systems with multiple vCPUs, as well as single-processor systems with one vCPU2. Therefore, option E is also correct. The other options are incorrect because they do not describe the CPU of a QEMU virtual machine. Option B is wrong because QEMU virtual machines can have more than one CPU with more than one core. Option C is wrong because QEMU does not require a dedicated physical CPU core for each virtual machine. QEMU can share the physical CPU cores among multiple virtual machines, depending on the load and the scheduling policy. Option D is wrong because QEMU does not use the term CPU, but vCPU, to refer to the virtual machines’ processors. References:

QEMU vs VirtualBox: What’s the difference? - LinuxConfig.org

QEMU / KVM CPU model configuration — QEMU documentation

Introduction — QEMU documentation

Qemu/KVM Virtual Machines - Proxmox Virtual Environment

QEMU can provide some network services in a user network, which is a mode of networking that does not require any administrator privilege to run. The user network uses the SLIRP TCP/IP emulator to create a virtual NAT’ted subnet, with a DHCP server started by QEMU that gives out IP addresses to the guest machines and puts the host on 10.0.2.21. QEMU can also provide a TFTP server in the user network, which can be used to boot the guest machines from a network image. The TFTP server can be configured with the -tftp option2. QEMU does not provide BGP, CIFS, or AppleTalk services in the user network. BGP is a routing protocol that is used to exchange routing information between autonomous systems on the Internet3. CIFS is a file-sharing protocol that is used to access files and printers on a network4. AppleTalk is a deprecated network protocol suite that was used by Apple devices5. These services require more advanced networking features than the user network can offer, such as bridging, routing, or tunneling.

References:

Documentation/Networking - QEMU

QEMU/Networking - Wikibooks, open books for an open world

Border Gateway Protocol - Wikipedia

Common Internet File System - Wikipedia

AppleTalk - Wikipedia

 The correct command to move the libvirt domain web1 from the current host system to the host system host2 is virsh migrate web1 qemu+ssh://host2/system. This command uses the virsh migrate command, which initiates the live migration of a domain to another host1. The first argument is the name of the domain to migrate, which in this case is web1. The second argument is the destination URI, which specifies the connection to the remote host and the hypervisor to use2. In this case, the destination URI is qemu+ssh://host2/system, which means to use the QEMU driver and connect to host2 via SSH, and use the system instance of libvirtd3. The other options are incorrect because they either use invalid commands or arguments, such as node-update, pool-add, patch, or cp, or they do not specify the destination URI correctly. References:

LXD supports the following network interface types in an LXD container configuration1:

macvlan: Creates a virtual interface on the host with a unique MAC address and attaches it to an existing physical interface. This allows the container to have direct access to the physical network, but prevents communication with the host and other containers on the same host2.

bridged: Connects the container to an existing bridge interface on the host. This allows the container to communicate with the host and other containers on the same bridge, as well as the external network if the bridge is connected to a physical interface3.

physical: Passes an existing physical interface on the host to the container. This allows the container to have exclusive access to the physical network, but removes the interface from the host4.

The other network interface types, ipsec and wifi, are not valid in an LXD container configuration. Ipsec is a protocol for secure communication over IP networks, not a network interface type. Wifi is a wireless technology for connecting devices to a network, not a network interface type. References:

About networking - Canonical LXD documentation

Macvlan network - Canonical LXD documentation

Bridge network - Canonical LXD documentation

Physical network - Canonical LXD documentation

Sparse images are a type of virtual disk images that grow in size as data is written to them, but do not shrink when data is deleted from them. Sparse images may consume an amount of space different from their nominal size, which is the maximum size that the image can grow to. For example, a sparse image with a nominal size of 100 GB may only take up 20 GB of physical storage if only 20 GB of data is written to it. Sparse images allocate backend storage at the first usage of a block, which means that the physical storage is only used when the virtual machine actually writes data to a block. This can save storage space and improve performance, as the image does not need to be pre-allocated or zeroed out.

Sparse images are not automatically shrunk when files within the image are deleted, because the virtual machine does not inform the host system about the freed blocks. To reclaim the unused space, a special tool such as virt-sparsify1 or qemu-img2 must be used to compact the image. Sparse images can be used with both full virtualization and paravirtualization, as the type of virtualization does not affect the format of the disk image. Sparse images are not automatically resized when their maximum capacity is about to be exceeded, because this would require changing the partition table and the filesystem of the image, which is not a trivial task. To resize a sparse image, a tool such as virt-resize3 or qemu-img2 must be used to increase the nominal size and the filesystem size of the image. References: 1 (search for “virt-sparsify”), 2 (search for “qemu-img”), 3 (search for “virt-resize”).

LXC implements system containers, which are a type of operating-system-level virtualization. System containers allow running multiple isolated Linux systems on a single Linux control host, using a single Linux kernel. System containers share the same kernel with the host and each other, but have their own file system, libraries, andprocesses. System containers are different from application containers, which are designed to run a single application or service in an isolated environment. Application containers are usually smaller and more portable than system containers, but also more dependent on the host kernel and libraries. Hardware containers, CPU emulation, and paravirtualization are not related to LXC, as they are different kinds of virtualization methods that involve hardware abstraction, instruction translation, or modification of the guest operating system. References:

1: LXC - Wikipedia

2: Linux Virtualization : Linux Containers (lxc) - GeeksforGeeks

3: Features - Proxmox Virtual Environment

Docker stack is a command that allows users to deploy and manage a stack of services on a Docker Swarm cluster. A stack is a group of interrelated services that share dependencies and can be orchestrated and scaled together. A stack is typically defined by a Compose file, which is a YAML file that describes the services, networks, volumes, and other resources of the stack. To use docker stack to run a Compose file on a Swarm, the user must first create and initialize a Swarm cluster, which is a group of machines (nodes) that are running the Docker Engine and are joined into a single entity. The Swarm cluster has one or more managers, which are responsible for maintaining the cluster state and orchestrating the services, and one or more workers, which are the nodes that run the services.

When the user runs docker stack deploy with a Compose file, the command parses the file and creates the services as specified. However, docker stack does not build or upload the images referenced in the Compose file to any registry. Instead, it instructs the Swarm nodes to pull the images from a registry, which can be the public Docker Hub or a private registry. The user must ensure that the images are available in the registry before deploying the stack, otherwise the deployment will fail. The user can use docker build and docker push commands to create and upload the images to the registry, or use an automated build service such as Docker Hub or GitHub Actions. The user must also make sure that the image names and tags in the Compose file match the ones in the registry, and that the Swarm nodes have access to the registry if it is private. By pulling the images from a registry, docker stack ensures that the Swarm nodes have the same and latest version of the images, and that the images are distributed across the cluster in an efficient way.

The other options are not correct. Docker stack does not build the images locally or on the Swarm nodes, nor does it copy or transfer the images to the Swarm nodes. Dockerstack also does not pass the images to the Swarm master, as this would create a bottleneck and a single point of failure. Docker stack relies on the registry as the source of truth for the images, and delegates the image pulling to the Swarm nodes. References:

Deploy a stack to a swarm | Docker Docs1

docker stack deploy | Docker Docs2

docker build | Docker Docs3

docker push | Docker Docs4