Administering virtual machines with MLN


Listing 2 illustrates the use of a superclass. The superclass, which is called basic in Listing 2, provides a bundle of settings that are then available for host definitions. Listing 2 defines three hosts based on the superclass. The third host illustrates the technique of overriding a setting from the superclass. Of course, many more settings could be placed into the superclass or individual host stanzas as required. One project file can include multiple superclasses, and the superclasses can even be nested.

Substanzas, such as network interface definitions, which appear both within superclass and host definitions, are merged. Directives that appear in the host definition have precedence over directives within the superclass.

Listing 2

Working with a Superclass


Distributed Projects and Live Migration

So far, all the examples have been located on a single server. However, MLN supports distributed projects in which virtual machines are located on one or more remote hosts. The host and switch definitions in a distributed project require an additional service_host directive, which specifies the server location:

host rem-vm {
   template rhel5.vmdk
   service_host bigvmbox

Superclasses can include the service_host directive as well (as shown in Listing 2).

For servers that will host virtual machines, the MLN daemon must be running. In addition, the MLN daemon's configuration file, /etc/mln/mln.conf, must define the server to be referenced in project files and must grant access to remote systems from which projects will be managed. For example, the MLN daemon configuration file on the target computer for the rem-vm virtual machine would contain directives like the following:

service_host bigvmbox
daemon_allow 192.168.10.*

In this case, the daemon_allow setting permits access only from systems on the local subnet.

The argument to service_host can be either a resolvable hostname or an IP address.

With MLN, it is a very small step from distributed projects to live VM migration in Xen environments.

To move virtual machines from one server to another, all you need do is modify the service_host settings within the project file to reflect the desired new destination and then rebuild the project with the mln upgrade command. For example, the following commands modify and rebuild the italy project shown in Listing 2, resulting in the virtual machines migrating from the server denoted by bigvmbox to the one denoted newvmbox:

# vi italy.mln
Change bigvmbox to newvmbox
# mln upgrade -f italy.mnl

Note that this command can run even when the virtual machines within the project are currently running.

Live migration also requires a few preparatory steps:

  • All of the servers must run the MLN daemon. Access control for the daemon must grant access to the other servers involved in the migration.
  • The virtual machines must use shared storage to hold images that will be accessible to all relevant servers. The best solution is usually a storage area network (SAN) controlled by the logical volume manager (LVM), but you can also use a shared NFS directory for testing, especially when performance is not a consideration. The location is specified in the host definitions in the project (see Listing 3).

In addition, with a SAN, the /etc/mln/mln.conf file on all relevant servers must contain the san_path directive. The argument for san_path specifies the location of the SAN, which is either the volume group name (like lvm_vg within the host definition) or the local mount point for the SAN.

Xen must be configured to allow migration on all relevant servers via the following entries in the Xen daemon's configuration file /etc/xen/xend-config.sxp:

(xend-address '')
(xend-relocation-hosts-allow '^localhost$ ^.*\\.ahania\\.com$')

The argument in the second directive is a single-quoted list of regular expressions specifying allowed hosts. In this case, we specify the local host and hosts anywhere within the domain.

Listing 3

MLN with a SAN


One Is Easy, and So Are 60

Consider the case of an operating system class taught to, say, 120 students. The students are organized in groups of two for lab work, with each group using a network of one Linux and one Windows virtual machine to solve the course exercises. The Linux virtual machine will have two network cards and share its connection to the LAN with the Windows virtual machine.

The challenge for the instructor is to create 60 of those mini-networks quickly, each with an individual public IP address and password.

The main philosophy for this task is "design once, deploy often." All 60 mini-networks must be as consistent as possible, and the system also must be easy to reconfigure, so if you later decide that the Windows virtual machines need more memory, you can modify all of them easily. Putting all of the virtual machines into a single project might seem like an easy way to accomplish this, but a single project would make it more difficult to manage one group's virtual machines separately.

A better solution is to use one project per student group. However, it will not be necessary to write 60 complete project definitions. The #include statement lets you compress as much information as possible, so each project file only contains the information unique to that project. For example, you can create 60 small project files and let them all point to the same main configuration file (see Listing 4).

Listing 4

Use of the #include Statement


The items beginning with a dollar sign are variable definitions, which will be used within the main configuration file.

Listing 5 shows the main file, oscourse.mln. (Note that this file has no global stanza.)

Listing 5



The hvm directive in the definition of the virtual machine running Windows XP indicates that it uses Xen full (hardware) virtualization. The Linux virtual machine uses Xen paravirtualization. As such, networking configuration is internal to this virtual machine (as IP address, so it is not configured by MLN and there is no network substanza. This configuration file also introduces the root_passwd keyword, as well as two keywords that set up the VNC display.

With a shell or Perl script, you can loop over the various project files with the mln create, the mln update, or both commands if necessary, as in when a change occurs to a customized template file used by the Linux virtual machine. Also, you can run mln commands manually.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • KVM Front Ends

    If you want to care for a zoo full of exotic KVM guest systems on your desktop, you could use a little help from a graphical front end.

  • Virtualization Intro

    Good tools are half the battle – even if you are just managing virtual machines. This month we take a practical look at virtualization, and we show you a new threat to watch for in the virtual future.

  • Virtual Machines Intro

    Virtualization can save you time, money, and effort, but you’ll need to find the right tool for the task.

  • VMware Monitoring

    Dynamic resource allocation and migration of virtual machines between hosts mean that VMware environments pose new monitoring challenges. A new version of the free OpenNMS network management tool now includes an option for monitoring VMware-based infrastructures.

  • Networking with VirtualBox

    Tour the VirtualBox virtualization tool, a free and easy environment for virtual versions of Linux, Unix, and Windows.

comments powered by Disqus