Entries by Mark Round

Introduction

I've been using and evaluating Citrix XenServer now for a while, and felt I should really post a review. I haven't seen much detailed coverage of this product at the level I'm interested in, so what follows is my take on it from a Unix Sysadmin's perspective. There won't be any funky screenshots or graphics; instead, I tried to cover the sort of things I wanted to know about when I was looking at it as a candidate for our virtualization solution at work.  

After all, implementing a new hypervisor is a big step, and a decision that you'll likely be stuck with for a long time. If there's anything else you'd like to know, just post in the comments section and I'll do my best to answer.

As some background: I've been using the open source Xen hypervisor as a virtualization platform, alongside VMware for Windows hosts for a good few years now at work. Part of the reason for picking Xen was that it was the standard on the systems I inherited, and also it was free and well-supported on most Linux distributions at the time. To date, I have been using CentOS as a Dom0 - as it's a free "clone" of Red Hat Enterprise Linux, it follows the same support schedules (up to 2014 for RHEL/CentOS 5.x) and is supported by pretty much every hardware vendor out there. It also has the libvirt tools built into it, as well as up to date packages for storage infrastructure such as DRBD and open-iscsi. It's well supported, and even though it is a conservative "stable" distro, point releases occur regularly with back-ported drivers and user-land updates.

With some work, you can roll your own management tools and scripts, and end up with a very flexible solution. However, it lacks some management ease of use, particularly for other systems administrators who may not be totally comfortable in a Linux environment. We also wanted to standardise on one virtualization platform if possible, and this all coincided nicely with a planned upgrade/migration off the VMware stack.

XenServer therefore presents a very attractive proposition: A well known, widely tested and supported open source hypervisor, with a superior management stack. The basic product is free, although support and enterprise features are available for a price. The prices for the advanced features are very reasonable, all the more so when you compare against VMware's offerings. Also consider that the free product allows you to connect to a wide range of networked storage systems and includes live migration, something that the free ESXi doesn't offer.

All of what follows covers the freely downloadable XenServer 5.6; Both Dell and HP offer embedded versions for some of their servers, however running and managing these systems should be near enough identical apart from the installation steps.

Update : Just after writing this, the beta of "FP1" (an update to XenServer 5.6) was announced. Full details of what will be in this update are here in the release notes. It looks like there will be plenty of significant improvements across all areas (including MPP RDAC, scheduled backups, supported jumbo frames, on-line coalescing of snapshot space and various other things of particular interest to me). Bear in mind when reading this review, that many of the little issues I have with XenServer may well be resolved in the upcoming version, and other areas may be totally overhauled. As soon as the final version is released I'll post a full update...

Update 2 : FP1 is indeed a big improvement. I've been using it in production now for a few months and should have an update soon, covering the new features such as the distributed switch, self-service portal etc.

Click the "Continue reading" link for the full review.

We have recently started using Citrix Xenserver in production at work (fantastic product, see my review for more information) and needed a simple backup solution. Our VMs run from an iSCSI SAN and are backed up daily through various methods - e.g. Bacula for the Unix/Linux systems. However, we wanted the ability to quickly roll back to a previous VM snapshot, and get up and running quickly if our SAN failed for whatever reason. Our solution was to create a large shared NFS storage repository, and periodically snapshot VMs and copy the templates over to this SR. Doing this means that if the SAN fails, we can create a new VM quickly from this NFS store (using the Xenserver's local disks, or even the NFS SR itself as storage). Once up and running, we can bring VMs back up to date by restoring the latest backup to them.

In order to automate this, I wrote a quick script which I thought may prove useful to someone else, so decided to post it here : snapback.sh.

Update: This script is now being hosted at GitHub. This means you can check out the latest version from there, by doing :

git clone https://github.com/markround/XenServer-snapshot-backup.git

or accessing the raw script file at https://github.com/markround/XenServer-snapshot-backup/raw/master/snapback.sh

It is very simple, and although it may serve well as your only backup solution, it's really intended as an image-level compliment to your primary file-system based backup system such as Bacula, Amanda, Netbackup etc. It also has not had much testing, and I fully appreciate the scripting is pretty rudimentary and could do with some optimisation - there's no error checking, for instance. I kept it pretty verbose on purpose though, so you can get a good idea of exactly what it's doing at each step; it may be better to think of this as a template you can base your own scripts off!

Overview

The script creates a snapshot of a running VM on a configurable schedule, and then creates a template from this snapshot. It will copy all these backup templates over to a configurable storage repository, and then clean up any old backups according to a specified retention policy. These backups are full backups, so if you have a 10GB VM and keep 7 previous copies you will need a total of 80GB disk space on your backup VM. Non-running VMs, and those not configured (as detailed below) will be skipped.

Important: See http://support.citrix.com/article/CTX123400. After backing up each VM, you will end up with a new VDI, so you may need to manually coalesce your VDIs again to reclaim disk space.

Installation and usage

2 1 * * * root /usr/local/bin/snapback.sh > /var/log/snapback.log 2>&1

This will also record a log of it's actions to /var/log/snapback.log. You now need to edit the script and change the DEST_SR variable to the UUID of your backup storage repository. You can find this value by clicking on the SR in Xencenter; the UUID will be displayed as a value like "2c01dc26-f525-70d6-dedf-00baaec76645".

Lastly, you need to configure your backup and retention policy for your VMs. In Xencenter, right click your VM, and select "Properties". Click on "Custom Fields", and then "Edit Custom Fields". You should add two text fields :

• backup : Can be one of "daily", "weekly", or "monthly". If it is set to weekly, it will by default run on a Sunday, and if it set to monthly, it will run on the first Sunday of the month. This day can be changed at the top of the script - see the WEEKLY_ON and MONTHLY_ON variables.
• retain : How many previous backups (in addition to the currently running backup) to keep. So, setting this to a value of "2" would mean that after a backup has run, you would end up with 3 backups in total.

Adding a custom field

The script will look for these fields when it is run, and will skip any VM that doesn't have them set. You can also see them in the Xencenter summary and properties for the VM :

VM summary showing the custom fields

You can now either run the script manually, or wait until the cron job kicks off. It will produce a detailed log to the console (or log file if run through cron), and when it's finished, you'll see your template backup VMs listed in Xencenter, similar to this :

Backups listed in Xencenter

Well, that's that, then. Solaris as we knew it is pretty much dead. I've suspected for a while now that Oracle's intentions regarding Solaris were not what the community, or us "old-school" Solaris sysadmins wanted or had hoped for.

In the last few months, Oracle have completely alienated and scared off the community around OpenSolaris, killed any lines of communication by clamping down on employee blogs and have ignored open letters from highly influential and important community members begging for any kind of information. They’ve forbidden Sun/Oracle employees from heading up the Solaris user groups and booted the meetings out of their buildings; turned Solaris 10 into a 90-day trial, and pushed back the 2010.x release of OpenSolaris with no word as to it’s planned release date, or even if it is being continued as a product. And now, in a final act of desperation, the OGB has essentially threatened to "shoot itself in the head".

Thanks to the awesome work of Boogie Shafer, there is now a FreeBSD port of my iostat scripts and templates for Cacti. I have included the modified tarball that was sent to me, this is inside the archive as "cacti-iostat-1.x-boogie_freebsd_linux_changes.tar.gz".

FreeBSD users should unpack this archive and follow the instructions inside. I have not had time to go through and merge these changes into one unified distribution yet, but as people were asking for the FreeBSD port, here it is! The next release of these scripts should see the FreeBSD scripts and templates etc. merged in, much the same as the Solaris modifications by Marwan Shaher and Eric Schoeller.

Follow the link to the original post to find the download link.

• No built in graphing (seriously, Dell - WTF?), but you can do it from the CLI - see here.
  
• Can't resize or change the I/O profile of a virtual disk once it's setup. This is a real pain, so make sure you set things up correctly the first time! You can however change the RAID level of a disk group once it's been created.
  
• You need a Windows or RHEL box to run the administration GUI on - I'm sure you can probably hack a way to get the CLI running under Debian, but I haven't tried. You're probably straight out of luck if you want to run it on anything else like Solaris.
• Can't mix SAS and SATA in the same enclosure. The controllers do support SATA as well as SAS, although SATA drives don't show up as options in the Dell pricing configuration thingy. Our account manager advised us that although technically you can mix SAS and SATA in the same enclosure, they'd experienced a higher than average number of disk failures in that configuration, due to the vibration patterns created by disks spinning at different rates (15K SAS and 7.2K SATA). If you need to mix the two types, your only real option is to attach a MD1000 array to the back (you can add up to two of these) and have each chassis filled with just one type of drive.
  

The hardware failover works nicely - the array is active/passive for each virtual disk, as both controllers are typically active, each handling separate virtual disks for load-balancing purposes. When a controller fails, the remaining "good" controller takes over the virtual disks or disk groups from the failed controller. Failback is pretty transparent - the GUI guides you through the steps, but I found that simply inserting a replacement HD/Controller/etc. just did the job automagically.

Multipath support under RHEL/CentOS with multipath-tools (dm-multipath) works fine with some tweaking - it uses the RDAC modules which lead to some oddness on CentOS 5.3. What tends to happen is that the first time device mapper picks up the paths, RDAC doesn't get a chance to initialise things properly (scsi_dh_rdac module isn't loaded) so you end up with all sorts of SCSI errors showing up in your logs. After flushing your paths (multipath -F) and restarting multipathd, things are OK. This is apparently fixed in RHEL 5.4, so should make it's way out to CentOS from there. I'm unsure what the status is on other distros, though.

It also works great with Citrix Xenserver, although you have to use MPP-RDAC instead of DM-Multipath due to performance issues with the latter.

My multipath.conf contains the following :

devices {
        device {
                vendor "DELL"
                product "MD3000i"
                product_blacklist "Universal Xport"
                path_grouping_policy group_by_prio
                getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
                path_checker rdac
                prio_callout "/sbin/mpath_prio_rdac /dev/%n"
                hardware_handler "1 rdac"
                failback immediate
        }
}

360026b90002ab6f40000056a4aa9e87b dm-12 DELL,MD3000i
[size=409G][features=0][hwhandler=1 rdac][rw]
_ round-robin 0 [prio=200][active]
 _ 21:0:0:1  sdi 8:128 [active][ready]
 _ 22:0:0:1  sdj 8:144 [active][ready]
_ round-robin 0 [prio=0][enabled]
 _ 20:0:0:1  sdg 8:96  [active][ghost]
 _ 23:0:0:1  sdh 8:112 [active][ghost] 

Update: It looks like the admin tool and SMcli are just shell script wrappers that run Java apps. I tried a quick'n'dirty hack of installing everything under RHEL, tarring up /opt/dell and /var/opt/SM and then transferring them over to a Debian Lenny host. All I had to change was the #!/bin/sh to #!/bin/bash at the top of the SMcli and SMclient wrappers, and they seem to work. I haven't put them through any serious testing though...

Part 1 - Overview, network layout and DRBD installation
Part 2 - DRBD and LVM
Part 3 - Heartbeat and automated failover
Part 4 - iSCSI and IP failover
Part 5 - Multipathing and client configuration
Part 6 - Anything left over!

In this part of the series, we'll configure an iSCSI client ("initiator"), connect it to the storage servers and set up multipathing. Note : Since Debian Lenny has been released since this series of articles started, that's the version we'll use for the client.

If you refer back to part one to refresh your memory of the network layout, you can see that the storage client ("badger" in that diagram) should have 3 network interfaces :

• eth0 : 172.16.7.x for the management interface, this is what you'll use to SSH into it.

And two storage interfaces. As the storage servers ("targets") are using 192.168.x.1 and 2, I've given this client the following addresses :

• eth1: 192.168.1.10
• eth2: 192.168.2.10

Starting at .10 on each range keeps things clear - I've found it can help to have a policy of servers being in a range of, say, 1 to 10, and clients being above this. Before we continue, make sure that these interfaces are configured, and you can ping the storage server over both interfaces, e.g. try pinging 192.168.1.1 and 192.168.2.1.

Assuming the underlying networking is configured and working, the first thing we need to do is install open-iscsi (which is the "initiator" - the iSCSI client). This is done by a simple :

# aptitude install open-iscsi

You should see the package get installed, and the service started :

Setting up open-iscsi (2.0.870~rc3-0.4) ...
Starting iSCSI initiator service: iscsid.
Setting up iSCSI targets:
iscsiadm: No records found!

At this point, we have all we need to start setting up some connections. 

Just a quick update to my Cacti iostat monitoring scripts and templates - thanks to the work of Marwan Shaher and Eric Schoeller, the package now supports Solaris! The updated package is available here :  cacti-iostat-1.4.tar.gz.

I have also updated the original blog post with the new package.

My response to today's news:

I was talking a few days ago, and the subject of password security came up. Now, we all know that we're supposed to pick a secure password, use at least 8 characters and never to pick a word from the dictionary. But then I was asked how long it would take to brute-force a password using a dictionary attack, and I had to admit I had no idea. I knew it would only be a matter of minutes, but wanted to give it a try.

So, For anyone who is interested, I knocked up a quick BASH script to compare a MD5 hashed password against the contents of /usr/share/dict/words, which on a Red Hat 5.3 system contains 479,623 words. The script is as follows :

#!/bin/bash
TARGET_HASH=$1
while read WORD; do
        WORD_HASH=$(echo $WORD | md5sum | awk '{print $1}')
        if [ "$WORD_HASH" == "$TARGET_HASH" ]; then
                echo "Found match!"
                echo "Password is : $WORD"
                exit
        fi
done < /usr/share/dict/words

Now, this was just a quick hack to satisfy my curiosity, and only something I threw together after a few seconds. Of particular relevance is the fact that it's a shell script, and uses a lot of forking to generate the MD5 hashes of the dictionary. If I wrote it in C, I'm sure it would be faster by an order of magnitude.

But anyway, on to the test - I created a MD5 phrase for it to crack, and timed it :

# time ./crack.sh 3a783fb2aa3a2318499f0a60d7ef6078
Found match!
Password is : hedgehog

real    8m43.432s
user    1m48.410s
sys     8m27.030s

Not bad - just under 9 minutes. Obviously, that'd take longer if I used a word starting with "x" or "z"!  I then realised it would be a lot faster if I generated a "compiled" version of the dictionary file with the MD5 hashes preprepared :

while read WORD; do echo "$WORD:$(echo $WORD | md5sum | awk '{print $1}')"; done < /usr/share/dict/words  > md5.txt

Obviously, I could then generate compiled dictionary files for each hashing algorithm I wanted to crack (assuming that they are non-Salted algorithms).  This took around 30 minutes, but now I don't have to generate the hashes again, all I need to do is check against the second column of the file for a match. It is also irrelevant whether the word lies near the start or end of the file, it now takes about the same time to find a match :

# time grep ac23b37db0039dda62896bb21f312755 md5.txt | cut -d':' -f1
aardvark

real    0m0.019s
user    0m0.008s
sys     0m0.011s

# time grep 981fe627ab4906b677ce9d3e6eff499f md5.txt | cut -d':' -f1
zoology

real    0m0.019s
user    0m0.006s
sys     0m0.014s

So there you have it. It was an interesting way to spend a few minutes, and I now have an answer whenever someone asks "how long would it take to crack a password based on a dictionary word": Assuming you have the compiled hash files, around 0.019 seconds.

Just a quick post this time, as I thought this may help others in the same situation I found myself in recently. At work, we've been using OpenVPN which works a treat with Unix clients; Windows clients (Vista in particular) were more problematic, though.

None of our regular users have admin privileges (for obvious reasons), but this caused problems with the routing setup: users could use the GUI tool, but could not create the necessary routes required to direct traffic over the VPN. We experimented for a while with setting up persistent routes, but this didn't work for multiple users. I'd read all kinds of posts about running the executables as an Administrator, disabling Vista UAC, registry tweaks and other voodoo - either they didn't work, or they were unacceptable in our environment.

I then hit upon a simple workaround that also seems to work on Windows XP: Just add the user to the "Network Configuration Operators" group:

Administrative Tools -> Computer Management -> Local Users and Groups -> Groups -> Network Configuration Operators

Now, everything works right out of the box on Vista SP1 with the 2.1RC builds of OpenVPN (OpenVPN 2.1_rc15 was the version we tested). You have to install this as an Administrator, and you do have to be happy with giving your VPN users slightly elevated privileges - but at least it stops way short of having to give them administrator rights.

For reference, here's the client config file as well :

client
script-security 3 system
dev tun
proto udp
remote <openvpn server address> 1194
nobind
persist-key
persist-tun
ca ca.crt
cert <user.name>.crt
key <user.name>.key
cipher BF-CBC 
comp-lzo
verb 3
mute 20
route-method exe
route-delay 2

This is part 4 of a series on building a redundant iSCSI and NFS SAN with Debian.

Part 1 - Overview, network layout and DRBD installation
Part 2 - DRBD and LVM
Part 3 - Heartbeat and automated failover
Part 4 - iSCSI and IP failover
Part 5 - Multipathing and client configuration
Part 6 - Anything left over!

In this part, we'll configure Heartbeat to manage IP address failover on the two storage interfaces. We'll also install and configure an iSCSI target to provide block-level storage to clients.

This is part 3 of a series on building a redundant iSCSI and NFS SAN with Debian.

Part 1 - Overview, network layout and DRBD installation
Part 2 - DRBD and LVM
Part 3 - Heartbeat and automated failover
Part 4 - iSCSI and IP failover
Part 5 - Multipathing and client configuration
Part 6 - Anything left over!

Introduction

In the last two guides, we set up a DRBD resource and LVM volume group which we could manually migrate between the two cluster nodes. In this guide, we'll set up the Heartbeat cluster software to handle automatic migration of services between the two nodes in our cluster ("failover").

The version of Heartbeat included in Debian Etch is 1.x. It is a very simple system, and is limited to two node clusters, making it ideal for something simple such as failover for services between two nodes. The current 2.x branch is a lot more complicated, and has a new XML configuration format, although it can still be used with the original 1.x format files. Although it adds many useful features, it's overkill for our needs at the moment - plus, sticking to 1.x avoids the need to install software not included in the current stable distribution.

I've been looking for ages for a tool to parse the output from "iostat" on Linux, and graph it in Cacti. I found a few scripts and templates that did some of what I was looking for (disk I/O etc.), but nothing that gave me the full set of statistics such as queue length, utilisation, service time etc. I finally got round to writing my own set of templates and a data gathering script to provide this information, and it seems to work very well. So that others can benefit, I've posted the package archive and a brief description over on the Cacti forums (click Continue Reading for a download link to an updated version - the one on the Cacti forums has a bug so that it won't work with all versions of sysstat). Below are a couple of sample graphs to give you an idea of what it can do - there's also a few more samples posted in the Cacti forums thread :

Displaying iostat's kB/s data source.

Timing information from iostat (average wait and service time)

Installation is a simple matter of creating a cron job to gather iostat data, extending your snmpd.conf to call the included iostat.pl script, and then importing the templates. Full instructions are included in the README within the archive (click the Continue Reading link to see them), but if you have any comments, suggestions or problems please let me know!

Blastwave is a registered trademark of Blastwave.org Inc. in the
United States and Canada. All assets of Blastwave.org Inc. are frozen
until further notice. All Solaris(tm) related open source software
work and services are cancelled. All websites, documents and binary
software packages that bear the mark Blastwave or Blastwave(tm) are no
longer available until further notice.

There's plenty more I could say, but at this point I think it's perhaps better to simply leave it. It's a sad day for me: seeing years of work towards something that I believed in, and helped a great many people, all go to ruin. It's even sadder for the Solaris community as a whole; this was a true grass-roots organisation - made up from like-minded Solaris users, admins, programmers and fans - who gave up countless hours of their own time to help others. I think the least we deserve is an explanation, but somehow I don't think one at this stage would make any difference anyway.

Update : People have been mailing me to say the main page is back up - true, but it's a case of "the lights are on, but no one's home". Check the thread in comp.unix.solaris.