CPS 196
Systems and Networks
home calendar topics labs resources

Basic workcycle for the labs

For much of this course, we will be running experiments using Xen. This guide is written to help you understand the mechanics of logging in, creating a virtual machine and to let you know how your workspaces are set up.

Logging in

You will be running most of your experiments on the Devil Cluster in the Computer Science department. You will each be assigned a Xen machine (named vmmXX.cod.cs.duke.edu) to log into. These machines are hidden away from the outside world, and you can only log into them from another machine in the cluster. For example, let's say you ssh into linux.cs.duke.edu:

ssh -l <username> login.cs.duke.edu

Now, log into your assigned vmm.

ssh vmmXX.cod

You're now good to go!

What's really going on here?

Why are we fooling around logging into multiple places? Here's why; The vmmXX machines are actually the names of the Domain-0 of the physical machines they're running on. Remember, on a machine running Xen, Domain-0 is the closest you can get to the bare machine. Since you're going to be running experiments and run kernels that could fail spectacularly, we are not exposing these computers to the public Internet. In other words, these machines don't have a "route" to the world, just to other machines on the same LAN. You can create your own personal virtual machine on top of these, and it will be shielded from the outside internet as well, without you having to do anything special.

Booting your virtual machine

In your home directory, you will find a file called {name}.xen. This is here to help you get started with your virtual machines. This is a plain text file that contains some information needed by Xen to create your virtual machine. To create a virtual machine with this script, just type in

sudo xm create <filename> -c

You should see bootup messages scroll by. These are from your new virtual machine. Finally, log into the prompt that appears and look around your new virtual machine. Unfortunately, these new virtual machines do not have X-Windows set up, so you will be restricted to playing around with the console.

xm is the command that allows you to interact with virtual machines running on the physical host. The create command is telling xm to create a new virtual machine, using the information contained in the specified file. The -c flag is to automatically connect you to the newly created machine's console. Try experimenting with leaving it out, to see what happens.

Here are other xm commands that might come in handy.

sudo xm list
This command shows you all running virtual machines.

sudo xm console <consolename>
This will attach you to the named virtual machine. Useful if you do not automatically attach at creation time. Get the name of the VM from xm list. Drop back into Domain-0 by typing CTRL+]

sudo xm shutdown <consolename>
Tells the named virtual machine to shut down gracefully. Use this whenever you are done with your virtual machine. The virtual machine will take a few seconds to shut down completely, during which time it will still remain visible in the list of running virtual machines.

sudo xm destroy <consolename>
Destroys the virtual machine without giving it a chance to shut down. Use only when nothing else works.

Read the man page for xm for more details.

Using your repository

We strongly encourage you to do all your development using some form of version control. We really like Subversion, and to make your life easier, we have created Subversion repositories for you. You will find them at https://nicl.cod.cs.duke.edu/svn/{username}. Passwords to access these repositories will be given to you at some point. If you've used CVS before, you will find yourself coming quickly up to speed on Subversion. An excellent book on Subversion is available online.

Subversion work cycle

In order to modify anything in your repository, you must first check out an initial copy. To do this, type

svn checkout https://nicl.cod.cs.duke.edu/svn/{username}
You will now have a new subdirectory under the current directory named with your username. This is now your working set. Be patient, the kernel tree is over 200 MB in size.

Go ahead and start editing your code. If you add any new files to your working set, you should let subversion know;

svn add {filename}

Other useful commands are

svn delete
svn move
svn copy

Once you are done with your edits, you need to commit them. Committing involves letting the repository know about all the changes you've made so far. To commit, type

svn commit

Subversion should pop open either vi or emacs (depending on your $EDITOR variable) and allow you to type in a log message. Subversion itself doesn't care about this message. This is only to help you keep track of what changes you've made. Be as brief or as loquacious as you please, as long as it helps you remember what you've done. Once successfully committed, subversion will tell you what the current revision number is.

You can edit your code anywhere, as long as you've checked it out first. Suppose you've checked out your code both into your project space, as well as on your laptop. Suppose further, that you've made changes and committed them from your project space. Now your laptop will have an out of date copy of your repository. Fix that by running

svn update

on your laptop's working set.

There is one further use of svn update that you might find useful. You can go back to any previous committed version of your repository if you've made a mistake and wish to undo one or more commits.

svn update --revision XX

XX is the number of the revision you want to go back to. Please remember to do a svn commit to save your work back to the repository.

The svn status command will show you the current state of your working set. Please read the manual or the subversion book to learn more about what the status command outputs. Subversion can be used from many places, not just the Unix shell. For example, there is a Windows shell plugin called tortoise svn as well as an eclipse plugin. There are many more things you can do with subversion to make your life easier. Read the subversion book for more details. Focus on chapters 2, 3 and 4.

Compiling Linux kernels

Editing

There are absolutely no restrictions on where you can edit source files. Just make sure that your editor doesn't insert spurious newlines in the middle of code. I've heard complaints about this from the windows version of emacs a while ago, I don't know if the problem persists.

Compiling

You can compile your linux kernels anywhere gcc is available. However, please refrain from building kernels in your home directory, since that volume doesn't have a great deal of free space. If you want to build kernels on the research machines, you can use /usr/research/playground/cps196/{username}. This directory is what we refer to as your "project space" or your "playground". It is accessible from any of the department or research machines.

Testing

Unfortunately, you can't test your newly built kernel anywhere you please. If you recall, Xen requires the "guest" OS (which is what you're building) to be slightly modified. This means that it will not boot on your laptop, for example.

In order for you to test your virtual machines, you'll need to boot them in a virtual machine. The {name}.xen file contains a line like this:

kernel = "/usr/research/playground/cps196/linux-2.6.12-xenU/vmlinux"

It currently points to a known good version of the vanilla kernel, just so you can test it. You'll need to change this to reflect where your own kernel is. When you do a make on the kernel sources, it will build two important files in the top-level directory - vmlinux and vmlinuz. These are your compiled kernels. vmlinuz is simply a compressed version of vmlinux. You can point your script to either one. Running xm create now will boot your new kernel.

Tips