Lead OSUOSL Developer Peter Krenesky has written an excellent blog post going over how the permission system works in Ganeti Web Manager. A key feature I’m looking forward to using more at the OSUOSL is managing our clusters with the following scenarios:

  • Fully managed - users have no access at all.  Only admins can create, reboot, or modify.
  • Partially managed - users can’t create virtual machines, but they have some limited ability to manage them.
  • Self Service - users can create virtual machines on demand.  They can create and manage their own virtual machines as needed.
  • User Managed Cluster - a user has control of an entire cluster.

The permission system in GWM will enable Ganeti cluster admins the ability to manage each cluster and virtual machine in finer detail. Ganeti by itself doesn’t come with any sort of user access management system, nor should it really. It makes sense to build tools like GWM on top of Ganeti to deal with such situations. I hope to see more features and bug fixes related to the permissions and quota system.

I’d love to see some feedback on how we implemented the system and how we can improve it!

Ganeti Web Manager logo

After three months of development Ganeti Web Manager 0.4 has been released! This project has been developed primarily by the OSU Open Source Lab with help from the folks at GRNET and several Google GCI students. Ganeti Web Manager (GWM) is a Django-based web application that connects to the Ganeti Remote API. It allows Ganeti administrators access to the various common tasks along with incorporating a permission system. GWM has a long ways to go in terms of implementing more of the RAPI features and UI improvements but this first release should be enough to get people to start using it in production. You can download Ganeti Web Manager here.

Features in 0.4:

  • Caching system
  • Permissions system:
    • User & Group management
    • Per cluster/virtual machine permissions
  • Basic VM management: Create, Delete, Start, Stop, Reboot, VNC Console
  • SSH key feed (for a ganeti post-install hook)
  • Basic quota system
  • Import tools

Basic Installation Requirements

GWM has a fairly low requirement footprint and only requires a minimum amount of Django dependencies.

Currently Firefox and Chrome browsers should work well although know that IE will have issues. I certainly hope whoever is using this application has at least Firefox installed. You will need the Java browser plugin in order to the VNC console. The VNC console requires direct access to the VNC port on the VM but we are working with GRNET to add in a VNC Auth Proxy to get around that.

Ganeti compatibility:

  • >= 2.2.x – supported
  • 2.1.x – mostly supported
  • 2.0.x – unsupported but may work
  • 1.x – unsupported

Screenshots:

List all virtual machines on a cluster:

List VMs in a cluster

Creating a new virtual machine form:

Creating a new virtual machine

Virtual machine reation output dynamically updating:

VM Creation output

Virtual machine VNC console using the java client.

VM VNC Console

Upcoming Features

We have lots of features we would like to eventually implement in GWM. You can see many of them on our issue tracker but here’s a summary of notable features we plan to do.

I’m excited to see where Ganeti Web Manager goes. I plan to start rolling it out at the OSUOSL very soon and giving access to some of the projects we host. If you would like to become a contributor to the project, please check us out on IRC in #ganeti-webmgr on Freenode.

Check my blog and Peter’s blog for more updates soon on Ganeti Web Manager.

One of the many large projects I’m working on at the OSUOSL has been migrating all of our virtualization over to Ganeti and KVM. Needless to say its kept me from updating my blog but I hope to make up for it. I thought I would give a rundown of how we use Ganeti at the OSUOSL and where we plan to move forward from there.

So far we have 10 clusters ranging in size from single nodes up to 4 node clusters. Each node is running Gentoo and managed with our cfengine setup. There are approximately 120 virtual machines deployed across all the clusters with the majority (~70) in our production cluster of four nodes. Each node in the production cluster is running between 17 to 18 KVM instances.

Project Ganeti Clusters

Several hosted projects including OSGeo, phpBB, and ECF have their own clusters which we fully manage on the node level. It works well for them as they don’t have to worry about  maintaining the virtualization cluster while giving them the flexibility of deploying dedicated VMs on their own hardware. I’ve been recommending moving towards this direction for current projects and new projects we get requests for. So far it seems to be working well for both the OSUOSL and the projects we host.

Image Deployment

For deployment we use ganeti-instance-image which is something I wrote to help make deployments faster and more flexible. It uses various types of images (tarball, filesystem dump, qemu-img) to unpack a pre-made system and deploy it with networking, grub, and serial fully functional. Creating the images is currently a manual process but I have it semi-automated using kickstart and preseed config files for building systems quickly and predictably. The amazing part is deploying a fully functional VM in under one minute using ganeti-instance-image.

Web-based Management

An upcoming tool that the OSUOSL is working on is a web-based frontend for managing Ganeti clusters called Ganeti Web Manager. Its written using the django framework and connecting to Ganeti via its RAPI protocol. Our lead developer Peter Krenesky and many of our students have been hard at work on this project in the last month and a half.

Some of the goals of this project include:

  • Permission system for users and how they access the cluster(s)
  • Easy VM deployment and management
  • Console access
  • Empower VM users

We’re very close to making our first release of ganeti-webmgr which should include a basic set of features. We still have a lot to work on and I look forward to seeing how it evolves.

The Network Engineering department at Oregon State University has a job opening for a Senior Network Engineer that closes on June 19, 2010. This person will be responsible for providing network access to every OSU faculty, student, and staff and ensuring fast, reliable, and secure data network connectivity within the University, among OSU’s regional University Partners, and to the Internet and Internet2. The OSUOSL operates within the department of Network Engineering at OSU however this position is not an OSUOSL position.

To view and/or apply for the position, go to http://jobs.oregonstate.edu and search for posting number 0005674.

Installing Ganeti is a relatively simple process on Gentoo. This post will go over the basics on getting it running on Gentoo. Its based primarily on a wiki page at the OSUOSL so check it out for more detailed instructions. I also recommend you read the upstream docs on Ganeti prior to installing it on your own. It will cover a lot more topics in detail and this post is intended just as a diff from that doc.

I should note that I have only installed Ganeti with KVM and have not tested it with Xen on Gentoo. I appreciate feedback if you have installed and used Xen with Ganeti on Gentoo. I’m also the current package maintainer for Ganeti and the related packages in Gentoo such as:

The first step is to install a base Gentoo system using the standard profile. You can use a hardened profile however if you intend to use ganeti-htools, it requires haskell which seems to have issues in hardened.

Configuring DNS

Ganeti requires the following names to resolve before you can set it up.

  • A master name for the cluster, this IP must be available (ganeti.example.org)
  • A name for each node or Dom0 (node1.example.org)
  • A name for each instance or virtual machine (instance1.example.org)

Kernel

DRBD is optional in Ganeti so you can skip this step if you’re not planning on using it. DRBD was recently included in the mainline kernel in 2.6.33 however Gentoo’s DRBD packages do not currently reflect that. I hope to get that changed soon but for now you have two options.

  1. Install gentoo-sources, drbd, and drbd-kernel
  2. Install gentoo-sources & enable drbd, install drbd without deps

For simplicity, I’ll describe option #2 above below. Check out the wiki page for #1.

DRBD requires you have the following option enabled. Make sure you’ve rebooted using a kernel with these options above before you continue.

Device Drivers --->
    <*> Connector - unified userspace <-> kernelspace linker

We recommend that you keyword both sys-cluster/drbd and sys-cluster/drbd-kernel so that you pull in the latest 8.3.x version.

echo "sys-cluster/drbd" >> /etc/portage/package.keywords
echo "sys-cluster/drbd-kernel" >> /etc/portage/package.keywords

Install DRBD.

emerge drbd

Ganeti uses DRBD in a unique way and requires the module to be loaded with specific settings. Add the autoload settings and load the module.

echo "drbd minor_count=255 usermode_helper=/bin/true" >> /etc/modules.autoload.d/kernel-2.6
modprobe drbd

If you forget this step, you will get an error similar to the one mentioned in this email thread.

Install Ganeti

Set the appropriate USE flags. In this case we will be using kvm with drbd.

echo "app-emulation/ganeti kvm drbd" >> /etc/portage/package.use

Install Ganeti (you might need to keyword other dependencies)

emerge ganeti

Configure Networking

There’s currently two methods for setting up networking: bridged or routed. I picked the bridged method mainly because I’m familiar with the setup and it seemed to be the simplest.

Ideally you should have a public network that will be used for communicating with the nodes and instances from the outside, and a backend private network that will be used by ganeti for DRBD, migrations, etc. Assuming your public IP (which node1.example.org should resolve to) is 10.1.0.11 and your backend IP is 192.168.1.11, you should edit /etc/conf.d/net to look something like this:

bridge_br0="eth0"
config_eth0=( "null" )

config_br0=( "10.1.0.11 netmask 255.255.254.0" )
routes_br0=( "default gw 10.1.0.1" )

# make sure eth0 is up before configuring br0
depend_br0() {
        need net.eth0
}

config_eth1=( "192.168.1.11 netmask 255.255.255.0" )

You can have a more complicated networking setup using VLAN tagging and bridging but I’ll go over that in another blog post.

Set the Hostname

Ganeti is picky about hostnames, and requires that the output of hostname be fully qualified. So make sure /etc/conf.d/hostname uses the FQDN and looks like this:

HOSTNAME="node1.example.org"

NOT like this:

HOSTNAME="node1"

Configure LVM

It is recommended that you edit this line in /etc/lvm/lvm.conf

filter = [ "r|/dev/nbd.*|", "a/.*/", "r|/dev/drbd[0-9]+|" ]

The important part is the

r|/dev/drbd[0-9]+|

entry, which will prevent LVM from scanning drbd devices.

Now, go ahead and create an LVM volume group with the disks you plan to use for instance storage. The default name that Ganeti prefers is xenvg but we recommend you choose something more useful for your infrastructure (we use ganeti).

pvcreate /dev/sda3
vgcreate ganeti /dev/sda3

Initialize the Cluster

Now we can initialize the cluster on the first node. The command below will do the following:

  • Set br0 as the primary interface for Ganeti communication
  • Set 192.168.1.11 as the DRBD ip for the node
  • Enable KVM
  • Set the default bridged interface for instances to br0
  • Set the default KVM settings to 2 vcpus & 512M RAM
  • Set the default kernel path to /boot/guest/vmlinuz-x86_64
  • Set the master DNS name is ganeti.example.org
gnt-cluster init --master-netdev=br0 \
  -g ganeti \
  -s 192.168.1.11 \
  --enabled-hypervisors=kvm \
  -N link=br0 \
  -B vcpus=2,memory=512M \
  -H kvm:kernel_path=/boot/guest/vmlinuz-x86_64
  ganeti.example.org

Now you have a ganeti cluster! Lets verify everything is setup correctly.

$ gnt-cluster verify
Sun May 16 22:43:00 2010 * Verifying global settings
Sun May 16 22:43:00 2010 * Gathering data (1 nodes)
Sun May 16 22:43:02 2010 * Verifying node status
Sun May 16 22:43:02 2010 * Verifying instance status
Sun May 16 22:43:02 2010 * Verifying orphan volumes
Sun May 16 22:43:02 2010 * Verifying remaining instances
Sun May 16 22:43:02 2010 * Verifying N+1 Memory redundancy
Sun May 16 22:43:02 2010 * Other Notes
Sun May 16 22:43:02 2010 * Hooks Results

Yay!

SSH Keys

Ganeti uses ssh to run some tasks but not for all tasks. During the initialization, it generated a new ssh key for the root user and installs it in /root/.ssh/authorized_keys. In our case, we manage that file with cfengine, so to work around it we copy the key as /root/.ssh/authorized_keys2 which ssh will automatically pick up.

Adding nother node

To add an additional node, you duplicate the setup steps above skipping initializing the cluster. Instead run the following command:

gnt-node add -s <node drbd_ip> <node hostname>

Next steps…

The next steps is actually deploying new virtual machines using Ganeti. I wrote a new instance creation script called ganeti-instance-image which uses disk images for deployment. I’m currently working on a new project website with detailed documentation and a blog post about it as well. We’re able to deploy new virtual machines (such as Ubuntu, Centos, or Gentoo) in under 30 seconds using this method!