From the Canyon Edge -- :-Dustin

Thursday, June 25, 2009

QEMU in Launchpad

QEMU provides the userspace and device emulation required by KVM. As such, it's an extremely important project to Ubuntu's virtualization and cloud computing efforts.

The upstream project has not had an actively maintained bug tracker for quite some time.

I recently helped QEMU's maintainer, Anthony Liguori setup a Launchpad project for tracking QEMU's bugs. This should be a good thing for the upstream QEMU project, as well as for tracking bugs in Ubuntu's kvm and qemu packages.


I have also set up a bzr mirror of qemu's git tree, for people who are more bzr-inclined.

You can now:

bzr branch lp:qemu

Also, you can use Loggerhead to browse QEMU's source tree and revision history at:


KVM's inside of Byobu

Here's a neat trick that I find phenomenally useful...

I like to run KVM virtual machines inside of Byobu, using KVM's -curses option. From QEMU's manpage:

Normally, QEMU uses SDL to display the VGA output. With this option, QEMU can display the VGA output when in text mode using a curses/ncurses interface. Nothing is displayed in graphical mode.

So this only works with non-graphical virtual machines, such as the Ubuntu Server. But hey, that's what I'm working on every day. Here's a quick demo screen cast.

Commands used in this video:

  1. start byobu

  2. run kvm -curses karmic-server.img to launch one virtual machine

  3. hit F8 to rename this window karmic

  4. hit F2 to open a new window

  5. start a second virtual machine, and rename that window

  6. hit F3 or F4 to move back and forth between windows

  7. hit F6 to detach

  8. and byobu -x to re-attach

The detach/reattach is really cool, as these virtual machines will continue running in the background. Many people use this sort of method to background an irc client such as irssi, which allows it to serve as a persistently connected proxy.

Of course, virsh and virt-manager are the preferred methods to manage virtual machines in Ubuntu, but I find this useful for my development purposes.


Wednesday, June 24, 2009

KVM-84 Backport Release Candidate


On March 17, 2009, I blogged the following call for testing:

We have worked through a number of the issues raised after that blog post, and cherry-picked several patches that fix some known bugs. We believe that Ubuntu 9.04's kvm-84 is a far more complete hypervisor.

This is a call for one more round of testing of a release-candidate build of that package (kvm - 1:84+dfsg-0ubuntu12.1~rc*) in the ubuntu-virt ppa:

If you are able to assist us with the testing, please add that PPA, and install both the userspace and dkms built kernel module onto your 8.04 and/or 8.10 servers.
$ sudo apt-get install kvm

Please file any bugs against kvm in Launchpad, and please tag them with "kvm-84".

The goal is to upload a version of kvm-84 to the hardy-backports and intrepid-backports repositories around July 6, 2009.


Sunday, June 21, 2009

Prime Numbers for the Win!

The Sieve of Eratosthenes

I minored in Mathematics in college. But as much as I have always loved math, I use it surprisingly little during my day-to-day computer programming. Perhaps this is why I'm excited about the latest Byobu releases.

Byobu-2.12 and 2.13 have introduced some tremendous performance enhancements, mostly surrounding the status gathering scripts.

I have gone over each of these with a fine-toothed comb, trying to make them as efficient as possible. I wrote a testing framework that ran these scripts millions of times to identify the most expensive operations. The improvements mostly involved reducing the number of shells and forks necessary to gather and print the information, and using files resident in memory, such as /var/run and /proc. In the long run, these scripts would probably perform better as compiled C programs. But I'm not yet willing to give up the simplicity and portability of the current shell scripts.

Aside from the scripts' contents, I also modified the intervals in which they run.

In Ubuntu 9.04, screen-profiles-1.44 ran the status scripts at the following intervals:
2         cpu-freq
2         load-average
2         mem-used
2         network-down
2         network-up
2         processes
2         reboot-required
2         wifi-quality
10        updates-available
10        users
30        battery
60        uptime
600       ec2-cost
3600      hostname
3600      release
86400     arch
86400     cpu-count
86400     logo
86400     mem-available
86400     menu
86400     whoami

This means that:

  • Every 2 seconds, Byobu will run each of (cpu-freq, load-average, mem-used, network-down, network-up, processes, reboot-required, wifi-quality).

  • Every 10 seconds, Byobu will run (updates-available, users), plus all of the 2-second scripts.

  • Every 30 seconds, Byobu runs (battery), plus the 10-second scripts, plus the 2-second scripts.

  • Every 60 seconds, Byobu runs (uptime), plus the 30-second, 10-second, and 2-second scripts.
  • etc.

These particular intervals result in some unfortunate harmonics, which are not a good thing in terms of Byobu's responsiveness. The battery script, for instance, only runs twice a minute because it's relatively expensive. However, at that 30-second interval, the battery script must also share time with the 10- and 2-second scripts. As you can see, we're going to have a couple of standing waves, that periodically cause some rather expensive refreshes of Byobu's status bar.

This was reported as several bugs, noting that Byobu causes screen to "stutter" every 2 seconds or so, with an even longer "delay" at 10 seconds. In older versions of Byobu, if you toggle all status notifications "on", and then scroll through a rather long file, you'll see it pause or stutter every few seconds. Try, `find /lib | less`, and hold the down-arrow key.

How do we solve this problem? Prime numbers!

If we set the Byobu status updates to happen at prime intervals, rather than (2, 10, 30, 60, ...), we can greatly reduce the expensive, compounded updates. We can spread the updates out more evenly over time, without stacking them up as much and creating particularly expensive intervals.

Based on the automated testing and statistical analysis of each script, Byobu is now configured to run the status scripts at the following prime numbered intervals:
2         cpu_freq
2         load_average
3         network
5         mail
5         reboot_required
7         processes
11        users
13        disk
13        mem_used
17        wifi_quality
19        temp_c
19        temp_f
29        uptime
61        battery
181       updates_available
599       release
601       ec2_cost
607       hostname
613       ip_address
86011     logo
86017     cpu_count
86027     mem_available
86029     whoami
86077     arch

Now, at any given time interval, we'll only run the status updates corresponding to the prime factors of that interval. So instead of a relatively expensive set of updates running at the 60-second mark, we only run 5 scripts (cpu_freq, load_average, network, mail, reboot_required), rather than 12 scripts in the old model!

The following chart shows time (in seconds) on the x-axis, and the number of scripts that need to run on the y-axis. In red, you have data from screen-profiles-1.44 (in Ubuntu 9.04), and in blue, you have current byobu-2.13 (in Karmic). We have reduced the average number of scripts that need to run per second. More importantly, we have tremendously reduced the harmonic spikes where previously we peaked running a dozen or more scripts at any one time.

In the latest Byobu release (2.13), responsiveness should be much better. The network status item is still the most expensive notification, but even it has improved. With the network item turned off, though, there should be no noticeable stutter in your Byobu sessions.

Prime numbers for the win!


Friday, June 5, 2009

The Goode Family

Mike Judge
's new cartoon sitcom, the Goode Family, has made a few headlines on Planet Ubuntu already. I'm throwing my endorsement in the ring.

It's pretty funny so far. Of course, it's great to hear "Ubuntu" on prime time television. The Goode's have an adopted son named Ubuntu from Africa -- South Africa. They're really having a blast with the pronounciation. Different characters pronounce his name in different ways -- something we certainly see in the Ubuntu Community as well. Quite entertaining.

I find it strangely ironic how my life has tracked Mike Judge's shows...
  • I was in junior high and high school in 1993-1997, listening to plenty of Metallica and Guns N Roses when Beavis and Butthead was on MTV (1993-1997).
  • I moved to Texas in 1997, still living there now. King of the Hill (1997-present) is quite thoroughly set in Texas, and makes fun of plenty of idiosyncrasies that have baffled me as a non-native Texan.
  • I started my first real internship with IBM Tivoli, in Austin, Texas in the corporate computer/tech industry in 2000... Office Space was filmed in Austin and released in 1999.
  • And here I am now, 2009, living in Austin. I find myself working on Ubuntu, with my wife driving a bio-diesel VW Jetta, buying over-priced organic groceries, stuffing them into reusable grocery bags, trying vegetarianism (unsuccessfully), and installing solar panels on the roof. The Goode Family could really be any one of a number of real households in Austin, quite a green-minded, hippie community ;-)
On a separate note, I've always wondered if Greg Kroah-Hartman and Mike Judge might be related... The resemblance is amazing!


Wednesday, June 3, 2009

Migrating to an Encrypted Home Directory

UPDATE (2011-02-15): These manual instructions are no longer required, however, they may prove useful if you need to deviate from the norm.  You can now use the ecryptfs-migrate-home command.


Many eCryptfs and Ubuntu Jaunty users have requested instructions on migrating their existing, non-encrypted home directories to an Encrypted-Home setup. I have some instructions for you now!


  1. Make a complete backup copy of your non-encrypted data to another system or external media. Some of the following instructions are dangerous, could result in data lost, or lock you out of your system! Please read and follow all instructions very carefully.
  2. Make sure you have sufficient disk space available. To make a full copy, you will need at least 2x the disk usage of your current home directory. Assuming the copy succeeds and you have access to your encrypted data, you can recover some space by deleting the unencrypted data.
    du -sh $HOME
    df -h $HOME
  3. You must have administrator (sudo) privileges.
  4. You should install ecryptfs-utils
    sudo apt-get install ecryptfs-utils

  5. These instructions require an empty $HOME/Private directory. If you already have some data in your $HOME/Private directory, please move all of these files and directories out of the way, and follow the instructions in:
    ecryptfs-setup-private --undo


Exit all desktop sessions. You need to ensure that there are no other processes on your system reading and/or writing data in your home directory. Perform all of the following instructions by logging in via SSH or at a tty terminal (ctrl-alt-F1).

Login and setup an Encrypted Private directory:

Logout, and log back in and make sure $HOME/Private is mounted.
mount | grep "$USER.*ecryptfs"

Use rsync to copy all data from your home directory to your new Encrypted Private directory. If you have a large home directory, this step might take a very long time. Be very wary of any errors at this point. This is the most essential step in this migration scheme. I usually re-run this step 3 times.
rsync -aP --exclude=.Private --exclude=Private \
--exclude=.ecryptfs $HOME/ $HOME/Private/

Sync to disk, unmount, logout, and log back in.
sync && sync && sync

Setup your eCryptfs configuration directory.
cd /
sudo mkdir -p /home/.ecryptfs/$USER
sudo chown $USER:$USER /home/.ecryptfs/$USER
mv $HOME/.ecryptfs /home/.ecryptfs/$USER/
mv $HOME/.Private /home/.ecryptfs/$USER/
sudo chmod 700 /home/.ecryptfs/$USER/.Private
sudo chmod 700 /home/.ecryptfs/$USER/.ecryptfs

Setup your new, unmounted home directory.
sudo mkdir -p -m 700 /home/$
sudo chown $USER:$USER /home/$
ln -sf /home/.ecryptfs/$USER/.ecryptfs \
ln -sf /home/.ecryptfs/$USER/.Private \

Move your old, unencrypted home directory out of the way.
sudo mv $HOME $HOME.old

"Activate" your new, unmounted home directory by renaming it.
sudo mv /home/$ $HOME
echo $HOME > $HOME/.ecryptfs/Private.mnt
ln -sf \
/usr/share/ecryptfs-utils/ecryptfs-mount-private.txt \
sudo chmod 500 $HOME

Logout, and log back in. Ensure that $HOME is mounted, and that you have a symlink to your configuration directory.
mount | grep "$USER.*ecryptfs"
ln -sf /home/.ecryptfs/$USER/.ecryptfs \
ln -sf /home/.ecryptfs/$USER/.Private \

Check all of your home directory data. Ensure that everything is in order. Once you are completely confident that the migration worked, you can reclaim some disk space by removing your old, non-encrypted data.
sudo rm -rf $HOME.old


If you are a shred-minded-individual, you will need to backup your cleartext data, shred your disk, and reinstall from scratch.


Karmic Manpages

The Ubuntu Manpage Repository has been updated with Karmic manpages, and Gutsy's have been dropped.

Cruise on over to for web based manpage browsing and searching.


Monday, June 1, 2009

byobu-2.8 - change in launch behavior

Howdy byobu users!

Per discussion at last week's Ubuntu Developer Summit in Barcelona, the latest version of byobu (2.8) has dropped the "diversion" of /usr/bin/screen.

In previous versions of byobu (and screen-profiles), /usr/bin/screen was actually a wrapper script that prompted you to choose your profile, and then launched the real /usr/bin/screen.real with byobu's configuration.

This has proven to be controversial with some traditional GNU screen users. Also, while most of screen's parameters can be passed directly through byobu, some of them cannot.

Thus, from byobu-2.8 onward (and in Ubuntu Karmic Koala), users will need to launch using the byobu command, rather than the screen command.

Note that if you really want to run byobu when you type screen, you can add the following to your $HOME/.screenrc file:
  • source $HOME/.byobu/profile
Also note that if you have configured your system to launch byobu automatically on login, it should continue launching byobu as expected.

Sorry about any inconveniences...