Managing KVM Deployments with Virt-Manager

The Virtual Machine Manager tools (aka virt-manager and libvirt) make it simple to set up and manage multiple KVM-based virtual machines.
libvirt Configurations

Using virt-install to create a VM image does two things. It creates an image file, and it creates a configuration (Listing 1) to launch it for libvirt. The configuration file is an XML file found under /etc/libvirtd/qemu, which should be accessible only by the root user.

If edits are done manually to this file, libvirt should be restarted:

sudo service libvirtd restart

However, it probably is better not to edit the file and to use the virsh command for libvirt to make updates to a VM configuration. If the amount of memory or number of CPUs to use for a VM needs to be lowered, the virt-manager Details tab needs to be used rather than using virsh. Be sure to exit any instances of virt-manager before restarting libvirt.

The base image can be copied to an NFS directory along with the XML configuration file, so that other hosts can make use of it. For another host to use it, copy the XML file to the new host's /etc/libvirtd/qemu directory, and edit it to point to the NFS mountpoint. Then, restart the libvirt on the new host.

Creating a Clone

The base image is just the core image for creating your VM appliances. Each appliance is a clone of the base image with additional applications installed. Base images are also known as “backing stores”, because the base image is used for reads, and the clone image is used when writes occur. In this way, the clone gets updated while the base image remains pristine.

Creating a clone requires that the host libvirt knows about the base image, which means the XML configuration for the base image is in the libvirt configuration directories and libvirt has been restarted. Cloning is performed by the virt-clone command:


sudo virt-clone -o <base-image-name> \
                -n <clone-image-name> \
                -f <path-to-base-image>

As with virt-install, virt-clone options are described in detail in the man page. Using the previous virt-install example and the naming scheme described earlier, a clone of a Fedora base image would look more like this:

sudo virt-clone -o fedora11-64 \
                -n fedora11-64.1 \
                -f /home/cloneimages/fedora11-64.1

In this example, the clone image name is the same as the base image with an identifying suffix, and the clone image file has the same name as the image and will be created in /home/cloneimages. The image name is used to identify the guest VM to libvirt and is saved as the “name” element in the XML configuration file for the VM. The image filename is the name of the file where the image is located. This is stored in the “source file” element of the XML configuration file.

Cloning an image can be a system-intensive operation. Although a quad-core CPU with 8GB of memory might handle this just fine, a single-core system may get bogged down if other operations are in progress. Cloning at home may be something to leave for overnight processing.

Clones are not required for working with a VM. You can just as easily work directly with the base image. Clones, however, are useful if you plan on having multiple, independent configurations using the same base OS installation. In other words, clones are not typically necessary at home, but they may be required when used with clusters of servers.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Configuring the host for DHCP address assignment

thyrsus's picture

I'm confused by the paragraph describing configuration of the host for DHCP network access. The lines listed are to be left "out"? Out of which file - ifcfg-br0 or ifcfg-eth0? My first guess would be that ifcfg-eth0 should contain the same contents as for a statically addressed host, and that the lines listed should appear in ifcfg-br0. Please clarify.

Thanks.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix