So, secretly, in spite of not saying anything about it on here, I’ve spent the last two months or so jobhunting. The whole process was definitely exciting and fun experience, but also really exhausting and stressful, so I’m glad it’s over. All in all, I applied to 9 companies, interviewed on-site at 7, and received offers from 6. So, a pretty good take, I suppose, and definitely very self-validating.

I want to try and pull some comments together on the process at some point, but for now I’ll just talk about the job itself.

On Wednesday, I accepted a position with MokaFive, in Redwood City, CA. I’ll be working in the Office of the CTO, under John Whaley. We haven’t finalized my start date yet, but it’ll likely be late July or early August.

MokaFive, of course, isn’t a Facebook or a Google, and not many people have necessarily heard of them. So, in a buzzword-loaded sentence, MokaFive is selling distributed, centrally-managed desktop virtualization. Phew! Let’s try to do that with a few more words.

Let’s say you work in IT at a company. And, like most companies, you have some software you want your employees to be able to use. But for whatever reason, people want to use their own computers instead of yours – maybe you’re just not providing them with a computer because they’re a short-term contractor, maybe it’s personal preference. But managing software on a heterogeneous environment like people’s personal computers is basically impossible.

MokaFive’s platform lets you wrap up that software in a VM, which your employees can then download and run on any platform – Windows, Mac, or Linux. You keep the ability to centrally manage those VMs, but your employees can still use them where they want, when they want, and without needing internet connectivity.

The point, though, is that I’m really excited about MokaFive, because the company is basically tailor-made for my background, and lets me keep doing the sorts of virtualization stuff that I’ve been doing.

For today’s post, I thought I’d survey what software projects related to virtualization name themselves.

It turns out that most projects have cute, but relatively unoriginal, names, formed by finding a word with “vert” and changing it to “virt”.

To collect today’s list, I started with sed -ne 's/vert/virt/p' /usr/share/dict/words. That gives me 433 words.

To pare down the list a bit, I used Google’s web search API to ignore words that had no Google results. That got the list down to 125 words.

Finally, I filtered the list down to things that I actually thought were reasonable project names (for instance, “advirt” might be a reasonable project; “incontrovirtible” and “ovirtalkative”, not so much). This admittedly subjective sampling got me down to 27 words that seemed worth exploring further.

And so, without further ado, here is a sample of names for today’s vertvirtualization projects:

  • ConVirt: ConVirt has seen a lot of evolution. It was originally a Linux desktop graphical Xen management application, a la virt-manager, and was originally called XenMan (you can still see some evidence of this at their old website. Since then, it’s been renamed to ConVirt, enhanced to support KVM (using libvirt), and moved into a rich web application. It’s still available under the GPL, but Convirture, the company supporting ConVirt development, is selling some advanced features along with their paid support.
  • Divirt: Divirt is a project to create virtual networks, allowing geographically disparate virtual machines to act as if they’re all connected by a LAN. Doesn’t really look like it ever got off the ground, though.
  • ExtraVirt: ExtraVirt was a project from UMich to detect processor errors by running the same system synchronously in multiple VMs, regulating non-deterministic inputs, and comparing the output. All I can find is a single two-page brief on the project.
  • IntroVirt: Another project from the same group at UMich, IntroVirt was a system for both active intrusion detection and post-facto intrusion analysis. It used a bunch of tests from the host to monitor suspicious activity.
  • Invirt: The super awesome project from the MIT SIPB. Invirt is a full-stack, multi-host, Xen-based management platform targeted at semi-public deployments with a web-based control interface. It has per-machine access control and quotas, and supports creation, deletion, installation, and general administration through the web interface, including an autoinstaller for Debian and Ubuntu. The primary deployment of Invirt, the XVM service, provides free VMs for the MIT community. XVM is currently running 246 separate VMs on 4 physical servers.
  • oVirt: Similar to ConVirt (at least in its current form), oVirt is a RedHat-sponsored web-based virtualization management platform. In contrast to something like Invirt that’s designed for building a “public cloud”, oVirt is designed for building more of a “private cloud”, where all of the VMs are managed by the same person. oVirt was one of the first projects to heavily utilize libvirt, and both projects come from the same group in RedHat.
  • ReVirt: From the group that brought you ExtraVirt and IntroVirt, ReVirt is a trustworthy execution logger. It logs a VM’s execution for later replay. Like IntroVirt, it seems to be primarily designed for intrusion detection and analysis.
  • SubVirt: Yet another paper from UMich, this paper was somewhat groundbreaking research into malicious virtualization technology. The SubVirt project developed proof-of-concept “VMBRs” (virtual-machine based rootkits), which installed themselves as a hypervisor on machines, transparently turning the OS previously running on bare metal into a virtual machine.
  • TransVirtual Systems: These guys sell a compatibility layer that lets you run ancient software from Wang VS on a modern UNIX platform.
  • Xilinx Virtex: While not virtualizing the same layer as the other projects and products here, FPGA’s are basically virtualization for silicon, letting you literally create new digital logic on the fly, and Xilinx’s Virtex series of FPGAs is the top-of-the-line.
  • Virtigo: I’m sort of cheating here, because Google won’t help you find this one. When I left my internship at Google, I decided to pull the virtualization testing framework I was working on out from the larger body of work it was originally included in, and Virtigo is what I decided to call it. If I ever have the time to pull the project back together, it’ll live at virtigo.org.

In addition to those names, though, there are actually some names that haven’t yet been taken:

  • advirt
  • ambivirt
  • antevirt
  • chetvirt
  • controvirt
  • covirt
  • culvirt
  • discovirt
  • evirt
  • obvirt
  • pervirt
  • povirty
  • retrovirt
  • virtebra
  • virtical

So – what are you going to name your next virtualization-related project or product?

Magic SysRqs

One of the most powerful ways to debug or recover Linux is through the Magic SysRq keys.

Normally, if you’re using a serial console, you send BREAK, followed by the command you want. However, this doesn’t work with the Xen paravirtualized serial console driver. Instead, you have to use Ctrl+o, followed by the command you want.

For instance, to do an emergency sync, press Ctrl+o, then s.

Note that you use Ctrl+o instead of BREAK for both dom0 and domU serial consoles – they both are using the Xen paravirtualized driver.

I live in a really awesome apartment. I’m living with really awesome people. And we tend to err on the side of awesome when it comes to buying stuff for the apartment. Specifically, we’re big fans of communalism – we do communal groceries, communal furniture, whatever.

But all four of us are paying for stuff for all four of us, it does make keeping track of money a little tricky. The traditional solution is for everybody to stuff their receipts into a drawer, and every month you all sit down and slowly work your way through the receipts.

Each of us owes you $50 for your grocery run, and you owe me $20 for my grocery run.

It’s a painful process, and the difficulty scales super-linearly as you add more people. Even with four, it would be pretty bad.

Now, it turns out that programmers hate tedious tasks like that, so there’s a long history amongst my friends of programmatically solving this in various ways. When we moved into this apartment, I figured I’d try my hand at it, and BlueChips is the result.

Since we set it up, BlueChips has been used by us and by other roommate setups to manage their expenses. We use it for tracking everything – rent, utilities, groceries, furniture, when all of us go out for dinner…

BlueChips has a very simple data model. There are users. A user can move money in two ways: expenditures and transfers. In an expenditure, one person spends money on behalf of a bunch of people. As a result of the expenditure, each of those people owes the spender some amount of money. BlueChips lets different people owe different amounts as the result of a single expenditure. For example, when we pay rent, each of us pays a different percentage, and BlueChips can follow that.

BlueChips’ biggest feature, though, is its ability to calculate the transfers necessary to settle the books. When it makes this calculation it also does something we call “pushing transfers”. Let’s say Larry owes Moe $1, and Moe owes Curly $1. BlueChips can “push” the $1 through, and will tell you that, to settle the books, Larry should give Curly $1.

If you’re still confused, or just want to see what the app looks like, I have a demo instance running at http://demo.bluechi.ps.

The software’s been around for a year, and it’s been open-source for most of that time, but I’ve never quite gotten around to putting a finishing coat of polish on it and getting it into a form that other people can use it.

When I lived with Scott Torborg and some other friends over the summer, we used BlueChips again for handling finances. Scott decided to put some of that polishing effort into BlueChips, and I have him to thank for all of the styling, excellent test coverage, and the iPhone interface, along with innumerable other tweaks.

I finally coded up the last big feature that BlueChips was missing: the ability to add new users without directly interacting with the database.

And so today I’m pleased to announce that I’ve tagged and released a version 1.0.0 of BlueChips.

BUT WAIT! THERE’S MORE!

For those of you MIT folks, I’ve worked with the scripts.mit.edu team to provide a Scripts autoinstaller. To install BlueChips, you can run the following commands from any Athena workstation:

dr-wily:~ broder$ add blue-sun
dr-wily:~ broder$ scripts-bluechips

Please remember that this is not a Scripts-managed autoinstaller. If you run into any problems, like it says, please let me know at bluechips@mit.edu.

And if you find BlueChips to be missing a feature you want, please feel free to write it yourself! In general, I don’t expect to have a lot of time going forward for new feature development, but I’m more than willing to review contributions from others. It’s my hope that the community can pick up my slack and keep BlueChips moving forward.

As part of my involvement with SIPB, one of the biggest problems we run into is getting people started. As much as we emphatically insist that you don’t need to know anything about computers coming in (just be interested in them), it’s hard to implement that in practice.

One area that I think we do a particularly bad job of spinning people up on is how to use Unix-like environments. We’re a very Linux-heavy organization, and without some amount of *nix (and, in particular, *nix command line) comfort, it’s hard to figure out where to start.

When I’ve tried to teach people this sort of thing in the past, one thing I’ve always found is that you can’t use a system you don’t understand. You might be able to apply formulas to it (i.e. you might know “ls” or “blanche“), but without understanding the system, you can’t do things like building awesome complicated pipelines of 12 different commands, or whatever. So in the last 6 months or so, whenever I’m trying to teach somebody something, I take the time to teach it to them from the ground up. But I still didn’t have a good answer for teaching Unix.

I realized last night that I really learned how to think about Unix in 6.033, when we read the Unix Paper. In particular, sections 3, 5, and 6 are a pretty concise explanation of open, read, write, pipe, fork, exec, wait, exit, not to mention how input/output redirection, file descriptors, and shell fork+exec loops work.

And, modulo some slight naming changes, all of the information still applies to modern Linux. Not bad for a paper that’s 36 years old!

In any case, I’ve decided that pointing people at those three sections of that paper is my new answer for how to go from a formulaic understanding of Unix to actually being able to work with it. But it’s still only a start.

When did Unix click for you, and what actually did it? How do you help it click for other people? What other good beginner material is there, not just for Unix but other technical topics as well?

This is a blatant abuse of any Google juice this blog has picked up.

Every time I look for the definition of Vcs-Browser, Vcs-bzr, Vcs-cvs, Vcs-git, Vcs-hg, Vcs-hg, and Vcs-svn, it takes me forever to track it down.

In particular, searching for debian vcs-svn doesn’t actually find what I’m looking for. It took me running through a series of blog posts linking to forum posts linking to online list archives linking to Debian bugs to finally get the hint.

Now, for everybody’s sake, the information is not in Debian Policy, but rather in the Debian Developer’s Reference. Specifically, section 6.2.5.

Hopefully Google will pick this up and make searching for those fields easier. But even if it doesn’t, at least I know that I have a blog post with the information.

© 2011 No Name Blog Suffusion theme by Sayontan Sinha