pixel is in Charge

Recently, I acquired a used Xserve RAID. Good storage capacity, and way cheaper than buying new drives. In the interests of data security I'd like easily removed drives, such as those in the RAID, to have their contents encrypted.

The master server is just a house for VMs. And, because those VMs are generally free to be rebooted with wild abandon, entering passwords into the VMs controlling the RAID arrays would be a real downer. Fortunately, the master computer to which the RAID is attached is already set up with encrypted hard drives—which means I can store keyfiles for the RAID arrays on it without compromising security.

In fact, thanks to proper layering, the VMs don't even have to know the drives they're accessing are encrypted.

Here's how.

Set up Drive Encryption

First, we'll need a key file. Random data will do nicely.

KEY_FILE=/etc/luks-keys/$VMNAME
head -c /dev/random 1024 > $KEY_FILE
chmod 400 $KEY_FILE

Next, set up encryption on the RAID array.

cryptsetup luksFormat $RAID_DEVICE $KEY_FILE

And then add it to crypttab, so encryption will be automatically set up and torn down at system start/shutdown.¹

UUID=`cryptsetup luksUUID $RAID_DEVICE`
echo $RAID_VOLUME UUID=$UUID $KEY_FILE luks >> /etc/crypttab
cryptdisks_start $RAID_VOLUME

The encryption set up and running, it's just a matter of creating the VM.

Configuring the VM

I like to create a partition on the regular drive for the VM's OS. While not strictly necessary, it gives a bit of flexibility (e.g., the ability to switch between two different VMs controlling the RAID while testing different NAS distributions), and leaves the maximum amount of space on the RAID array for files.

lvcreate -L $SIZE -n $VOLNAME $VOLGROUP

That done, actually make the VM.

virt-install --name $VMNAME \
  --disk /dev/$VOLGROUP/$VOLNAME \
  --disk $RAID_VOLUME \
  …

Or, if adding the encrypted disk to an existing VM:

virsh attach-disk $VMNAME $RAID_VOLUME $VMDEV --persistent

Once inside the VM, you can format the attached volume as normal, none the wiser to the encryption. It just works.

Of course, encryption means if your RAID array loses one too many disks your data is hosed irrecoverably, so be darn sure to have a good backup policy in place before you start storing critical data on it!

For the purpose of those backups, it might be desirable to ensure you can take snapshots of the filesystem. That's doable, too:

VGNAME=$RAID_VOLUME
vgcreate $VGNAME $RAID_DEVICE
lvcreate -L $SIZE -n volume $VGNAME
mkfs -t $FSTYPE /dev/$VGNAME/volume

where $SIZE is some size smaller than the extent of the device. Exactly how much smaller depends on how much data churn you're expecting while the volume is snapshotted, but I'd say leaving ~10% for the snapshot is probably sufficient.²

Then you can attach the logical volume to your VM

virsh attach-disk $VMNAME /dev/$VGNAME/volume $VMDEV --persistent

and use snapshots to back up the VM from outside with the VM none the wiser.

Note that the mkfs turns out to be important: if you don't format the logical volume before mounting it within the VM, the VM will see the LV rather than an unformatted block device and be very confused.

A Note about Fibre Channel

Using the mptfc driver with my fibre channel card, I was unable to get echo '- - -' > /sys/class/scsi_host/$HOST/scan to recognize a change in RAID size, and don't recall having much luck actually specifying the parameters, either.

Rescanning was, however, successful with echo 1 > /sys/class/scsi_device/$DEV/device/rescan

So if scan doesn't help, try rescan. It certainly beats rebooting!

Footnotes

¹ Alternatively, you could add a libvirt hook to set up and tear down the encryption before and after the VM is booted and shutdown. That is left as an exercise to the reader.

² As a point of reference, upgrading Debian from Stable to Testing requires ~7% of a 32GB volume.

Some time ago, we got a TV that supports DLNA. I had no idea what that was, but a quick consultation with Wikipedia left me eager to give it a try.

I've tried a couple of DLNA servers since then, and found all of them wanting in some manner. I've also been using Netflix streaming of late, so I'll add that to the comparison seeing as it fills the same niche.

DLNA

Why?

I gave DLNA a shot because my TV supports it and it seemed like a good idea.

Pros

• Works even when internet is down.
• Doesn't leak information about watched shows.
• Content stays available as long as you want it to.
• No commercials!
• No monthly fees.

Cons

• No fast-forward, rewind, chapter skipping, or single-frame progression.
• Can't handle interactive content (DVDs, etc.).
• Client capabilities differ significantly (e.g., in whether they support switching between multiple audio streams).
• Wildly varying client capabilities necessitates remuxing and/or transcoding, complicating servers.

Verdict

DLNA is a nice idea, poorly implemented atop a terrible protocol. Because none of the DLNA servers I've tried are perfect, I've ended up running two beside each other so I can use the fast one when it works, and the featureful one when the fast one can't do what I need.

PS3 Media Server

Why?

I tried this at the recommendation of the local Linux User Group.

Pros

• Supports pausing, skip forward, and skip backward.
• Ability to force audio to desired language (if available in file, of course).
• Debian package available (third-party).
• Can run headless.

Cons

• Slow to browse. You can speed up browsing a bit by enabling the cache, but that broke audio language forcing for me.
• Slow to play. Files require multiple seconds to start playing, skip forward, back, or unpause.
• Unpausing often restarts slightly before or after the pause time.
• Had to scrounge around forums for a profile that (mostly) works with my TV.
• Documentation assumes you're running the GUI, leaving most of the config file options un- or poorly-documented.

Verdict

PMS is okay. The slowness is infuriating, and configuration involved more than starting it up, but it's been very stable. The ability to prefer some languages over others is an excellent feature.

MediaTomb

Why?

I tried this because it was in Debian.

Pros

• Debian package.

Cons

• XML config file.
• Web interface.
• Can't pause or skip when remuxing or transcoding.

Verdict

MediaTomb is crap. XML-based configuration files are terrible, and web interfaces are a blight upon mankind that should be abolished. But even if you can look past that, the inability to do something as basic as pause makes it completely worthless.

Serviio

Why?

I tried this because it was mentioned somewhere on the interwebs.

Pros

• Browses fast.
• Plays fast.
• Resumes fast.

Cons

• No Debian package.
• Can't switch audio language.
• Must be configured with included GUI client, no config file.

Verdict

Serviio is decent. The fast pausing and unpausing is a welcome relief from pms's multi-second unpause, and the fast browsing makes getting to the file I want to watch much less painful. The lack of a .deb is a bit of a downer, but installation is relatively straighforward (untar and run). While I'd much prefer a proper config file, the only thing preventing me from ditching pms entirely is the inability to prefer a particular audio language.

Edit (16.05.2012): I seem to have spoken too soon on Serviio. Further testing on a wider range of files has shown it to sometimes have infuriatingly-long start-to-play times and that it works with fewer files than pms. Alas, it had such promise!

Netflix Streaming

Why?

I tried this because hey, free trial.

Pros

• Much wider array of content than my local media server.
• Skipping around the video is much nicer than DLNA.
• Selection UI is way better than DLNA.
• Good for discovering things you didn't know about or old things you'd forgotten.
• No commercials!

Cons

• Stops working when the internet goes down mid-video.
• No rewind, fast-forward, or single-frame movement.
• The video progress meter never goes away when paused. (Especially annoying when pausing to try and read something, only for that thing to end up covered.)
• Never more than 720p.
• Leaks watched show information.
• Many things I'd like to watch aren't available (e.g., no Jack Benny).
• Content regularly disappears or threatens to disappear with minimal notice.
• Many series are only partially available. E.g., you can watch ReBoot seasons 1 and 2, but not 3 or 4; and Sesame Street is missing the first forty years or so.

Verdict

Netflix is awesome, when they have something you'll watch. Searching for something specific is an exercise in futility (if you're looking for it, Netflix won't have it), but browsing can often result in something interesting. I very much enjoy when the "Comedies from the 1940s" category pops up, for instance; and the availability of the wealth of long-running series from the Star Trek and Stargate franchises will likely keep me subscribed and entertained for quite some time.

Summary

Netflix and DLNA are both awesome ideas with not-so-awesome implementations, but between the two Netflix is an incredible triumph. DLNA generally works, and is vastly superior to watching things on a computer monitor, but has little else in its favor (I suspect I'd ditch it entirely if I had an HTPC running XBMC). Netflix certainly has areas in need of improvement, but I was surprised at just how quickly and completely it supplanted any other method of watching video content—my biggest annoyance is actually the pause thing, believe it or not, because I pause to read things all the time.