Some of the great promises of virtualization are that new servers can be instantiated very quickly and that developers will have as many (low priority) test virtual machines available as they want. One of the great worries of system administrators is that people will make use of these capabilities!
Sure, your hardware inventory shrinks and you can save a lot of cost that way, but you suddenly end up running two or three times the number of virtual systems that you used to have physical systems. Licensing isn't an issue, since both Red Hat and SuSE allow you to run a bunch of virtual instances per supported system, but all these operating system instances will have to be managed somehow...
There are a number of different approaches to managing an ever growing number of operating system instances.
Large scale system management interfaces
System management tasks are done through large scale system management programs. Systems are generally classified as a certain profile, and manipulation of all the systems in a profile can be done through a central management interface.
Most of this kind of system management applies to both physical systems and virtual systems. The extra functionality for virtual systems would be the instantiation of virtual machines when the administrator asks for them. If only hardware sprung into existance that easily...
One example of this kind of system management is Red Hat Network for system installation and updates, combined with something like puppet for configuration management.
Stateless Linux
A different approach is to simply not care much about what's inside each virtual machine. This is feasible if all the custom data lives outside of the virtual machine (eg. on a SAN or other network storage) and the virtual machine really only contains the operating system.
If a virtual machine (or a physical machine) breaks, it is reinstalled from scratch, the configuration files are generated and deployed and the virtual machine is ready for action again.
System management libraries
There are a number of libraries out there to help abstract out the details of the various virtualization solutions. Libraries like Xen CIM and Cimbiote allow users to attach management software using the CIM API to their virtualized Linux systems.
libvirt abstracts away the virtualization technology itself, which means that management software only needs to be written once in order to be able to manage different virtualization technologies. Currently (October 2009) libvirt manages:
The Xen hypervisor on Linux and Solaris hosts.
The QEMU emulator
The KVM Linux hypervisor
The LXC Linux container system
The OpenVZ Linux container system
The UML (User Mode Linux) paravirtualized kernel
The VirtualBox hypervisor
Single system management
For managing Xen on developer works and other small setups, distributions have been adding tools to easily install and monitor virtual machines. SuSE has Xen virtual machine installation support in YaST, while Fedora and RHEL have virt-manager to monitor, manage and create virtual machines. Unfortunately, virt-manager does not support management of virtual machines on different physical machines. This support is planned to use the new Xen management API in the new Xen 3.0.4. ConVirt (formerly XenMan) is a project very similar to virt-manager but with the added feature of controlling vms on seperate physical machines with ssh access to dom0.
The Xen initscripts also save virtual machines when the host OS is about to reboot, and restore those virtual machines on startup. Do not be surprised if your Xen guests have a higher uptime than domain 0...
Grid / cluster computing
On the other end of the spectrum, there are people who would like to fully automate some of the aspects of managing virtual machines. Just specify something along the lines of "I want a database server with 1GB RAM and 50GB disk space" and it should appear automatically.
Nobody has to care on which exact physical computer this virtual machine runs. If something happens to that physical computer, the cluster (or grid) software should automatically start the virtual machine on another computer. If the cluster software knows that something is about to happen, it should do a live migration of the virtual machine, so the hardware can be switched off without application downtime.
Several grid computing packages know how to schedule batch jobs across a cluster, and some of the Linux cluster suites are able to do high availability failover and live migration of virtual machines. Full automatic deployment of virtual machines and cost optimized load balancing do not appear to have been implemented yet.