How it works...

In step 1, we used the virsh command and supplied all argument to list all active and inactive instances. As expected, we started with no instances defined.

In step 2, we created a definition file for a new KVM instance. We used a small subsection of the available XML schema attributes to set the following options:

• The root element of the XML file is required for all virtual machine definitions and is named domain. It has two attributes--type and id. We specified kvm as the type and an id as 1 because this is our first KVM virtual machine. All other attributes are defined under the domain root element.
• We specified a name for the instance with the name attribute.
• The memory attribute defines the available memory to the VM, in our case, 1 GB.
• The vcpu element defines the maximum number of virtual CPUs allocated for the guest OS. We specified 1, and we used the optional attribute placement that indicates the CPU placement mode; in this example, static. Static placement indicates that the virtual instance will be pinned to all the available physical CPUs.
• The OS element defines the architecture of the VM with the use of the type element. The hvm option indicates that we are going to use full virtualization, which is going to be KVM, as specified in the domain type attribute we saw earlier. We specify the boot device the VM will start from with the <boot dev> element.
• The next three elements specify the action to be taken when the guest requests a power off, reboot or it crashes. In our example, the VM will be destroyed when the guest OS is powered off and restarted when the guest reboots or crashes. 
• The largest section of the XML definition is the devices section, where we use various XML elements to describe devices provided to the guest OS. The emulator element specifies the path to the emulator binary. We are going to use the same QEMU emulator binary qemu-system-x86_64 we used in Chapter 1, Getting Started with QEMU and KVM. In the last few sections of the devices attribute, we define the type of virtual disk we are using, in this example, the raw image we built in the previous chapter. In a similar fashion, we describe the VNC server that the guest should start and the network interface inside the guest OS. 

With the config file in place, we defined the instance in step 3, using the image we created earlier in /tmp.

Once a new instance has been defined, it does not automatically start by default. We can see that the status of the new instance is shut off in step 4.