April 2008 Archives

CoWNFS seems to have vanished from mortal sight.  I'll miss it; it was almost unique among Xen-related technologies in that it actually worked with minimal effort, and had a clear, logical set of steps, with easy-to-follow documentation.  The fact that it hadn't been updated in three years didn't seem especially relevant.  I guess I'll post the howto we wrote here, for historical reference.

An archive of the page is at the Wayback Machine: http://web.archive.org/web/20070811053113/http://www.russross.com/CoWNFS.html

Maybe we should just email the guy, ask him why he stopped working on CoWNFS, and what he recommends instead.  Or if he wants some free hosting.

I am a poor bookkeeper. I will try to keep this status page updated.

• 0-introduction,1-overview, 04-storage, 05-networking, 13-windows - finalized.
• nothing- in our 'post-copyedit' review queue, for chris and luke to look at.
• 2,11,12 - in the copyedit queue for no-starch
• 3,6,7,8- back from tech review for pre-copyedit review by Chris and Luke
• 9 - in tech review queue for Rami
• 15 - almost done (almost ready for TR)
• 10,14 - still have some work to do.

Worked on the troubleshooting chapter for a while today.  (Having been interrupted by the need to set up domainkeys on a mail server -- useful experience, that.)

I don't have much to say about it, other than that it is. . .  very long.  There's a lot of troubleshooting to do.  I'm trying to subtly pepper it with sentences that are encouraging, but suspicious -- an astute reader will note that we felt a _lot_ of encouragement was called for.  We're also documenting error messages that we ran across in the making of the book.  It's. . .  quite a long list.

Have I mentioned that Xen's barely emerging from the hackerware stage?  I don't know, I'm actually really encouraged, though.  With RH's paravirt-ops implementation making progress, we might see Xen mainlined yet.

The thing that's bothering me today is the "custom template" section of the XenSource chapter. We wrote about a page and a half on creating templates -- but that only applies to the previous version of the product.  With current versions, templates have to be blessed to be used by the management frontends, and I haven't figured out the details of that process.  (I know it's possible, because there's a guy selling custom templates. . . makes me want to figure it out just to spite him.  I think maybe I should call my ideological position on things like this "subsistence capitalism.")

I think what I'm going to do is just cut it and add a note asking our tech. reviewer what he thinks about such a section.  It's probably impolitic to say so, but we really are focused pretty aggressively on the open-source version, and I really want to get another chapter or two out the door.

Today I worked on updating the XenSource chapter.  It hasn't really changed since the last time I wrote about it, but I figured that it would be best to work through the examples again and make sure they actually, you know, worked.

A lot of working on a tech book is doing these boring, redundant things. . .  and then doing them again with slight variations to see what the important parts were.  It's enough to drive you crazy after a while.

Ah well.    Now that I've had some time away from this chapter, I can also see that these sections should be in a slightly different order.  In the middle of talking about the GUI, I suddenly veer off and talk about the xe command-line interface for a while.  Got to fix that.

I think I'm writing really poorly today.  It happens, sometimes.  One of the great things that I've learned from the book is that, most days, you can write anyway, and then you'll be in a better position when you have to edit tomorrow.  Today, though, my head hurts and the fan noise is getting to me.

It's okay.  I'll be done with this tomorrow.

Okay, I've been whining too much lately.  Here's a bit that I'm having to cut out of the chapter where we talk about the XenSource product.  (We wrote it right before version 4.0 came out and changed everything.  I preserve it here on the off chance someone will find it useful.)

So, here's a pure erratum for you:

Installing the XenSource GUI

The XenSource GUI officially works on Windows and Linux. Unofficially, it's a Java program, and will run at very least on MacOS X, and probably on any other system with a sufficiently bleeding-edge version of Java installed.

The Windows install is easy. Insert the CD-ROM, let the install process run, answer its questions.

The Linux install is just as easy -- there are RPMs in the client-install directory on the Linux Support CD. Install them using your favorite method, e.g.:

# rpm -ivh xenserver-client-jre-3.2.0-2004-i386.rpm

# rpm -ivh xenserver-client-jars-3.2.0-2004.noarch.rpm

# rpm -ivh xenserver-client-3.2.0-2004.noarch.rpm

Installing the console on MacOS X is a little more difficult, and unsupported besides. If you'd like to try anyway, here are some directions for installing the 3.2 version:

First, you'll need Java version 6. Download it from Apple's Developer website. The filename we had was javase6release1dp6.dmg . Install it.

Now go to a handy Linux machine. Take the xenserver-client rpms (the two with "noarch" in their name,) and convert them to .tar.gz files using rpm2targz . Move both .tar.gz files to the mac and extract them into the root directory.

This creates an /opt/xensource/xenserver-client directory. Edit the bin/xenserver-client.sh script in that directory and change

${BASEDIR}/jre/bin/java \

to point to OS X's java location:

/System/Library/Frameworks/JavaVM.framework/Version \

Also, at the top of the list of command-line options, add:

-XX:+UseTLAB \

Finally, remove the -Xincgc bit from that script. (The incremental garbage collector appears to be broken.) Run the script, and it should pop up the same interface as on the Windows and Linux versions, Java widgets and all.

The thing that I like about Slackware is that it lets me hold on to the belief that computers are deterministic.

Take my recent struggle.  I've been working on building a RedHat kernel in the official manner.  Sometimes rpmbuild creates its directories -- sometimes it doesn't.  Sometimes it adds a / to relative paths, turning them absolute -- and sometimes it doesn't.

BUT IT NEVER WORKS.  Maybe that's the real constant.

See, this way lies madness.  This, in a nutshell, is why people don't trust computers.  You can say that they're complex but deterministic, but trying to figure out the system's like trying to reconstruct a book after someone's burned it and stirred the ashes.

*sigh*  I exaggerate, of course.  I fully expect to get this working.