Managing KVM Deployments with Virt-Manager

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.

<domain type='kvm'>
  <name>ubuntu-9.04-64</name>
  <uuid>19a049b8-83a4-2ed1-116d-33db85a5da17</uuid>
  <memory>1048576</memory>
  <currentMemory>1048576</currentMemory>
  <vcpu>2</vcpu>
  <os>
    <type arch='x86_64' machine='pc'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/bin/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <source
       file='/home/baseimage/ubuntu-9.04-64.qcow2'/>
      <target dev='hda' bus='ide'/>
    </disk>
    <disk type='file' device='cdrom'>
      <target dev='hdc' bus='ide'/>
      <readonly/>
    </disk>
    <interface type='bridge'>
      <mac address='54:52:00:42:df:25'/>
      <source bridge='br0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target port='0'/>
    </console>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='yes'/>
  </devices>
</domain>

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.

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.