Olddevboxdoc

This is the documentation to the discontinued PlanetLab DevBox. It is provided here for reference only.

	TWiki > Planetlab > DevBox	TWiki webs: Main \| TWiki \| Know \| Sandbox \| Planetlab
	Planetlab . { Changes \| Index \| Search \| Go }

This page describes the procedure to install the PlanetLab linux kernel and a set of RPMs on a conventional Fedora Core 2 systems. Why would anyone want to do this? Maybe to:

develop and test new PlanetLab related software that runs in a slice/vserver,
look under the covers at the PlanetLab system software in action and enhance/modify it, or
play around with the PlanetLab linux kernel itself.

There are three flavors of DevBox available: production, alpha, and beta. These correspond to the latest software that is running on existing PlanetLab production, alpha, and beta nodes. At the moment, the DevBox software is a proper subset of the software that one needs to run on a PlanetLab nodes. In the future, we hope to expand it to the point that a DevBox corresponds fully to the software needed to work with a PlanetLabInABox^?.

The remainder of this document is organized as follows:

Adding PlanetLab software to a Fedora Core 2 system
Changing System Resource Allocations with RESMAN

Adding PlanetLab software to a Fedora Core 2 system

NOTE: This is for Fedora Core 2. We have not tested it with FC3. There have been reports that it does not work without some additional work. Please try on a FC2 system first.

We have created DevBox yum repositories. Currently, the rpm set includes the kernel, vserver related utilities, and support to twiddle resource management knobs.

Getting DevBox with yum

To get updates from the DevBox yum repositories, you will need to make a simple three line addtion to /etc/yum.conf. I'll assume you have a x86 box that has Fedora Core 2 installed with recent rpm package updates and are using the grub bootloader.

For the PRODUCTION DevBox installation, add the following lines to /etc/yum.conf:

[planetlab-devbox]
name=PlanetLab DevBox RPMS -- PlanetLab Central
baseurl=http://boot.planet-lab.org/install-rpms/planetlab-devbox/

and then as root run

# yum groupupdate planetlab-devbox

This downloads the PlanetLab node software that corresponds to the production software currently deployed on PlanetLab nodes.

After the yum groupupdate completes, reboot into the new planetlab kernel. It should be listed as one of your grub choices with the name "planetlab" in it.

For the ALPHA DevBox installation, please use the following yum.conf and yum commands:

[planetlab-alpha-devbox]
name=PlanetLab Alpha DevBox RPMS -- PlanetLab Central
baseurl=http://boot.planet-lab.org/install-rpms/planetlab-alpha-devbox/

# yum groupupdate planetlab-alpha-devbox

For the BETA DevBox installation, please use the following yum.conf and yum commands:

[planetlab-beta-devbox]
name=PlanetLab Beta DevBox RPMS -- PlanetLab Central
baseurl=http://boot.planet-lab.org/install-rpms/planetlab-beta-devbox/

# yum groupupdate planetlab-beta-devbox

NOTE: Once you install an alpha DevBox, you cannot easily downgrade to a beta or production DevBox. Similarly, once you install a beta DevBox, you cannot easily downgrade to a production DevBox. This is something we are still working on. If you know how to solve this using yum, please send us email devel@planet-lab.org.

Post Installation/Reboot operations

After the reboot, the vserver reference is automatically run. A displayed message: "Building vserver reference" should appear. This operation might take several minutes.

For adding slices (users) you can type:

# /usr/sbin/vuseradd v_test

which will create a vserver named v_test.

You can log into this vserver by typing:

#su v_test

Now you are operating inside a vserver in a similar manner as if you just logged into your slice account on a PlanetLab node. Go ahead and do whatever software development or testing you would like to do.

Debugging installation

In case everything went well, you should skip this section.

yum settings

When editing /etc/yum.conf, you are advised to replace the [base] and [updates-relased] section to have mirrors which are geographically close to you. A list of FC2 mirrors is found on: mirrors. I have experianced stuck yum sessions where the mirror did not respond or was too busy. You can check if the mirror is alive:

#yum info gcc

Unable to find pid
Gathering header information file(s) from server(s)
Server: Fedora Core 2 - i386 - Base
Server: PlanetLab Desktop RPMS -- PlanetLab Central
Server: Fedora Core 2 - i386 - Released Updates
Finding updated packages
Downloading needed headers
Looking in Available Packages:

Looking in Installed Packages:
Name   : gcc
Arch   : i386
Version: 3.3.3
Release: 7
Size   : 11.07 MB
Group  : Development/Languages
Repo   : Locally Installed
Summary: The GNU cc and gcc C compilers.
Description:
 The gcc package includes the cc and gcc GNU compilers for compiling C
code.

Checking grub setup

After doing yum groupupdate "planetlab-devbox" (or the equivalent for the alpha and beta versions of DevBox you can look at /boot/grub/grub.conf. A new entry similar to the following should appear: [root@planet8 daniel51]# cat /boot/grub/grub.conf # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/sda2 # initrd /initrd-version.img #boot=/dev/sda default=0 timeout=10 splashimage=(hd0,0)/grub/splash.xpm.gz title Fedora Core (2.6.8-1.521.2.4.planetlab) root (hd0,0) kernel /vmlinuz-2.6.8-1.521.2.4.planetlab ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.8-1.521.2.4.planetlab.img title Fedora Core (2.6.9-1.6_FC2smp) root (hd0,0) kernel /vmlinuz-2.6.9-1.6_FC2smp ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.9-1.6_FC2smp.img title Fedora Core (2.6.9-1.6_FC2) root (hd0,0) kernel /vmlinuz-2.6.9-1.6_FC2 ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.9-1.6_FC2.img You can change the "default" parameter to point to the number of the planetlab version and thus avoid hitting enter when the node reboots.

Verfying new kernel version

After the reboot, you can do "uname -a" in order to check the new kernel version.

[root@planet8 daniel51]# uname -a
Linux planet8 2.6.8-1.521.2.4.planetlab #1 Tue Dec 14 15:20:58 EST 2004 i686 i686 i386 GNU/Linux

The kernel is the third field (you do not have to be root to do this).

Removing a slice

In case you added a user with "vuseradd" and you like to remove it, use "vuserdel".

Errors when building the vservers:

# /sbin/service vserver-reference start

[root@planet8 vservers]# /usr/sbin/vuseradd huji_daniel51
/usr/sbin/vuseradd: line 30: useradd: command not found
/usr/sbin/vuseradd: line 80: vserver: command not found
/usr/sbin/vuseradd: line 81: vserver: command not found
/usr/sbin/vuseradd: line 91: service: command not found

Here the PATH environment variable was not set correctly. The fix was: (assuming root is working using bash)

[root@planet8 vservers]# PATH=$PATH:/sbin:/usr/sbin ; export PATH

Manually installing new kernel (overriding yum)

This is needed only if yum failed to download the right kernel. Find out which kernel version is current, and do the following (as the root user).

[root@planet8 vservers]#wget http://boot.planet-lab.org/install-rpms/planetlab-desktop/kernel-2.6.8-1.521.2.4.planetlab.i686.rpm
[root@planet8 vservers]#rpm -i ./kernel-2.6.8-1.521.2.4.planetlab.i686.rpm

Looking at the logs

The service vservers-reference writes a log file into /var/logs/vserver-reference.log. You can try to examine this file in order find out where the script got stuck.

Danny Bickson
here

Changing System Resource Allocations with RESMAN

A new package, called resman, is used to twiddle the knobs that the PlanetLab kernel exposes for disk space, network bandwidth, cpu, memory, tasks, and io. The scripts provided by resman include: disklimit, bwlimit, cpulimit, memlimit, tasklimit, and iolimit.

Each script exports the following commands: init, setlimit, getlimit, on, off, and default. The common case sequence of commands used to change a particular limit consists of a getlimit, setlimit, and on sequence. The following example with cpulimit illustrates how to increase the cpu allocation by 4 shares for a slice called v_slice:

# /bin/bash # in case you are running a different shell
# cur=$(cpulimit getlimit v_test)
# let cur=$cur+4
# cpulimit setlimit v_test $cur
# cpulimit on v_test

A similar recipe can be used for all the other limit scripts.

Topic DevBox . { Edit | Attach | Ref-By | Printable | Diffs | r1.11 | > | r1.10 | > | r1.9 | More }

Revision r1.11 - 09 Jan 2006 - 21:01 - SteveMuir