----------------------------------
- testkvm shut off
Let's start our test virtual machine:
# virsh -c qemu:///system start testkvm
Domain testkvm started
We can now get the connection instructions for the graphical console:
# virsh -c qemu:///system vncdisplay testkvm
:0
Other available virsh subcommands include:
reboot to restart a virtual machine;
shutdown to trigger a clean shutdown;
destroy, to stop it brutally;
suspend to pause it;
resume to unpause it;
autostart to enable (or disable, with the --disable option) starting the virtual machine automatically when the host starts;
undefine to remove all traces of the virtual machine from libvirtd.
All these subcommands take a virtual machine identifier as a parameter.
12.3. Automated Installation
The Falcot Corp administrators, like many administrators of large IT services, need tools to install (or reinstall) quickly, and automatically if possible, their new machines.
These requirements can be met by a wide range of solutions. On the one hand, generic tools such as SystemImager handle this by creating an image based on a template machine, then deploy that image to the target systems; at the other end of the spectrum, the standard Debian installer can be preseeded with a configuration file giving the answers to the questions asked during the installation process. As a sort of middle ground, a hybrid tool such as FAI (Fully Automatic Installer) installs machines using the packaging system, but it also uses its own infrastructure for tasks that are more specific to massive deployments (such as starting, partitioning, configuration and so on).
Each of these solutions has its pros and cons: SystemImager works independently from any particular packaging system, which allows it to manage large sets of machines using several distinct Linux distributions. It also includes an update system that doesn't require a reinstallation, but this update system can only be reliable if the machines are not modified independently; in other words, the user must not update any software on their own, or install any other software. Similarly, security updates must not be automated, because they have to go through the centralized reference image maintained by SystemImager. This solution also requires the target machines to be homogenous, otherwise many different images would have to be kept and managed (an i386 image won't fit on a powerpc machine, and so on).
On the other hand, an automated installation using debian-installer can adapt to the specifics of each machine: the installer will fetch the appropriate kernel and software packages from the relevant repositories, detect available hardware, partition the whole hard disk to take advantage of all the available space, install the corresponding Debian system, and set up an appropriate bootloader. However, the standard installer will only install standard Debian versions, with the base system and a set of pre-selected “tasks”; this precludes installing a particular system with non-packaged applications. Fulfilling this particular need requires customizing the installer… Fortunately, the installer is very modular, and there are tools to automate most of the work required for this customization, most importantly simple-CDD (CDD being an acronym for Custom Debian Derivatives). Even the simple-CDD solution, however, only handles initial installations; this is usually not a problem since the APT tools allow efficient deployment of updates later on.
We will only give a rough overview of FAI, and skip SystemImager altogether (which is no longer in Debian), in order to focus more intently on debian-installer and simple-CDD, which are more interesting in a Debian-only context.
12.3.1. Fully Automatic Installer (FAI)
Fully Automatic Installer is probably the oldest automated deployment system for Debian, which explains its status as a reference; but its very flexible nature only just compensates for the complexity it involves.
FAI requires a server system to store deployment information and allow target machines to boot from the network. This server requires the fai-server package (or fai-quickstart, which also brings the required elements for a standard configuration).
FAI uses a specific approach for defining the various installable profiles. Instead of simply duplicating a reference installation, FAI is a full-fledged installer, fully configurable via a set of files and scripts stored on the server; the default location /srv/fai/config/ is not automatically created, so the administrator needs to create it along with the relevant files. Most of the times, these files will be customized from the example files available in the documentation for the fai-doc package, more particularly the /usr/share/doc/fai-doc/examples/simple/ directory.
Once the profiles are defined, the fai-setup command generates the elements required to start an FAI installation; this mostly means preparing or updating a minimal system (NFS-root) used during installation. An alternative is to generate a dedicated boot CD with fai-cd.
Creating all these configuration files requires some understanding of the way FAI works. A typical installation process is made of the following steps:
fetching a kernel from the network, and booting it;
mounting the root filesystem from NFS;
executing /usr/sbin/fai, which controls the rest of the process (the next steps are therefore initiated by this script);
copying the configuration space from the server into /fai/;
running fai-class. The /fai/class/[0-9][0-9]* scripts are executed in turn, and return names of “classes” that apply to the machine being installed; this information will serve as a base for the following steps. This allows for some flexibility in defining the services to be installed and configured.
fetching a number of configuration variables, depending on the relevant classes;
partitioning the disks and formatting the partitions, based on information provided in /fai/disk_config/class;
mounting said partitions;
installing the base system;
preseeding the Debconf database with fai-debconf;
fetching the list of available packages for APT;
installing the packages listed in /fai/package_config/class;
executing the post-configuration scripts, /fai/scripts/class/[0-9][0-9]*;
recording the installation logs, unmounting the partitions, and rebooting.
12.3.2. Preseeding Debian-Installer
At the end of the day, the best tool to install Debian systems should logically be the official Debian installer. This is why, right from its inception, debian-installer has been designed for automated use, taking advantage of the infrastructure provided by debconf. The latter allows, on the one hand, to reduce the number of questions asked (hidden questions will use the provided default answer), and on the other hand, to provide the default answers separately, so that installation can be non-interactive. This last feature is known as preseeding.
GOING FURTHER Debconf with a centralized database
Preseeding allows to provide a set of answers to Debconf questions at installation time, but these answers are static and do not evolve as time passes. Since already-installed machines may need upgrading, and new answers may become required, the /etc/debconf.conf configuration file can be set up so that Debconf uses external data sources (such as an LDAP directory server, or a remote file mounted via NFS or Samba). Several external data sources can be defined at the same time, and they complement one another. The local database is still used (for read-write access), but the remote databases are usually restricted to reading. The debconf.conf(5) manual page describes all the possibilities in detail.