The MLN ProjectComplex virtual machine management made easy |
Navigation |
Plug-ins for MLNMLN supports a flexible plug-in architecture that enables you to write your own extensions to MLN. Plug-ins can be used to either modify the project itself before the project builds, like adding certain sanity checks to your projects. They can also be used to extend the configuration domain of MLN towards the filesystem of the VM. You can write plug-ins that configure a piece of software, like an apache-plug-in. For more information on how to write plug-ins, read the plug-in howto in the MLN manual.InstallingTo install a plug-in, place it in the /etc/mln/plugins folder, or in ~/.mln_plugins if you only want them to be available to your own user. Follow the instruction of the given plug-in for its usage.See installed pluginsThe list of installed plugins and their version is visible through this command:mln write_config Download from CVSYou can browse the latest CVS versions of all the plugins here: CVS:pluginsSubmitting pluginsPlease join our mailing list and share your plugins with us. We will then include them on this page.Publicly available plug-ins( * = comes with mln-latest tarball )
Amazon EC2 cloud computing pluginThe MLN plugin: Download ec2.plThis plugin allows you to manage Amazon EC2 instances just as any other VM on your server. In fact, you can use MLN and the EC2 plugin without Xen installed on your local machine if you are only interested in running virtual machines in the cloud. MLN's strong points when used with EC2:
iSCSI plugin and backend serverThe MLN plugin: Download iscsi.plThe backend server script: MLN-server-backend This plugin enables MLN to use iSCSI for filesystems. Live migration is supported using this plugin. One can use either iSCSI hardware with pre-created targets or set up a Linux system as an iSCSI server with dynamic creation/deletion of filesystems by request from the MLN servers. Please read the chapter in the MLN manual on how to set it up. mln-manual.pdf VMware Server pluginDownload vmware.plThis plugin is one of the most advanced plugins and should be considered as a template for anyone who wants to provide support for another virtualization techology. The plugin assumes that you have VMware server installed. It has been tested with the 1.0.* versions. It mostly relies on the vmware-cmd for VM start/stop and creation. TemplatesYou need to have VMware Server filesystems which MLN can use as templates. You can use an existing VM but make sure it is a pre-allocated image. Also, it should be of your wanted size. This plugin does not resize the VM's filesystem for you (yet).The pre-allocated VM filesystems consist of two files: myVM.vmdk and myVM-flat.vmdk. The later is the largest of them and contains the actual disk image. Important: When you make a copy, remember that the -flat.vmdk file needs to keep its original filename, even if the small file changes its name. For example: If I would copy those two image-files into my templates directory, I would name them like this: ls /opt/mln/templates Debian-4.0.vmdk myVM-flat.vmdkThe reason is that the name myVM-flat.vmdk is hardcoded in the other file. host example { vmware template Debian-4.0.vmdk network eth0 { address dhcp } }Two VMware VMs where "gateway" has two network cards and is gateway for the "backend". host gateway { vmware template Debian-4.0.vmdk # Outside network eth0 { address dhcp } # Internal network eth1 { address 10.0.0.1 netmask 255.255.255.0 switch lan } } host backend { vmware template Debian-4.0.vmdk network eth0 { address 10.0.0.2 netmask 255.255.255.0 gateway 10.0.0.1 switch lan } } switch lan { vmware }The use of the VMware Server plugin should be transparent in all other ways except the following:
Postfix pluginDownload postfix.plA simple plugin which demonstrates how postfix can be configured from MLN. The plugin assumes that postfix is allready installed on the VM and will configure main.cf. Only hostname and relayhost are set, but you can easily expand it to set more parameters. host example { postfix { relayhost my.relay.host } } Fedora pluginDownload fedora.plThis is a plugin which adds users and groups and passwords for Fedora filesystems. It also configures network devices. The plugin works transparently and no extra MLN syntax is required. HostsFile pluginDownload hostsFile.plWhen building larger network topologies, one wants to have /etc/hosts files created on each VM. This plugin creates those and takes care to put the correct IP address from every VMs particular point of view. Example: A node VM should have the gateways internal (LAN) address in its /etc/hosts file, not the external. SSHkey pluginDownload sshkey.plThis plugin supports adding public SSH keys to users inside the VM so that one can log in without password. A very convenient plugin if you want to create a VM which monitoring tools like Nagios or similar can log into automatically. Remember to add the corresponding user too. host example { users { joe llkae93ajefij adam ljotaewddaa } sshkey { joeMake sure that your editor does not crop the line. It becomes very long. winConfig pluginDownload winConfig.plThis plugin is not recommended for production usage, but it demonstrates how MLN can be used to configure other OS'es than Linux. This plugin will create a bat script which will run when the VM boots for the first time. (You need to have a Windows VM template which is preconfigured to run that script). The bat script will add users and also add them to groups. host winexample { xen hvm winconfig { users { joe VNCpluginDownload vncplugin.plThis plugin sets a VNC server password. Since the vncpasswd command is interactive, this plugin will write a startup script which uses exptect to communicate with the command. This plugin only works for filesystems where vncpasswd and expect are installed. The VNC password file is stored in /root/.vncpasswd host example { vncplugin vncpasswd cleartextpassword } Apache2 pluginDownload apache.plThis plugin is similar to the postfix plugin. It is straight forward and only configures the location of the DocumentRoot directive of the default apache site. host webserver { apache { DocumentRoot /etc/HTML } } Autenum pluginDownload autoenum.plThe autoenum plugin was created with the intention of automating some common repetitive tasks encountered when using MLN in the context of both teaching laboratories and computing clusters. It simplifies the creation of MLN configurations that are consistent yet otherwise lengthy. Its features include specifying the number of hosts to create, the superclass they will belong to, their networking information, creating users, choosing a hostname-space, and finally selecting the physical hosts they will run on. At the moment, only one autoenum block is supported, which means that the virtual network complexity it can represent is limited. Refer to the example autoenum configuration block below for more information on usage. global { [...] autoenum { # The superclass to which all # hosts created by autoenum will # belong. superclass hosts # The number of autoenum hosts to # create. numhosts 50 # Auto-enumerate static addresses? address auto # What number shall the first auto- # enumerated IP address be? (This # is only the fourth octet, as the # autoenum plugin only supports # auto-enumerating class C networks.) # If you use a superclass that specifies # DHCP, you will not need this or the # "net" parameter below. addresses_begin 100 # The class C (24-bit netmask) network # that will serve as the basis for all # the auto-enumerated IP addresses. net 128.39.74.0 # Here you can specify the hostname prefix # for each VM. If you do not set this, it # will default to "node," e.g. node1, node2, # etc... hostprefix ubuntu # The autouser parameter will setup a # user of the same name as the node, # using the provided password hash. This # is useful in situations where you are # using autoenum to give a large number # of people their own individual VMs. And # so their user account on the VM will be # the same as the hostname, simplifying # your environmental accounting. You can # use the utility "mkpasswd" to yield a # proper password hash. autouser mNVBqcTkw/Ua2 # The service_hosts block contains a list # of dom0 nodes that will host the VMs. # It can accept three forms of syntax: # # The following line will specify the # phys host named "odin" to run all the # domains. # odin all # # The following lines will specify that # the phys host "thor" will run 2 VMs # and the phys host "loki" will run 1 # VM. # thor 2 # loki 1 # # The following lines specify that the # phys host "thor" will run 2 VMs, "loki" # will run 1 VM, and odin will run all # the remaining VMs, no matter how many # there are. # thor 2 # loki 1 # odin # # This could also be a "#include filename" # if you have a long specification. service_hosts { thor 2 loki 1 odin } } } Cluster PluginDownload cluster.plThe cluster MLN plugin is designed to automatically populate important head node and compute node configuration files. This was motivated by the fact that MLN (without the compute plugin) inherently provides a fast way to setup VMs that could serve as clusters. However, providing the infrastructural configuration glue was still a manual process. And so this plugin requires simply the specification of the head node. All other hosts in the project will be considered compute nodes. It assumes the use of the TORQUE (http://www.clusterresources.com/pages/products/torque-resource-manager.php) open source resource manager, used for batch job control. All the compute nodes will be automatically added to the nodes file on the head node. Additionally, the head node will export a home directory to all the compute nodes. On the compute nodes, the automounter is configured to NFS mount home directories from the head node (NFS client functionality is assumed to be available in the VM). The usage is simple, as seen below in a global block. global { [...] cluster{ head node1 } } |