Fri Oct 20 4:46am MDT
Vers: 4.608 Build: 10/11/2017
a3ab3e957156caff11d7d82a

News

News

(Changelog/Technical Details)
RSS Feed

Node shortages for the next week.
Friday, September 22, 2017, 5:26PM; posted by mike (27).

Node usage, particularly on the d710s, will be high for the next week due to a conference deadline.

The new Emulab reservation system, and its incomplete integration with the old Emulab UI, may be leading you to believe that there are nodes free when there really aren't. If you see a message like:

  *** Resource reservation violation: 1 nodes of type d710 requested, but
  only 0 available because of existing resource reservations to other
  projects.
you should believe it.

To get a more accurate accounting of available nodes, you should go through the new "portal" interface and look at the new Cluster status page and look at "Emulab Totals".

For information about the reservation system, see the Resource Reservations section of the new manual. Use the Reserve Nodes menu item to make a reservation.

For information about switching to the new portal interface to Emulab, see the Transitioning section of the manual.


New Emulab Portal UI (Beta)
Tuesday, May 23, 2017, 4:26PM; posted by stoller (282).

The Utah Emulab team is pleased to announce a new web "portal" UI for the Emulab testbed, now available for BETA TESTING and feedback at:

https://www.emulab.net/portal

Please help us test this new interface to Emulab! Send questions and comments about the new interface to emulab-users@googlegroups.com, or to testbed-ops@flux.utah.edu for private questions/comments.

The new Emulab portal is based on the interface already in use for the CloudLab, Apt, and PhantomNet testbeds. If you have used any of those, the new portal interface to Emulab should be very familiar.

We intend that the new portal will become the default interface to Emulab in the "near" future. Your help with beta testing will help to make the new portal interface better!

PROFILES

In comparison to the current "classic" Emulab UI, the new portal has a streamlined, modern web GUI. More significantly, the new portal is organized around *profiles*, which are similar to, but different than, classic Emulab experiments. Profiles:

  • are written in a domain-specific language atop Python (no more NS/Tcl!)
  • can be created and edited with a web-based GUI
  • are versioned
  • can have parameters, settable at swap-in time
  • can have metadata, including embedded instructions
  • can potentially be instantiated on other testbeds, like CloudLab
  • can be based on Git repositories
  • can be published to the world

To learn about the portal UI, profiles, and the "geni-lib" DSL, please consult the online documentation:

http://docs.emulab.net/getting-started.html
http://docs.emulab.net/creating-profiles.html
http://docs.emulab.net/geni-lib.html

CLASSIC EXPERIMENTS

The Emulab portal can create profiles from "classic" Emulab experiments, automatically converting NS files into geni-lib scripts. Within the classic Emulab interface, navigate to one of your experiments and select "Create Profile from Experiment" from the left-hand menu. In the portal, you will also see icons that provide a "shortcut" to the converter.

The converter covers the most commonly used features of NS. If you find a missing feature, or have an experiment that cannot convert, please let us know. We are especially interested in feedback about the converter!

MISSING FEATURES

The primary features of NS-based experiments that are *not* currently available in geni-lib profiles relate to the event system. The missing features include dynamic events ("event at time X"), event sequences, event timelines, and event groups. These features are somewhat rarely used by most Emulab experimenters. Please send us feedback if you would like support for these features and/or help with possible workarounds.

Thank you for your help in beta testing the new Emulab portal interface. Happy hacking! ---

Eric Eide Robert Ricci and the Utah Emulab Team

Reserved nodes
Saturday, August 27, 2016, 6:29AM; posted by mike (27).

Update: we are back on regular cooling again and I have put all nodes back in service.

I have take 25+ nodes of each of the pc3000, d430, and d710 types out of the free pool. This is out of an "abundance of caution" in case I need to shutdown machine quickly due to ongoing cooling work in the machine room.

If you do really, really need some nodes, sent mail to testbed-ops@flux.utah.edu.


New Ubuntu 16.04 LTS 64-bit standard Emulab images
Thursday, August 18, 2016, 10:02PM; posted by johnsond (30817).

We've released UBUNTU16-64-STD, a new standard Emulab disk image with Ubuntu 16.04 LTS (Xenial Xerus) 64-bit. The image contains a 4.4.0 Linux kernel, gcc 5.4, systemd 229-4, etc. All Emulab services are launched and controlled via udev and/or systemd. You can find more information at https://wiki.ubuntu.com/XenialXerus/ReleaseNotes . Please test it out, and let us know at testbed-ops@flux.utah.edu if you find anything broken or generally useful packages that are missing.


Unplanned Downtime due to Cooling Failure
Wednesday, July 6, 2016, 10:37PM; posted by ricci (1182).

There has been a large-scale cooling failure in our machine room, so we are turing off some Emulab nodes for the night to try to avoid hardware damage. We have been told cooling will be restored in the morning, but do not have a firm ETA at this time.

Update as of Wednesday night: Emulab is pretty much 100% down right now. I had to turn off all remaining nodes.

Update as of Thursday morning: The word now is "maybe by noon today" we will have cooling again.

Update as of Thursday noon-ish: Machine room is cool again, all the nodes have been powered back on!


Results of the Emulab server upgrades
Tuesday, June 21, 2016, 7:37PM; posted by mike (27).

The downtime on 6/20 went reasonably smoothly. The only thing known to not be working at this time is the documentation wiki.

The net result of the upgrades is that the boss and ops (users) servers are now running FreeBSD 10.2 with newer versions of most ports and packages. The network links from both VMs are now 10Gb dedicated links instead of 1Gb.

If you routinely use users.emulab.net for your work, let us know if you have any issues with software, especially missing packages that you have been using.


Impending Emulab server downtime.
Wednesday, June 8, 2016, 12:32PM; posted by mike (27).

We need to perform some oft-delayed maintenance on the main Emulab server machines, updating OSes and physically moving machines to achieve better network connectivity and power redundancy. Ideally, this won't take more than 2-4 hours, but to be safe we want to schedule a full day (12 hour) downtime.

This will take down the CloudLab, Apt and Emulab portals for the duration. All cluster nodes at Utah, Clemson, and Wisconsin will continue to be available, you just will not be able to access them through the portal. You will also not be able to create/modify/destroy profiles or experiments.

The proposed time window for doing this is Monday, June 20th from 8AM-8PM MDT. If this conflicts with any really important deadlines, please let us know ASAP.


Limit on d430 nodes changed from 10 to 20
Wednesday, February 17, 2016, 7:55PM; posted by mike (27).

I increased the number of d430 nodes that a single project can allocate from 10 to 20 to encourage more use.


160 new nodes are now available in the Utah Emulab testbed!
Tuesday, February 9, 2016, 8:53PM; posted by mike (27).

We are very pleased to announce the latest hardware enhancement to the
Utah Emulab testbed: 160 new Dell PowerEdge R430 server nodes, now
available to experimenters.  Each of these nodes has:

  + two 8-core 2.4GHz Xeon CPUs, 64 GB RAM, 1x 200 GB SSD, 2x 1TB disks
  + six experimental network interfaces (mix of 1Gb and 10Gb interfaces)

For more technical specs, please see: https://wiki.emulab.net/wiki/d430
That web page also lists certain caveats about using these nodes.

To allocate one of these nodes to an experiment, specify the "d430" node
type.  For example, in an NS file, you might say:

  tb-set-hardware $mynode d430

To help many people try out the new nodes, we've set a temporary limit on
the number of d430s that any project can allocate at one time.  The limit
is 10.  We expect to raise the limit in the future.

We have updated the currently supported "standard" Emulab disk images for
the d430 nodes:

  OS                         Disk image name
  ------------------------------------------
  Ubuntu 14:                 UBUNTU14-64-STD
  CentOS 7.1:                CENTOS71-64-STD
  FreeBSD 10.2:              FBSD102-64-STD
  Xen 4.4 w/Ubuntu14 "dom0": XEN44-64-STD

All of these are "ready to go" for experiments on the d430's.

If you want to use a custom image on the d430's, we *strongly* encourage
you to make a new image based on one of the above.  Not only will you get
built-in d430 support, but you will also get the latest security updates.
(And, you'll also be able to run your new disk image on other nodes in
the Utah Emulab testbed as well.)

On request, we will enable an old custom disk image to be swapped in on a
d430.  Beware that things like the 10Gb interfaces may not work correctly
with older images.  This is why we encourage users to make new images.

As always, for help, send your questions to

  emulab-users@googlegroups.com --- public forum for general questions,
  see https://groups.google.com/d/forum/emulab-users

  testbed-ops@flux.utah.edu --- for operational issues, e.g., "my node is
  wedged," hardware failures, marking custom images for the d430's, etc.

This major enhancement of the Utah Emulab testbed is supported by the
National Science Foundation under Grant Number 1513121.

Thank you for using Emulab, and happy hacking! ---

Eric Eide and Robert Ricci
on behalf of all the Utah Emulab
development and operations staff


New nodes are close!
Thursday, January 14, 2016, 10:56AM; posted by mike (27).

We are performing some tests on the first 80 of the 160 "d430" nodes to insure all the wires are correctly hooked up and that the switches are working.

Nodes show be available by next week I hope!


New Emulab firewall in place
Tuesday, December 15, 2015, 11:46AM; posted by mike (27).

We have a new firewall box fronting emulab.net now! We have attempted to replicate the old access rules, but if something doesn't work that used to, let us know.

One difference you will notice is that this is a true stateful firewall and connections through it will timeout once they have been idle for "a while" (don't have the exact number, but it is measured in minutes). So for ssh in particular, you will need to enable "keep alives" to keep your interactive sessions alive.


New Emulab nodes coming soon!
Monday, November 16, 2015, 4:29PM; posted by mike (27).

This is a quick announcement about an imminent refresh of the Utah Emulab testbed. Summary: Better, modern machines and network by the end of the year!

You might have noticed the Utah Emulab testbed was "shrinking" in the past few weeks. Utah staff decommissioned the old pc600s and the pc850s --- about 160 machines that were well past their prime.

Our testbed will not be shrunk for long! In the next few weeks, we will start adding 160 new nodes to the Utah Emulab site. Each of these will have modern specs ---

  two 8-core 2.4GHz Xeon CPUs, 64 GB RAM, 200 GB SSD, two 1TB disks

--- as well as multiple network interfaces, including multiple 10Gb interfaces.

We will start adding these nodes to the Utah Emulab site in late November, and we expect to have them generally available to experimenters by the end of the year. Of course, we will make an announcement when they are available. This email is just a heads-up so that you can look forward to these new resources.

Thank you for using Emulab, and happy hacking! ---

Eric Eide and Robert Ricci on behalf of all the Utah Emulab development and operations staff


Upcoming downtime for Emulab services
Monday, November 9, 2015, 12:36PM; posted by mike (27).

There is a planned power outage in our machine room this Wednesday Nov 11 at 10pm MST. While the actual outage should be no more than 5 minutes (and our servers should ride it out on UPSes) we are taking the opportunity to do a little maintenance.

Prior to the outage, at 8pm, we are going to take down the Emulab SAN (aka, blockstore, aka, dataset) servers so that we can replace a failed disk and updated the OSes. This will not affect most users.

The portal will also be unavailable for 5-10 minutes at around 10pm while I reboot the boss VM to reconfigure the "hardware" a bit.

Emulab cluster nodes will go down during the power outage, so experiments instantiated on the Emulab cluster will be affected.


Imminent decommissioning of the pc600 nodes
Thursday, October 1, 2015, 9:56AM; posted by kwebb (10109).
Please be advised that starting Monday of next week (10/5/15) we will begin decommissioning the pc600 nodes. All of these nodes will go offline tomorrow morning in preparation. They've had an admirable run of over 15 years of service!

In the coming weeks we will decommission the pc850 nodes as well. Another announcement will be posted just prior.

If you are currently making use of either of these node types, now would be a good time to transition your experiments to other available types (e.g. d710 and/or pc3000).

Emulab/Cloudlab/Apt downtime on 9/22
Tuesday, September 22, 2015, 7:16PM; posted by mike (27).

As we have mentioned in a couple of group postings, the Emulab, Apt, and Cloudlab clusters will be unavailable from 8pm MDT tonight until as late as 1am MDT tomorrow morning.

This downtime is for a variety of reasons, including upgrade of network infrastructure in the downtown datacenter, a new firewall for Emulab, and server SW upgrades on Apt and Cloudlab servers.

Parts, if not all, of the infrastructure may be back up well before 1am, but don't count on it.

UPDATE: the conversion to the new firewall did not go smoothly, so neither that or the SW upgrades happened. We'll try again another time...


A reminder about idle resources
Tuesday, February 10, 2015, 6:29PM; posted by mike (27).

Since we just re-enabled the idle resource detector/swapper, this would be a good time to remind people about efficient use of Emulab resources.

If all nodes in your experiment have been idle for 2 hours or longer, your experiment will be swapped out. "Idle" here means that it has not used a significant amount of CPU or control/experiment network bandwidth. You can increase the maximum idle time via the Modify Settings page in the upper left menu on the experiment page.

Keeping nodes active via artificial means (e.g., running screen or periodic "ps" processes) just to prevent an experiment from swapping out is not acceptable behavior.

If your experiment has been swapped in from more than 16 hours it will be swapped out, whether or not it has been idle. You can increase this threshold up to 120 hours (5 days) in the Modify Settings page.

If you need to keep an experiment to remain swapped in longer than the maximum threshold, you will need to contact testbed-ops and explain why you need more time and exactly how much longer you need.


Re-enabling the auto-swapout mechanism
Sunday, February 8, 2015, 8:14PM; posted by mike (27).

At the time we upgraded the Emulab servers back at the beginning of January, we disabled the "maximum duration" and "maximum idle" swapout mechanism for active experiments. This was primarily so that if we were down for longer than anticipated, active experiments would not get penalized for circumstances beyond their control.

However, that was a month ago and things are running just fine. So at 6pm MST on Tuesday February 10th (about 48 hours from now) we are going to re-enable the mechanism. There are currently a large number of experiments that will be affected (i.e., swapped out) either because they have been idle or they have (long) exceeded their maximum duration.

We are sending email to the people who swapped in such experiments, but it would be in your best interest regardless to go to the experiment page for any active experiment you have and check the idle and max duration!

If you are one of the affected parties, then please login and save off any important state you have on the nodes. We would prefer that you then swap the experiment out, but if you don't, it will get swapped out at 6pm Tuesday.

If you absolutely must have more time, then send mail to testbed-ops and let us know why you need more time and exactly when you will be done and we will try to accommodate you.


Emulab is back up!
Wednesday, January 7, 2015, 12:54PM; posted by mike (27).

The upgrade went relatively smooth.

Be on the lookout for problems. Again, you will need to reboot all nodes in any experiment that was active at the time we shutdown. The shared filesystems have all moved and you will get NFS "stale file handle" errors until you reboot your nodes.

Also, when your nodes (for an existing experiment) come up, you will see messages about it unmounting /scratch/your-pid, and that will fail. This is harmless and a consequence of us no longer exporting /scratch directories.

If you have data on a /scratch directory, then you can access it by ssh-ing into users.emulab.net and looking in /oldops/scratch/your-pid. If you need to access that data from experiment nodes, you will have to copy it into /proj/your-pid.


Emulab Changes coming in the new year.
Wednesday, December 31, 2014, 7:44PM; posted by mike (27).

New servers!

First, a reminder that next Monday through Wednesday (5th - 7th) Emulab will be down completely. We are upgrading the "boss" and "users" ("ops") servers and it is unavoidable that their being down will affect any active experiments. As stated in the earlier news item, once the servers are back up again, active experiments should still be okay, though you will need to reboot the nodes due to NFS changes (see below).

Will Emulab really be down for three days? Probably not, but we need some slack in case something goes terrible wrong. If all goes well, we might be back up by Tuesday morning--we'll see.

What is new? Boss and users are moving to VMs on a much faster server machine. The VMs will be provisioned with 8 cores and 16GB of RAM each, so hopefully performance will be improved overall. Both will be running a 64-bit version of FreeBSD 10.1 rather than the current 32-bit FreeBSD 8.3. For those of you who login to "users", any binaries you have should continue to run, though it would be wise to recompile them.

All the user-visible filesystems (/users, /proj, /groups) will now be in ZFS, with each individual home directory and project directory being its own filesystem! The only way you should notice this is if you are prone to going over your disk quota. There will no longer be per-user quotas enforced on each filesystem, instead each filesystem will have a max size (which can be adjusted as needed). So you can no longer--intentionally or not--get around quotas by saving files from nodes as "root" via NFS. As always, if you do need more disk space, let us know--we try to be accommodating. /scratch is going to go away, in favor of larger "quotas" on /proj. We will keep the old /scratch available and mounted read-only on "users" so that you can copy over any files you really need.

New Images!

In a couple of weeks (date TBD), we will be changing the "default" images loaded on the pc3000, d710, and d820 nodes. We will be replacing the embarrassingly old Redhat Linux 9 and Ubuntu 10 with a 64-bit Ubuntu 14.04. Going forward, we will officially support only the following images: Ubuntu 14.x, CentOS 6.x (as the Redhat variant of Linux) and FreeBSD 10.x, all in 64-bit versions. We will also continue to support a 32-bit Windows 7 image.

We may or may not change the default images on the pc600, pc850, and pc2000 nodes. These are the 32-bit only machines which we hope to phase out in the coming year. For the time being, we will make available 32-bit versions of Ubuntu14 and FreeBSD 10.0.


Emulab downtime Jan 5-7
Wednesday, December 3, 2014, 7:35PM; posted by stoller (282).
Utah Emulab will be down Jan 5-7th for a software and hardware upgrade of the servers. During this time no services will be available at all, and you should expect that you will not be able to contact any nodes in your current experiments. We will not swap out any experiments during this time, so you should be able to pick up where you left off, although it is possible that your nodes will be rebooted.

Please plan accordingly!

bash updated on users.emulab.net
Thursday, September 25, 2014, 10:24PM; posted by mike (27).

A back-ported version of bash 4.3.25 has been installed on users.emulab.net to address the bash vulnerability.

It has been very lightly tested, so let us know if there are any problems.


New per-project node allocation limits in place
Monday, September 22, 2014, 9:27AM; posted by mike (27).

The demand for d710 and d820 nodes is relentless so we are resorting to per-project limits to help out. As of this morning, all projects (not users) are limited to 40 d710 nodes and 4 d820 nodes.

If you need more than 40 nodes for a short period of time (where "short" is defined to be days and maybe weeks and not months) let us (testbed-ops) know and we will try to accommodate you.

Note that you may also hit this limit even if you are asking for fewer than 40 nodes because others in your project are using nodes. In that case, first talk to the other people in your project and see if you can work something out. If not, then let us know and we can adjust your quota for a short period of time.

We expect that the quota will be adjusted, and maybe even elimiated, as we try to find a balance between having nodes available for others and just having them sit idle when they could be helping someone.

We will be submitting a proposal this fall to replace a lot of our old nodes (pc600s and pc850s) and, if funded, this will take the pressure off.


ops.emulab.net disk expansion done
Thursday, July 17, 2014, 8:07AM; posted by mike (27).

Everything should be up and operational again.


Downtime for Emulab on Thursday AM
Monday, July 14, 2014, 9:45AM; posted by mike (27).

UPDATE: The downtime is officially set for tomorrow at 6AM.

On Thursday July 17th at about 6AM MDT, I would like to take ops.emulab.net down to add some more disk space. It is expected that this will take 1-2 hours, so we should be back up by 8AM MDT.

Since having the fileserver down affects just about everything, we will just shutdown the Emulab web server during that time. We won't actively shutdown any of the nodes, so if they are operating off strictly local storage (no accesses to /proj, /users, /scratch) they might continue to run okay, but no guarantees!

If this is a bad time for anyone getting close to a deadline (e.g., your deadline is Thursday afternoon), let us know and we will see if we can work out a better time.


Testbed News
Thursday, June 12, 2014, 8:56AM; posted by mike (27).

Yesterday afternoon (06/11/2014) we made a significant change to the way we manage NFS mounts. Previously, we mapped the "root" user on nodes to "root" on the fileserver. While this afforded maximum flexibility to experimenters, it had an unfortunately side-effect of bypassing the quota system on the file server since the "root" user had no quota. This made it too easy to (unintentionally) exhaust the file server's disk space.

So starting yesterday, we now map "root" from nodes to an unprivileged user on the file server with a very small quota. This will require changes to the way some people run experiments, in particular:

  • If you have a daemon or applications that run as root, they should do all their logging to local disk on the node. They may also need to have their configuration and other input information on the local disk. See this page for information about what the NFS mounted filesystems are, how to make use of the local disk, and other possibly alternatives.
  • If you have "root owned" files on the file server that you were using and you cannot access them, you will need to contact testbed-ops@flux.utah.edu to get the ownership changed. Note that doing this change of ownership may put you over your quota and you will be asked to clean up your disk usage.

We will be adding more disk space to the /proj filesystem later this month, but it will be an incremental increase and not an order of magnitude increase. We encourage you to look into the new Emulab storage subsystem to see if it meets you needs, but unfortunately at this time, it does not replace NFS as a large, shared storage mechanism. That is a future extension that we hope to start on soon.


Over-quota issues
Friday, February 21, 2014, 8:50AM; posted by mike (27).

On Wednesday I discovered that a number of users did not have disk quotas. When I corrected this, a number of users were instantly "over quota".

If you are one of those people, please refer to this FAQ entry for help on getting back under quota.


UBUNTU12-64-STD Updated
Wednesday, July 24, 2013, 11:12AM; posted by stoller (282).

The UBUNTU12-64-STD image has been updated; the kernel is moved forward from 2.6.X to 3.2.46, and the clientside has been updated to do linkdelays properly. Let us know if you have any problems.

If needed, you can find the old image at UBUNTU12-64-OLD, but keep in mind that this image will no longer receive updates of any kind.


Having problems with SSH Login to Emulab?
Sunday, June 30, 2013, 8:15AM; posted by stoller (282).

If you suddenly cannot login to Emulab nodes via ssh, it is probably because you are trying to use password based authentication. We have disabled password authentication as a security measure, so you must use key based authentication.

To upload an ssh public key, login to the Emulab web interface, go to your "My Emulab" page and then to "Edit SSH Keys" and upload a pubkey. This will allow you to login to "users" or your allocated nodes from your home machine.

See this very nice tutorial on how to use ssh.


Emulab-based testbeds (up to 1,000 nodes) available as part of PRObE facility
Wednesday, June 19, 2013, 1:04PM; posted by ricci (1182).

Wish you could get more nodes to run larger experiments on Emulab? NSF has funded PRObE, a facility with several large testbeds built with the Emulab software. The largest is Kodiak, a 1,000 node cluster built from hardware donated by Los Alamos National Labs. Several other clusters with differing node and core counts are also available, and are hosted by the New Mexico Consortium and CMU. These clusters will be allocated in large chunks, ensuring that they can support large experiments.

A nice writeup on PRObE's capabilities and the application process can be found on the USENIX blog.


Post-upgrade changes
Friday, December 28, 2012, 10:32AM; posted by mike (27).

A couple of things to note about the recent Emulab server upgrade:

  • We have disabled "elvin compatibility". Chances are, you don't know what that means, but the effect is that the event system in some older (pre-2008 or so) OS images may no longer work. The most obvious symptom is that "linktest" will timeout on swapin. If you have problems, contact testbed-ops.
  • We are in the process of replacing our old default images (FreeBSD 4.10 and RedHat 9!) This includes images that are used for traffic-shaping nodes, virtual-node hosting, and control net firewalls. Again, if you encounter strange problems, let testbed-ops know.
  • "chat" (with jabber) has been disabled. This has been broken for awhile and has now officially been disabled.


Emulab servers have been upgraded!
Wednesday, December 26, 2012, 2:53PM; posted by mike (27).

A lot of significant changes, so be on the lookout for things that have broken and let us know.


Emulab downtime on 12/26
Sunday, December 16, 2012, 2:28PM; posted by mike (27).

The Utah Emulab boss and ops machines will be down starting at around 9am MST on Wednesday, December 26th.

We are going to update the OS on our boss and ops nodes. We are planning on having boss and ops down for the entire day. If all goes well, it will be much shorter, but when is it ever the case that "all goes well"?


New High-End Nodes and 10Gb Networking Available in Utah Emulab
Tuesday, August 28, 2012, 4:28PM; posted by ricci (1182).

We're happy to announce the immediate availability of new equipment in Emulab that represents a significant upgrade in terms of virtualization capabilities, network bandwidth, storage space, and computing capacity. The primary goal of this expansion is to support research on virtualization and the systems underlying modern cloud and datacenter computing. As with other nodes in Emulab, you get "bare metal" access to the hardware. Emulab's Xen support is available on them as well, or you're free to run whatever other virtualization technology you'd like.

The sixteen new nodes each have four 8-core Xeon E5 (Sandy Bridge) processors (a total of 32 cores per node) and 128 GB of RAM. Each has four 10Gb Ethernet NICs supporting SR-IOV virtualization and are connected by a low-latency full-backplane switch from Arista Networks. Each host also has seven disks: one 250GB system disk and six 600GB 10k RPM SAS drives for local storage. In the near future, we will provide a network storage service, backed by software SAN servers, that will offer iSCSI volumes to nodes in this cluster.

Together, the new nodes have a total of 512 cores, 2TB of RAM, 640Gb of Ethernet bandwidth, and 57TB of storage on 96 spindles. More details of the hardware can be found at: http://users.emulab.net/trac/emulab/wiki/d820

To get them, simply request nodes of type 'd820' in your NS file. Since there are a limited number of d820 nodes, they will only be allocated when explicitly requested.

This expansion has been funded by NSF under award CNS-1059440.


Windows 7 Now Available at Utah Emulab
Monday, August 20, 2012, 9:41AM; posted by kwebb (10109).

The Flux Research Group is very pleased to announce the availability of Windows 7 (Professional, 32-bit) for experiments in the Utah Emulab testbed!

You may request Windows 7 by specifying the following in your NS file:

tb-set-node-os $your_node WIN7-STD

Please take a moment or two to read over the revised Windows in Emulab documentation.

Please report any problems, suggestions, etc. to the Emulab Users forum.

For Emulab site administrators: In the next few weeks, the Flux Research Group will post instructions and automation assistance for Emulab administrators who want to create Windows 7 images for their own sites.

Happy experimenting! ---


New Emulab Feature: Controlled degradation of disk performance
Friday, April 27, 2012, 11:50AM; posted by ricci (1182).

We're happy to announce a new feature in Emulab: joining Emulab's longstanding ability to shape network links, it's now possible to introduce delays and failures into disk I/O, allowing you to experiment with the effects of failing or heavily loaded disks.

This feature is built on the Linux kernel's device mapper framework, meaning that it presents a block interface on top of which you can build any filesystem, or even other block devices such as RAID arrays. Using the event system, it's possible to script or dynamically control this behavior, meaning that you can cause individual disks to become slow or "fail" at controlled points during your experiment.

Documentation can be found here

This feature is still in its early stages, and we welcome feedback! The disk image used on your nodes must support this feature; currently, only our FEDORA15-DAGENT image (based on FEDORA15-STD) supports it, but others are planned in the future.


Public access to Emulab source repositories
Tuesday, June 14, 2011, 2:33PM; posted by ricci (1182).

We've decided to make it easier to get the code from our Emulab source code repositories. Previously, access to our git repositories was available to anyone, but they had to request an account on our git server.

This is no longer necessary - we have enabled read-only access to these repositories, no account of any type necessary.

You can read about how to get a copy of our latest source on our git repository page


New Emulab Feature; Bridge Nodes
Wednesday, June 8, 2011, 6:05PM; posted by stoller (282).

We have a new Emulab feature to announce; Bridge nodes, that you can insert into your topology to do your own traffic shaping and link tracing. Much more flexible then normal delay nodes. See the wiki page on Bridge Nodes. Let us know what you think and how it works.


New FreeBSD 8.2 images
Friday, April 15, 2011, 6:02PM; posted by mike (27).

I created 32- and 64-bit versions of FreeBSD 8.2, available as FBSD82-STD and FBSD82-64-STD.

The system and ports source is in /share/freebsd/8.2 on users.emulab.net.


The deed is done.
Monday, December 20, 2010, 5:17PM; posted by mike (27).

Emulab boss and ops have been upgraded to FreeBSD 7.3 and all the ports upgraded. It was not the smoothest of transitions and I'm sure there will be further issues, so let us know what problems you encounter!


Over One Million VLANs Served
Wednesday, November 10, 2010, 10:40AM; posted by ricci (1182).

The links and LANs that you put into your NS files get turned into VLANs on Emulab's switches every time you swap your experiment in. This month, we passed a milestone: we've now created over one million VLANs since we started keeping track about ten years ago.


PRObE: Large new NSF-funded testbed, run using Emulab software
Tuesday, October 12, 2010, 8:22PM; posted by ricci (1182).

We've been working with Los Alamos National Lab, CMU, the New Mexico Consortium (NMC), and the NSF on a new testbed, PRObE.

PRObE will be the largest Emulab-based testbed to date; it plans to host two 1024-node clusters, plus a few smaller clusters. It is being built from decommissioned supercomputers, and will focus on supporting experiments that need hundreds to thousands of nodes.

Small PRObE clusters should be up and running within a few months, with the first 1024-node cluster up within a year.

PRObE website

Press Release


Extended network outage
Saturday, September 11, 2010, 8:15PM; posted by ricci (1182).

Emulab was offline last night and much of today due to a problem with our campus network. This affected Emulab's connectivity to the outside world, but did not affect its internal network; any experiments that were running contained within Emulab should not have been affected.

Details, for the interested:

Last night, at around 9:00 PM MDT, the supervisor module in one of our campus' border routers failed. While our campus has redundant border routers (and is in fact fully redundant throughout the entire router topology), Emulab and the Flux Research Group have a special arrangement through which we bypass the campus firewall; this arrangement is implemented through an MPLS tunnel that terminates on the router that failed. So while the rest of campus failed over to another router, we were off the air for three hours while they replaced the supervisor module.

When our border router came back online, the configuration for our MPLS tunnel did not get re-built correctly. We spent several hours on the phone with campus networking staff overnight and this morning, and they in turn spent hours on the phone with Cisco to debug the issue; it turned out to be a misconfiguration. Around 1:30 MDT today, the misconfiguration was found and we came back online.

Our special firewall bypass has been the source of many misconfigurations over the years, largely due to the fact that it is unique on campus. We are in discussions with our campus networking staff to replace the current tunneled configuration with physical interfaces by lighting up dark fiber across campus. We hope that this will greatly reduce our downtimes due to misconfiguration.


Campus networking problems
Thursday, September 2, 2010, 11:18AM; posted by ricci (1182).

A configuration conflict with our campus network knocked Emulab off the air for several hours. Connectivity to the outside world was affected, but connectivity within Emulab was not, so any experiments that were already running should not have been affected.

The configuration issue is not completely fixed, but a workaround is in place. There may be a short downtime later in the day when the workaround is replaced with a more permanent fix.


Unplanned downtime for cisco8
Thursday, August 26, 2010, 1:42AM; posted by ricci (1182).

While doing some maintenance on the gigabit switch that serves the pc3000s, cisco8, the switch locked up and had to be rebooted. The experimental net for pc3000s was thus down from about midnight MDT to 1:00 MDT.

It should now be functioning normally.


160 new nodes available!
Monday, August 23, 2010, 2:44PM; posted by mike (27).

Finally!

Almost a year ago we began the process of buying 100+ more machines to extend the Utah Emulab. After many delays, including waiting six months for additional AC capacity in the machine room, we are making them generally available. Briefly, they are 160 Dell R710s with quad-core processors and 12GB of RAM each. See here for details.

There are almost certainly going to be issues, so let us know if you have problems (but only after reading the link above!)


Unexpected downtime earlier today
Tuesday, July 27, 2010, 8:35PM; posted by mike (27).

We had a control net switch meltdown from around 5:30-6PM MDT today. All is well again.

We are beginning integration of a physical layer switch to which a layer2 switch and some PCs are connected (so that we can allocate actual switches to experiments) and we accidentally connected together two ports on the switch--bad idea. We managed to set off a spectacular packet storm that lit up our new HP control net switch like a Christmas tree!

The experimental switch has now been disconnected from the control net switch so we shouldn't see that again.

Sorry bout that.


Need to reserve lots of nodes
Monday, July 19, 2010, 3:42PM; posted by mike (27).

We need 100+ of the pc3000 nodes tomorrow, Tuesday July 20th, starting at about 8AM MDT. This is for a tutorial session at a conference. So we may need to ask current pc3000 users to give up their nodes before then. We should be done with them by the afternoon.

So be patient if you cannot get any nodes tomorrow!


New Google Group for Users
Friday, July 16, 2010, 9:37AM; posted by stoller (282).

We have created a new forum/mailing list on Google Groups, intended for all users of all Emulab sites. Please subscribe to this list, and use it to ask questions of other users, or help others with typical problems and issues that are common to all Emulab sites. Subscribe at emulab-users.


Emulab sloooooooooowwwwww
Wednesday, June 23, 2010, 11:25AM; posted by mike (27).

Our firewall/router is in a state of meltdown at the moment. Probably not an attack, just some new firewall rules that did not work as planned.

Working on it...stay tuned.

UPDATE: should be fixed now.


A security reminder
Saturday, May 1, 2010, 10:33PM; posted by mike (27).

If you are installing OSes on Emulab that do not include the standard Emulab client-side scripts (e.g., Xen virtual machine images), then you need to make sure that all accounts in those images have strong passwords!

We have had a couple of instances lately of people installing their own VMs which had weak root passwords that were exploited.

Part of the problem was because Emulab would return a routable IP address when a VM DHCPed. This will no longer happen, so don't expect it.


Another unexpected downtime
Monday, April 12, 2010, 3:06PM; posted by mike (27).

Around 1:45pm MDT today we lost power to parts of Emulab. You know the story: someone doing electrical work, couldn't possibly affect the machine room...takes down almost everything.

Boss, ops and the pc3000s remained up, however, must of the experimental net switching infrastructure went down, so experiments could well have been affected.


A Chance To Show Off Your Research
Tuesday, March 23, 2010, 11:07AM; posted by ricci (1182).

The GENI Project Office is putting out a call for 'demo proposals' - a few projects will be showcased for large demos at a future GENI Engineering Conference. This is an interesting chance to have your research demonstrated to a large set of people within the GENI project, the NSF, etc. For this demonstration, a diverse set of resources that are being assembled to form the GENI testbed will be available, as will support from the providers of those resources and the GENI Project Office. Testbed resources will include hundreds of nodes at several of the Emulab sites, cross-country backbone links, nodes from PlanetLab, switches supporting the OpenFlow standard on several campuses, and much more.

If you have some research you'd like to show off, the deadline to submit proposals is April 1. You don't need to be a current GENI user to submit a proposal.

Date: Fri, 12 Mar 2010 14:30:57 -0500
To: geni-announce@geni.net
From: Chip Elliott <celliott@bbn.com>
Cc: mberman@bbn.com, Chip Elliott <celliott@bbn.com>
Subject: A remarkable opportunity to demonstrate your best ideas

We are delighted to announce an opportunity for you to demonstrate your best ideas in networking and distributed systems on a nation-wide networking and computing infrastructure that we are dubbing "GENI alpha".

If accepted, your ideas will be demonstrated to government, university, and corporate leaders with help and support of a professional engineering team, at a special GENI Engineering Conference in Washington, DC, in November 2010.

Please read the attached slides for details. Mark Berman, from the GPO, will formally unveil this opportunity at GEC 7, and will be very happy to brainstorm with you about your ideas.

Important Note - your demo proposals will be due VERY SOON.... April 1, 2010.

Attachment


Abrupt Emulab downtime
Wednesday, January 13, 2010, 2:45PM; posted by mike (27).

We apologize for the abrupt and prolonged Emulab downtime this morning. A series of suspicious events led us to believe that we might have had a breakin. Displaying "an overabundance of caution", we blocked access to Emulab so we could track down what was going on.

We are happy to report that found no trace of problems and have determined the causes of the unusual behaviors (an unexpected password change, mysterious root logins, malformed XMLRPC requests--you know, the stuff of spy novels).

We never shutdown any of the servers, just blocked access at the firewall, so all experiments swapped in at the time of The Event should still be there. We have temporarily disabled the Java-based GUI tool while we further look into XMLRPC issues.

Thanks for your patience and once again, we apologize for the inconvenience!


Emulab maintenance done
Wednesday, December 30, 2009, 9:18AM; posted by mike (27).

Two Cisco fan trays replaced and both servers upgraded. Things to watch for:

  • Network link problems on pc600s and pc850. Replacing the fan trays involved temporarily disconnecting a lot of wires. If you have an existing experiment using pc600/pc850s, you might want to run "linktest" (checking connectivity and latency) on it.
  • Odd application behaviors on "users". I did not upgrade anything in /usr/local (i.e., FreeBSD ports), but everything in /bin and /usr/bin is new. The kernel was upgraded from 6.2 to 6.4-stable.


Emulab Downtime Schedule
Tuesday, December 29, 2009, 8:36AM; posted by dreading (32620).

Expect Emulab downtime to start 5am MST. Downtime is expected to be 2-3 hours.


A belated happy holidays!
Monday, December 28, 2009, 10:20AM; posted by mike (27).

Happy holidays to everyone!

We have been, and will continue to be this week, thin on testbed-ops coverage, so expect delays in response.

We would also like to take advantage of this short week to perform some maintenance tasks that we have been putting off.

In particular, we need to replace a couple of failed fan trays in Cisco switches. Because of the current switch topology, this will affect the entire experimental switch fabric and will require that we shut-off access to the Emulab web interface while we are doing it. Also, due to the location of the fan tray in the chassis, we will need to disconnect literally hundreds of wires to replace the trays, so expect downtimes of an hour or more.

I would also like to perform minor upgrades of the OSes on boss and ops to address security concerns. We will likely do this during the same downtime.

So when will this all happen? We haven't fixed a time yet, but I would like to aim for tomorrow in the morning (MST). I will update later today to let everyone know for sure.


switch problems
Monday, December 14, 2009, 9:17AM; posted by mike (27).

One of the big experimental switches had a memory fault and shutdown late yesterday. It has been rebooted and seems happy again.

However, if you have a swapped in experiment that is using pc3000 nodes, make sure that all your links are operational. If not, let us know--it is possible that some VLANs got lost.


Re: Planned power outage 10/14/2009
Wednesday, October 14, 2009, 8:05AM; posted by dreading (32620).

The planned power outage has been completed. Some node did not go down. The racks holding the pc3000 where down through the outage.


Planned power outage 10/14/2009
Thursday, October 8, 2009, 4:50PM; posted by ricci (1182).

There will be electrical work done in our machine room, largely to support a major cluster expansion that we have in the works. In order to run some more circuits into the room, power will be shut down from 5 AM to 8 AM MDT on Wednesday, October 14.

We will have backup power to allow many of our servers to stay up, but Emulab nodes will be shut down during this time.


Outages over
Sunday, September 27, 2009, 6:01PM; posted by ricci (1182).

Today's outages were short, but took a while to clean up after. Things should now be back to normal.


One down, one to go
Sunday, September 27, 2009, 10:36AM; posted by mike (27).

The morning power outage lasted all of 20 seconds instead of 15 minutes. If we had known that in advance, we would not have taken any of our machines down! But, as it was, we had some problems bringing the switching infrastructure back up.


Reminder: Emulab power outages tomorrow 9/27/09
Saturday, September 26, 2009, 9:48PM; posted by mike (27).

Just a reminder that there will be two short (15 minute) downtimes for Emulab tomorrow at 7AM MDT, and again sometime in the afternoon. The afternoon downtime depends on when work gets completed, but is likely to be in the 1PM to 3PM range.

During the downtimes, all connectivity to emulab.net will be cut off and all experiment nodes will reboot. The main Emulab servers, boss and ops, should stay up the entire time.


Two short power outages on Sunday
Tuesday, September 22, 2009, 9:09AM; posted by mike (27).

On Sunday Sept. 27th there will be two short (15 minutes) outages at 7AM and 3PM MDT.

boss.emulab.net and users.emulab.net should remain up during these outages, but all nodes and the switching infrastructure will go down at those times. All infrastructure should be up between those times (~7:30-2:30).

So plan on being disrupted during those times. Sorry for the inconvenience!


Another short network outage
Monday, September 21, 2009, 11:37AM; posted by ricci (1182).

We had another short outage on our network connection to campus today. As with last Friday's outage, this only affected connectivity to the outside world, not connectivity within Emulab. This should be cleared up now.


Short Unplanned Campus Network Outage
Friday, September 18, 2009, 5:31PM; posted by ricci (1182).

We briefly lost our connection to campus (and thus the outside world) around 5:00 PM MDT on September 18th. We worked with our campus networking people, who were able to isolate and resolve the problem.

Emulab itself stayed up, and the experimental network was not affected. The only experiments effected would be those that relied on getting out to the Internet.


Unplanned ops.emulab.net shutdown
Tuesday, September 15, 2009, 2:25PM; posted by mike (27).

Through a series of unfortunate events, I managed to shutdown ops and then hang it. It is rebooting and checking the disks now.


One year on...
Tuesday, September 15, 2009, 10:35AM; posted by mike (27).

It has been one year since Prof. Jay Lepreau, the founder of the Flux Research Group, passed on. Just thought we would send out a quick note to let everyone know the current state of Emulab and the Flux Group.

Needless to say, it has been a very busy year and it has taken several people to fill Jay's shoes.

But as result of many people's hard work, the Flux Group continues to thrive. In the past year, we have hired new staff members and picked up several new graduate and undergraduate students. With the help of several faculty members within the School of Computing at the University of Utah, we smoothly transitioned all ongoing research projects and made significant---though in some cases, limited---progress on all. We even had time to pursue several new funding opportunities as well!

We continue to recruit candidates for the Jay Lepreau Named Professorship position here at the University. As a result, over the last year, we have had the opportunity to meet and talk with a number of energetic researchers.

Emulab continues to grow---not just the facility, but the software and architecture as well. The Utah cluster (the "mothership") will undergo a significant expansion this fall, and we will likewise be expanding our building-wide wireless network in the coming year.

Through the ProtoGENI project, we are federating with other Emulab sites, allowing cross-site experimentation. ProtoGENI is also placing nodes in Internet2 colocation centers around the country, allowing for a small-scale, dedicated, nationwide backbone for experimentation.

The software base continues to grow in a number of exciting ways, including the aforementioned support for GENI, increased support for virtual nodes, and much more. Expect a news posting soon detailing all our technical efforts in the past year!

We have done a great deal of thinking about scaling, extensibility, and security issues in the past year as well. If all goes well, we hope to implement many of our new ideas in the coming year.

We have welcomed a number of new Emulab-based facilities in the last year, with several more "in the works." You can now see the current state of Emulab facilities worldwide on our web page.

Thank you to everyone in the community for helping to make Emulab a success! We here in Flux remain committed and energized, and we look forward to the year ahead!


Possible shutdown of nodes this morning
Tuesday, September 8, 2009, 9:43AM; posted by mike (27).

We need to turn off the A/C in our machine room starting at 10AM this morning (for about 30 minutes). If things starting getting hot enough to endanger our servers, we will start shutting off experimental nodes.

The servers (boss and ops) should stay up the whole time.


Unplanned Network Outage
Wednesday, July 29, 2009, 1:49AM; posted by ricci (1182).

Due to a power bump which caused our campus network to lose a switch, Emulab was cut off from the outside world for a few hours tonight. Working with campus networking folks, we were able to restore connectivity. Nodes in your experiments may have been affected by this power bump.


Scheduled maintenance on our upstream network provider
Thursday, June 11, 2009, 4:57PM; posted by ricci (1182).

The University of Utah's upstream network provider, UEN, has scheduled some maintenance on their backbone this weekend. It is scheduled to begin at 2 AM MDT on Sunday, and is expected to last two hours. During their maintenance, access to Emulab from outside may be sporadic. Traffic within Emulab will not be affected, so if you have experiments running, the will continue, you will simply not be able to reach your nodes from outside.


UPDATE on pc3000 availability
Monday, June 8, 2009, 8:40AM; posted by mike (27).

Looks like we will need them through today (6/8). They will be available again on Tuesday (6/9) instead.

Sorry for the misinformation!


pc3000s unavailable
Wednesday, June 3, 2009, 12:15PM; posted by mike (27).

There will be a pc3000 shortage through next Monday (6/8/09) as we need to run some scaling tests that require 100+ of them. If we manage to reserve enough nodes before that, we may be able to run our tests and free the nodes sooner, but it will be no later than Monday.

Therefore, if you currently have pc3000s allocated in experiments, please swap them out as soon as possible. If we have not accumulated enough nodes by Saturday night, we will have to start forcibly swapping experiments out.

If this is a life-altering, career-killing inconvenience to you, let us know!


New Ways of Looking at Emulab
Friday, May 8, 2009, 12:54PM; posted by ricci (1182).

We've added a few new interesting ways of visualizing information about Emulab and its users.

To help you understand how busy Emulab is, and the times when you're most likely to be able to find free nodes, we now have node availability graphs showing recent and long-term availability trends.

Our "Emulab users" page now includes a map of the cities where Emulab users are located. There is also a fullscreen version of this map.

Our "Other Emulabs" page also includes a map, showing the facilities around the world that are using the Emulab software to run their testbeds.


Scheduled Power outage May 10th
Wednesday, April 8, 2009, 10:50AM; posted by dreading (32620).

The University has scheduled a power outage for our building from 6am -8pm MDT on May 10, 2009. We will begin to shutdown emulab.net starting at 4am MDT. Only our main router will remain powered up.


CFP - Workshop on Cyber Security Experimentation and Test
Tuesday, April 7, 2009, 1:40PM; posted by ricci (1182).

We'd like to make our users aware of a call for papers that might be if interest to many of you. CSET is a workshop seeking short papers on testbed use and tools. It is primarily aimed at, but not limited to, security-related research.

The following is an excerpt from the CFP. The full CFP can be found here.

Effective cyber security and network experimentation is challenging for today's network testbeds for a number of reasons. Among these are:

  • Scale: Experiments that involve complicated composite behaviors, rare event detection, or emergent effects may need to be quite large and complex to be accurate or indicative.

  • Multi-party nature: Most interesting cyber security experiments involve more than one logical or physical party, due to the adversarial nature of the problem as well as the distributed, decentralized nature of the networked systems environment.

  • Risk: Cyber security experiments by their fundamental nature may involve significant risk if not properly contained and controlled. At the same time, these experiments may well require some degree of interaction with the larger world to be useful.

Meeting these challenges requires both transformational advance in capability and transformational advance in usability of the underlying research infrastructure. The second annual Workshop on Cyber Security Experimentation and Test (CSET '09) invites submissions on the design, architecture, construction, operation, and use of cyber security experiments in network testbeds and infrastructures. While we are particularly interested in works that relate to emulation testbeds, we invite all works relevant to cyber security experimentation and evaluation (e.g., simulation, deployment, traffic models).

Topics of interest include but are not limited to:

  • Security experimentation
    • Positive or negative experiences from past experiments
    • Novel experimentation approaches
  • Testbeds and methodologies
    • Tools, methodologies, and infrastructure that support risky and/or realistic experimentation
    • Supporting experimentation at a large scale (virtualization, federation, high-fidelity scale down)
    • Experience in designing or deploying secure testbeds
    • Realistic traffic and topology generators
    • Instrumentation and automation of experiments; their archiving, preservation, and visualization
    • Diagnosis of and methodologies for dealing with experimental artifacts
    • Fair sharing of testbed resources
  • Hands-on security education
    • Experiences teaching security classes that use hands-on security experiments for homework, in-class demonstrations, or class projects
    • Experiences from red team/blue team exercises


Emulab Secondary Nameserver Moved
Tuesday, January 13, 2009, 11:15AM; posted by ricci (1182).

The secondary nameserver for Emulab has been moved. The change should be transparent, but if you run into any problems, please let testbed-ops know.

Many thanks to Dave Andersen for hosting this nameserver (and our old secondary as well).


Emulab Holiday Schedule
Monday, December 22, 2008, 12:51PM; posted by stoller (282).

We just want to let you all know the University of Utah holiday closure schedule, and thus when Emulab technical support will be minimal to non-existent:

  • Wed Dec 24 - University closed
  • Thu Dec 25 - University holiday
  • Fri Dec 26 - University closed
  • Thu Jan  1 - University holiday

In addition, many Emulab staff members will be on vacation and/or taking personal time from now until January 2nd.

So, from now until the new year, response time will be slow; please be patient.


Power Failure
Monday, December 8, 2008, 11:26AM; posted by mike (27).

We had a building-wide power failure at 10:30AM MST today. Thing should be back up and running normally in a few minues.


Outage Completed
Sunday, November 9, 2008, 1:30AM; posted by ricci (1182).

Though it took longer than expected, our outage has been completed, and the new redundancy tests out fine.


Short Emulab network downtime Saturday, Nov. 8 at 10 PM
Thursday, November 6, 2008, 2:34PM; posted by ricci (1182).

There will be a short downtime of Emulab's connection to the Internet on Saturday, November 8 at 10 PM MST. The total window scheduled for the outage is two hours long, but we expect the actual outage to take only a few minutes. During this time, all nodes and servers in Emulab will remain up; they will simply be unable to reach the Internet.

The main purpose of this outage is to improve the redundancy and robustness of our off-campus link. Emulab staff will be working with campus networking staff to ensure that the change goes smoothly.


Updated disk images for Fedora Core 6 and Fedora Core 8
Tuesday, September 30, 2008, 7:42PM; posted by rdjackso (31974).

We've updated the standard Fedora Core 6 and Fedora Core 8 images to be in sync with the latest available packages and kernels from Fedora. We've also improved the images to prevent boot failure when trying to mount the root filesystem.

Details:

  • The Fedora Core 6 (FC6-STD) kernel version is now 2.6.22.14-72
  • The Fedora Core 8 (FEDORA8-STD and FEDORA8-64-STD) kernel version is now 2.6.25.14-69.
  • The mkinitrd script in each image now generates an initramfs that includes drivers for most IDE, SATA, and SCSI controllers.

The FC6-STD, FEDORA8-STD and FEDORA8-64-STD images now contain these and other changes. If you have any problems using the updated images, you may use the FC6-STD-OLD, FEDORA8-STD-OLD and FEDORA8-64-STD-OLD images.

If you have any problems with these images, please let us know.


Update MyPLC Image Now Available
Monday, September 22, 2008, 5:17PM; posted by kevina (30825).

An updated MyPLC image based on PlanetLab 4.2-rc18 is now available as PLAB-PLC. However, please note that you can not use pc3000s for the PlanetLab nodes since they will not boot. The older MyPLC image based on PlanetLab 4.0 is now available as PLAB-PLC-v40. Please see this Knowledge Base entry for more info.

Update, Nov 11: PLAB-PLC is now PLAB-PLC-v42


In Memoriam
Friday, September 19, 2008, 4:02PM; posted by stoller (282).
In Memoriam

We are sad to report that Jay Lepreau, Research Professor and Director of the Flux Research Group, passed away Monday morning Sept 15th due to complications of cancer. Jay was an enthusiastic and productive researcher, a dedicated mentor of students and staff, and an avid participant in recreational activities such as music and outdoor sports. His loss will be felt by all who knew him, both within the computer science community and elsewhere.

Please be assured that we plan to carry on the vision for Emulab that we shared with Jay, and that operation and development of the Utah Emulab facility and the Emulab software will continue.


Emulab Software Now Supports HP ProCurve Switches
Thursday, September 11, 2008, 4:13PM; posted by ricci (1182).

We're happy to announce that our recent release of the Emulab software adds support for HP ProCurve switches. This means that ProCurve switches can now be used to build Emulab experimental networks. At this time, ProCurve 5412, 3500, and and 2810 switches have been tested, but we expect that other ProCurve products should work as well.

This support was contributed by Keith Sklower of DETER, one of the largest Emulab installations, where it is in active use.

HP support joins Emulab's existing support for Cisco, Foundry, and Nortel switches.

Emulab's hardware support and recommendations can be found here: http://users.emulab.net/trac/emulab/wiki/HWRecommend


Finally! The official Emulab source release
Tuesday, September 9, 2008, 2:18PM; posted by mike (27).

With very little fanfare, I have put out the "official" Emulab 5.0 release tarballs. See the software page for details.

Update: I forgot to mention that Grant Ayers put together a tarball of the installation documents that you can download and unpack locally. Just in case you cannot reach our Wiki for some reason.


Emulab Documentation moving to Trac Wiki
Friday, July 18, 2008, 5:09PM; posted by stoller (282).

The Emulab documentation has officially moved into a Trac Wiki at https://users.emulab.net/trac/emulab/wiki so that all of our users and collaborators can help us improve our documentation.

Please tell us what you think of the new wiki.


Full Emulab source release
Monday, June 30, 2008, 11:35PM; posted by lepreau (12).

We've released the full Emulab software as open source for your perusal or installation or hacking pleasure. This comes with mostly-online installation documentation, as well. This version 4.9.0 should be fine for installing new Emulabs, but we strongly recommend that people upgrading their existing Emulabs wait for version 5.0, which we intend to release in July.

Get your source and your docs from our software page.

Kudos to the skilled and hard-working Utah Emulab developers and operators for this magnum opus. Special acks to Grant Ayers for testing and the docs, and to Mike Hibler and Leigh Stoller for many things.


New Form to Submit Your Emulab Publications
Wednesday, June 11, 2008, 4:25PM; posted by kevina (30825).

A new form is available to record any publications, theses, reports, talks, software, or services for which you used Emulab. If your publication or significant software is not already listed in our publication list and you have used Emulab to validate your research, please use the form to add it (must be logged in). And thank you-- doing so will help keep Emulab funded!


CFP - Workshop on Cyber Security Experimentation and Test
Monday, April 28, 2008, 12:49PM; posted by ricci (1182).

We'd like to make our users aware of a call for papers that might be if interest to many of you. CSET is a workshop seeking short papers on testbed use and tools. It is primarily aimed at, but not limited to, security-related research.

The following is an excerpt from the CFP. The full CFP can be found here.

Security challenges constantly grow in complexity and scale. To meet these challenges, security professionals need safe experiment environments, tools, and methodologies to:

  • capture new threats,
  • study threats through interactive experimentation,
  • dissect and reassemble malware,
  • pit new attacks against proposed defenses, and
  • test defensive technologies in a large-scale, realistic setting.

This workshop aims to gather both researchers who use testbeds for security experimentation and testbed developers to share their ideas and results and to discuss open problems in this area. While we particularly invite papers that deal with security experimentation, we are also interested in papers that address general testbed/experiment issues that have implications on security experimentation such as traffic and topology generation, large-scale experiment support, experiment automation, etc.


Short Emulab network downtime on Tuesday, April 21
Monday, April 21, 2008, 3:25PM; posted by ricci (1182).

Tomorrow (Tuesday) at 7 AM MDT, we'll be switching our routes back through our bypass of the campus firewall. This is to "back out" the temporary workaround put in place to fix Friday's outage, getting us back to our usual configuration, which exempts us from campus firewall rules.

The outage is expected to be short, and we'll simply revert if it causes problems.

Longer-term, we have discussed a solution with our campus network operators that should cause more graceful failover when things go wrong, and should give us more control over our routes, so that we can fix things up on our own. The plan is to implement this in a few weeks.

Update: This outage is complete, with < 1 minute of downtime


Fedora 8 standard Emulab image now available in both 32 and 64 bit versions
Monday, March 10, 2008, 11:37PM; posted by kevina (30825).

There is now a Fedora 8, Emulab-supported disk image available for use under the name FEDORA8-STD. In addition, a 64 bit (x86_64) version of Fedora is available under the name FEDORA8-64-STD.

The 32 bit and 64 bit versions have an identical set of packages installed, apart from some 32 bit compat library versions on the 64-bit image. For additional information on the 64 bit image, see this KB entry.

Note that end node traffic shaping is unavailable; we need to port some modifications made to 2.4 kernels to the 2.6 line.

If you find something missing or broken, please let us (testbed-ops) know.


NetFPGA boards available in Emulab!
Thursday, December 20, 2007, 9:58PM; posted by johnsond (30817).

We've added Emulab support for NetFPGA boards (programmable network devices designed at Stanford University). NetFPGAs appear largely as a normal Emulab node, so you can add them to your experiment topology, reprogram the FPGA, and experiment with your own hardware-assisted router designs! Currently we've installed one NetFPGA each in two pc3000s, but this is only the first step in a larger deployment.

For more information on how to use these devices, , look at the tutorial at

   http://www.emulab.net/tutorial/docwrapper.php3?docname=netfpga.html

For general NetFPGA information, look at http://netfpga.org/.

If you have questions or problems with the NetFPGAs, send mail to testbed-ops.


Changes to building scale wireless testbed
Sunday, December 16, 2007, 8:57PM; posted by johnsond (30817).

Experimenters who have used our building-scale wireless testbed, or plan to, should read this note.

This week, we'll be replacing our existing 18 building-scale wireless nodes, starting on Tuesday (Dec 18). The deployment of these new nodes is the beginning of a larger deployment, but one that will take some time. The new nodes have faster, dual-core processors, and different wireless cards (based on the Atheros AR5006XS with the AR5414 chip).

Based on our usage observations, we don't believe this change this will jeopardize any in-progress paper efforts; however, please let us know if you need specifically the current set of nodes and the existing hardware for your experiments, and we'll try to adjust our deployment plan to accommodate your needs.

We apologize for the short notice! If you have questions, please send mail to testbed-ops.


How many pc3000s are free?
Wednesday, October 31, 2007, 5:57PM; posted by lepreau (12).

To get the per-node-type free counts like used to be there, click on the little "Free PCs" box in the banner. It's a toggle.

Thanks to Leigh for adding this. It took some hacking due to restrictions of iframes.


New Web Look Coming
Tuesday, October 23, 2007, 3:52PM; posted by stoller (282).

Just a heads up that sometime in the next day or two, Emulab will get a slightly different look. The main menus, which have traditionally been on the left side of the screen, are moving to the top of the screen as drop down menus. The banner across the top will also be smaller and more space efficient.

The motivation for these changes is to leave more room for actual content in the main window. Our ongoing "experimenters' workbench" project needs that real estate, but the additional space is generally useful.

We have tried to test this out on as many browsers as we can, but there are bound to be glitches. We do know that it works in Firefox (1.5 and 2.0), Safari (2.0 and 3.0) and on Internet Explorer Version 7. IE6 has some visual issues that might make it a little annoying, but view it as incentive to upgrade your version of IE (IE7 has been out a long time!).


Node shortages as NSDI deadline approaches
Wednesday, October 3, 2007, 10:08AM; posted by mike (27).

With the looming deadline on next Tuesday, there has been a surge in demand especially for 'pc3000' nodes. We have one experimenter who needs to get a 51 node pc3000 experiment swapped in so I have started reserved nodes for his use. What everyone can do:

* If you do not need Gb ethernet or fast machines, please use the pc600 and pc850s. Use tb-set-hardware to force use of those.

* If you need Gb ethernet and fast machines and your experiment is small (< 10 nodes) and it is short duration (< 12 hours), consider using the 'pc2400c2' nodes which are the fastest machines out there, but there are only 20 of them. Again, ask for them with tb-set-hardware.

Update: I forgot two other important criteria for using the pc2400c2s. One, is that you must use either FBSD62-STD or FC6-STD as the OS. Two, is that you cannot need more than one experimental interface per node (they have only one interface hooked up).


New wireless 802.11 testbed in Emulab
Friday, September 7, 2007, 4:48PM; posted by johnsond (30817).

The Flux Research Group at the University of Utah is pleased to announce the availability of a new 802.11 wireless testbed within the Utah Emulab facility. We've added 802.11a/b/g cards to 36 rack-mounted PCs and deployed the antennas in a compact grid (3m x 2.25m) on the back of the racks in our machine room. These machines are already part of the Emulab infrastructure, with five wired interfaces per node, and the many existing Emulab wired and wireless features are available on them.

The goal of this mini-testbed is to give users an opportunity to conduct experiments with wireless nodes in a congested, compact, and hostile environment. By deploying these nodes in a machine room, we expose them numerous opportunities for interference, multipath effects, and congestion. We believe that experimenters can use these nodes to effectively test applications and protocols in congested, close-quarters scenarios, such as a meeting with many laptops in a crowded conference room. Experimenters can easily specify wireless topologies, modify wireless and link parameters during experiment runtime, and include in their experiment nodes that are deployed as part of our existing building-scale 802.11 wireless testbed.

You can look at the hardware configuration and some environment information for these PCs at

  http://www.emulab.net/tutorial/docwrapper.php3?docname=wireless.html

Sign up for an Emulab account here:

  http://www.emulab.net


Emulab adds twenty more machines!
Friday, September 7, 2007, 4:15PM; posted by mike (27).

A number of people have expressed interest in Intel machines with VT technology for doing hardware-assited VM experimentation. To accomodate these people we have setup 20 Dell Optiplex 745 dual-core machines, each with a single Gb control interface (see here for details). These are known as pc380-pc399 and you should ask for nodes of type pc2400c2 to get them. Current, only a small subset of OSes run on these machines: FreeBSD 6, FreeBSD 7, and Fedora Core 6. We have no plans for further OS support (read: Windows) at this time.

This should enable some small scale experimentation with Xen and other VMs.


Wireless: New features, updated disk images
Friday, May 18, 2007, 3:15PM; posted by johnsond (30817).

We've improved wireless network configuration, both statically via NS files and dynamically during experiment runtime, for both 802.11 and GNU Radio devices, and have updated the default wireless disk images.

Details:

  • (802.11) More control via NS files and better wireless mode selection. For instance, you can now set up adhoc mode in an NS file, and you can specify more hardware control parameters to iwconfig.
  • (802.11) More options for dynamic network configuration (changing wireless device properties via link_config or XMLRPC) at runtime. In addition, dynamic config can now help you work around possible issues in the madwifi drivers and Linux wifi support.
  • (GNU Radio) Support for dynamic reconfig. Also added important params that can help you get your GNU Radios talking to each other more easily.
  • (802.11) Updated the madwifi drivers on both wireless images to the latest version (0.9.3). For RHL90-WIRELESS, we also updated the kernel to version 2.4.34 and patched the wireless extensions in the kernel to version 18.

The FC4-WIRELESS and RHL90-WIRELESS standard wireless images now contain these and other changes. If you encounter any problems, you can use the FC4-WIRELESS-OLD and RHL90-WIRELESS-OLD images.

Check out the wireless and GNU Radio tutorials for more information:

http://www.emulab.net/tutorial/docwrapper.php3?docname=wireless.html
http://www.emulab.net/tutorial/docwrapper.php3?docname=gnuradio.html

As always, please let us know if you have any problems with these images.


New images are installed!
Thursday, May 10, 2007, 4:29PM; posted by mike (27).

The new images described in the previous message are now installed at -STD. Again, if you encounter any serious problems, you can use the -OLD images.


More standard images changes coming
Monday, May 7, 2007, 12:54PM; posted by mike (27).

UPDATE: Make that Thursday May 10th! I have been side-tracked by other issues and don't want to install the new images this late in the day.

UPDATE: Make that Wednesday May 9th!

On Wednesday May 8th we are going to install a batch of new images. Once again, there are no changes to the OSes or standard utilities, but this time there will be a significant change to the Emulab client-side infrastructure.

We are replacing the underlying mechanism of the Emulab event system. We have been using Elvin, but due to restrictive licensing, we have decided to replace it with a much simpler, home-grown publish-subscribe system.

What does this mean to you? Well, hopefully nothing! In theory, everything will continue to work as it did. The potential implication is that your events might behave differently. So if you encounter problems with your scripted actions (e.g., program agents don't start) let us know.

If you don't want to deal with potential problems right now, you can continue to use the old standard images by specifying -OLD images (e.g., RHL90-OLD instead of RHL90-STD).

If you want to preview the new images now, use the -UPDATE versions (e.g., RHL90-UPDATE).

The affected images are: FBSD410, FBSD54, FBSD62, RHL90, FC4, FC6.


Fedora Core 6 standard Emulab image now available
Monday, April 30, 2007, 1:53PM; posted by johnsond (30817).

There is now a Fedora Core 6, Emulab-supported disk image available for use under the name FC6-STD. We've tried to include a similar set of software packages to those installed on the FC4-STD image (of course, the versions are updated), so the environment should feel similar.

Note that end node traffic shaping is unavailable on FC6-STD; we need to port some modifications made to 2.4 kernels to the 2.6 line.

If you find something missing or broken, please let us (testbed-ops) know.


New Experiment Specification GUI
Thursday, April 26, 2007, 1:50PM; posted by ricci (1182).

We have a new experiment specification GUI that has been in testing for quite some time now. We're happy to announce that it is now available to all Emulab users. There is a link to the new GUI at the top of the Begin Experiment page, or you can access it directly. The old NetBuild GUI is still available.

The new applet supports a much broader range of Emulab features, such as software installation, program control, traffic generators, and setting of environment variables. It uses our XML-RPC interface to automatically download lists of images you are allowed to use, tarballs/RPMs in your project directory, and more. Let us know if you have any problems with it or feature requests.


Opensearch Plugin
Thursday, March 15, 2007, 12:19AM; posted by ricci (1182).

Emulab now has an Opensearch plugin. This means that you can use that little search box in the toolbar of Firefox 2.0 or IE 7 to search the Emulab documentation and knowledge base. In Firefox, the dropdown arrow next to your current search engine should glow, and you can add the Emulab search engine by clicking on it. Or, in any browser that supports Opensearch, click on the new link at the bottom of the search results page.


Daylight Savings Time has arrived!
Sunday, March 11, 2007, 10:07AM; posted by mike (27).

Note that it is now DST in the United States, three weeks earlier than usual. The biggest impact of this is that older OS images will display the incorrect time. I have fixed the FBSD410, RHL90, FBSD54 and FC4 -UPDATE images, and will get to the other newer images. I will move these to the standard images once the SOSP deadline has passed.

Of course, if you use UNIX timestamps or UTC, you will be unaffected.

UPDATE: and those with a sense of irony will note that the time stamp for this message, as well as the time displayed in the upper right side of the frame, are wrong! The web server needs to be restarted to pick up the corrected timezone info...


New NSDI papers on Flexlab and the Workbench
Friday, March 9, 2007, 7:22PM; posted by lepreau (12).

We've posted our final NSDI papers on Flexlab and the Experimentation Workbench. These are running in alpha test in Emulab right now. If you'd really like to try one of them for your research, especially Flexlab, let us know.


Software development efforts at Emulab (Continues)
Thursday, March 8, 2007, 11:20AM; posted by stoller (282).

As part of the Emulab Federation and Workbench projects, we are continuing to rollout substantial changes to the Emulab software, particularly the web interface code. These changes are primarily to allow for users and other core abstractions to be globally named. These changes should be mostly invisible, but some bugs are bound to creep into the system. Please report anything that seems wrong or questionable.


Minor Website Visual Update
Monday, February 12, 2007, 4:21PM; posted by ricci (1182).

We've updated our banner, usage table (that thing in the upper right corner), and a few other minor things. We've tested it with all the browsers we could lay our hands on, but if you notice any formatting problems, let us know.


More disk space on users.emulab.net!
Friday, February 9, 2007, 7:40PM; posted by mike (27).

We have added more disk space on users.emulab.net. At the moment, this is manifested by a larger (40GB -> 200GB) /users filesystem and a much larger (430GB -> 2TB) /proj and /groups filesystem.

Is it enough? Well, our limitation here is really how much we can afford to backup to tape, and not how much disk space we can buy. As a compromise, we will be making available another 2TB of space, with the caveat that it will not be saved to tape. However, this is still part of the larger RAID5 array, so hardware failure will not cause loss of data.

All files from the old filesystems should be copied over to the new filesystems but in the event that something is missing, the old filesystems are temporarily available in /old (e.g., /old/proj, /old/users).


Software development efforts at Emulab Continue
Tuesday, January 16, 2007, 2:36PM; posted by stoller (282).

More changes were installed today; the newuser and newproject pages have been fully reimplemented in the Emulab backend so that they can be accessed from the XMLRPC interface in addition to the web interface.

These changes should be mostly invisible, but some bugs are bound to creep into the system. Please report anything that seems wrong or questionable.


Software development efforts at Emulab
Thursday, December 21, 2006, 10:33AM; posted by stoller (282).

As part of the Emulab Federation project, we are rolling out substantial changes to the Emulab software, particularly the web interface code. These changes are primarily to allow for users and other core abstractions to be globally named. These changes should be mostly invisible, but some bugs are bound to creep into the system. Please report anything that seems wrong or questionable.


Major new features coming to Emulab
Wednesday, December 13, 2006, 2:23PM; posted by lepreau (12).

For previews of three major new features that we'll put into beta production in weeks to months, see the new papers and slides we've recently posted, or better, go to the three new project project pages linked from the Flux Group web site:

  • Flexlab:
    1) The best of PlanetLab and Emulab, wrapped up into one system.
    2) Separated network model to drive Emulab experiments.
    In alpha test in the live Utah Emulab, with 3 models.

  • Experimentation Workbench: Automate, record, and export all your work, experiments, data, and analyses. In alpha test in the live Utah Emulab.

  • Fully stateful swapout and time-travel of experiments. Interrupt your running experiment at any point and transparently continue it tomorrow. Can't find that bug? Then go back and forward in time. The pieces for stateful swapout are done.

We've been working hard on each of these projects for at least 12-18 months. More news on several other developments coming soon.


New Windows images
Friday, November 17, 2006, 5:55PM; posted by fish (30775).

I have updated the Windows images with the current Emulab test node-side (linktest and event system improvements) and increased the C: disk space from 4 to 8 gig.

WINXP-UPDATE* include Windows Updates through the 11/14/2006 Patch Tuesday. The WINXP-SP{0,1,2}* images, as always, are unpatched. Use WINXP-UPDATE for normal security.


New Standard Images again
Monday, September 25, 2006, 10:12AM; posted by mike (27).

I have once again updated the standard images. The set includes: RHL90, FC4, FBSD410, FBSD54, FBSD61.

Once again, the changes are confined to the Emulab client scripts (and once again, fixes to linktest!) and no kernels or standard applications are affected.

If you do encounter changed behavior, let us know ASAP!


Madwifi driver updated in RHL90-WIRELESS image
Thursday, July 6, 2006, 3:49PM; posted by kwebb (10109).
We have updated the Madwifi driver to version 0.9.1 in the RHL90-WIRELESS image. The new driver is much more stable than the old one.

If you're not familiar with Emulab's wifi capabilities, please read through our wireless tutorial.

For more information on this driver and its features, please visit the Madwifi wiki.

SSH to Node Button now works on Max OS X
Friday, June 30, 2006, 7:53AM; posted by stoller (282).

We added instructions on how to configure your Mac OS X browser to do SSH to Node. Please let us know if you have any problems or questions.


New standard images
Tuesday, June 20, 2006, 9:59AM; posted by mike (27).

I have updated the -STD versions of: RHL73, RHL90, FC4, FBSD410 and FBSD54. The new versions have updated Emulab client-side scripts. The most important change is to "linktest," the link tester that runs at experiment swapin time (whether you want it to or not!) The new version should run much faster for LAN topologies and generate fewer false positives.

The only other difference between the new and old images that has been reported is that /usr/local/bin/emulab-iperf has moved to /usr/local/etc/emulab/emulab-iperf where all the other emulab specific binaries are.

There should be no changes to the kernel or standard utilities, but let us know if you encounter problems.


Unexpected Emulab downtimes
Friday, May 26, 2006, 8:58AM; posted by mike (27).

Many people have noticed that Emulab "disappeared" for hours at a time, twice this week. This was due both times to routing problems in our upstream providers. We are going to get together with them to see what we can do to prevent this in the future.

Just FYI, to let you know that these were not Emulab-related downtimes that we forgot to inform people about. But we apologize just the same, especially to those of you who are frantic due to imminent deadlines!


Emulab backups (filesave) have resumed
Tuesday, April 18, 2006, 2:35PM; posted by kwebb (10109).

File backups have resumed on Emulab. Please recall that we only backup the filesystems on the Emulab servers and _NOT_ those located on the experiment nodes. This covers the /proj, /group, and /users trees on users.emulab.net (ops), which are NFS mounted on the experiment nodes.


Hardware-independent Windows XP images
Monday, April 10, 2006, 12:13PM; posted by fish (30775).

The Emulab Windows XP images are no longer specific to a particular hardware type, and will work on pc600, pc850, pc3000, and pc3000w nodes. See the Change Log for more information.


PlanetLab DevBox image
Friday, February 24, 2006, 4:27PM; posted by ricci (1182).

Need to build binaries to run on PlanetLab? We now have a disk image that acts as a PlanetLab DevBox. This means it has software as similar as possible to the PlanetLab nodes. Unlike the PlanetLab nodes, however, it has a compiler. It also has the usual Emulab software, so you'll get your account, home directory, etc.

You can use it by asking for the PLAB-DEVBOX image. If you don't want to have to mess around with an NS file, you can use our tool to automatically generate an NS file using this image.

There is a knowledge base entry describing how to use this image. You can also use it to run run your PlanetLab app in Emulab.


Our own Mike Hibler interviewed
Friday, February 24, 2006, 8:33AM; posted by lepreau (12).

Find out what OS is favored by studly kernel hackers from Truth or Consequences, NM, in this interview at http://blogs.ittoolbox.com/unix/bsd/archives/007589.asp.


Testbed Pictures
Thursday, February 23, 2006, 2:54PM; posted by mike (27).

I finally put out the pictures from our cluster expansion last summer. See the Photos section.


Stricter NS parsing
Tuesday, January 24, 2006, 9:40AM; posted by stack (424).

We are now running NS files through the real NS parser as a check that our own parser is functioning correctly. This change should not cause a problem for most files, however, there is some syntax that works in our parser but not the real one. For example, the following NS would not parse correctly anymore because the "node1" and "node2" strings are not variable references:

  set node1 [$ns node]
  set node2 [$ns node]

  $ns make-lan "node1 node2" 10Mbps 0ms
The fix is simply to prefix them with dollar signs:
  $ns make-lan "$node1 $node2" 10Mbps 0ms
In cases where the variable name is constructed programmatically, you can use the "set" command to get the value of the variable. For example, to fix the following NS:
  for {set i 0} {$i < 10} {incr i} {
    set name node$i
    set $name [$ns node]
    append lanstr "$name "
  }
  $ns make-lan $lanstr 10Mbps 0ms
You would change the "append" line to get the value of the variable specified by the "name" variable like so:
    append lanstr "[set $name] "

Resource crunch
Saturday, January 21, 2006, 6:15PM; posted by lepreau (12).

1. Due to high demand for resources, we've changed the idle timeout from 4 hours to 2 hours. After that your experiment will be swapped automatically.

2. You are expected to pro-actively swap out your experiment when you're done, not wait for Emulab to detect it idle. Please try to remember; it helps everyone.

3. Finally, if you're consuming lots of testbed resources, and you could be using our virtual nodes (FreeBSD jails) but aren't, you can expect us to start leaning on you, possibly hard. So you might start doing that application port to FreeBSD now, from Linux. Spend a day, save 50 PC3000s day after day.

Thank you!

Avoid excessive logging to the "users" machine
Sunday, January 15, 2006, 1:36AM; posted by mike (27).

We experienced a lockup of our ops/users machine earlier tonight. After forcibly rebooting it, it hung again as it was coming up. It appears that the second time at least, was caused by massive NFS activity.

A reminder: please avoid "excessive" logging of experiments to the /users and /proj NFS mounted filesystems. Excessive here means not only high volume from a single node, but also moderate volume from a large number of nodes!

Look into the loghole facility, which allows you to log to the local nodes and return the logfile automatically later.


Standard images updated again
Tuesday, January 3, 2006, 10:26AM; posted by mike (27).

I have once again installed new versions of the so-called "standard" images: FBSD410-STD, RHL90-STD, FBSD54-STD and FC4-STD.

The changes were only to update the Emulab client-side (test node-side) linktest scripts; no other kernel or application changes have been made. So you should see no functional or performance differences.


RSS Feed for News
Friday, December 30, 2005, 2:08PM; posted by ricci (1182).

We've added an RSS feed for this news page. To subscribe, simply paste the URL from the "RSS Feed" at the top of this page into your favorite RSS news reader.

Firefox, Safari, and other modern browsers will auto-detect the presence of the feed and present you with an icon (usually in the URL bar or the status bar) to allow you to subscribe.


The Emulab-PlanetLab Portal Lives!
Friday, December 16, 2005, 4:02PM; posted by kwebb (10109).

After a very long interruption, Emulab's PlanetLab portal is up and running once more. Users with PlanetLab access should definitely give it a try (and provide feedback).

Note that you can quickly and easily setup a PlanetLab slice including custom software installation, automatic script startup, and powerful but simple node selection via the "Create a PlanetLab Slice" menu link. The traditional NS script and XMLRPC paths are, of course, also available.

Read the PlanetLab interface documentation for more info.


New standard images
Friday, November 18, 2005, 9:54AM; posted by mike (27).

I have installed new versions of the so-called "standard" images: FBSD410-STD, RHL90-STD, FBSD54-STD and FC4-STD.

The changes were only to update the Emulab client-side (test node-side) scripts; no other kernel or application changes have been made. So you should see no functional or performance differences.

The new images will allow automatic link testing (connectivity, latency, loss, bandwidth) at swapin time when enabled. This feature ("linktest") has been present for awhile but was optional and not very reliable. The latest version is significantly better and will be enabled by default, for all experiments, when we've worked out some issues.


NFS Problems
Wednesday, October 5, 2005, 2:10PM; posted by stoller (282).
Some users have mentioned a higher incidence of NFS failures from their experimental nodes when building sofware in /proj or /users (which are NFS filesystems, mounted from users.emulab.net).

With the addition of 160 new (and very fast) nodes, the testbed is much busier and the load on the NFS server is much higher. Writing across NFS is particularly prone to cause problems. These are ongoing and known problems with NFS.

We encourage users to build their software on the local disks of their experimental nodes to avoid transient NFS problems, then later use "scp" or similar to copy it back to the server.

RHL73 image updated
Monday, September 26, 2005, 7:09PM; posted by kwebb (10109).

We have updated the legacy Emulab RHL73-STD image to run on the new pc3000 nodes. In the process, we updated the packages and kernel to get security and bug fixes (all updates are from the RHL73 channel of fedoralegacy.org). Please also note that the kernel has been compiled to support SMP, and has a modern Intel Pro/1000 driver.


New Collaboration and Development Tools
Wednesday, September 14, 2005, 10:30AM; posted by stoller (282).

Emulab has just made available a new set of collaboration and development tools, which we hope will assist you in your research, development, and experimentation.

On your left hand side is a new menu called the Collaboration menu with four entries (more entries to be added later).

  • My Wikis: Each user has their own Wiki page, and each project has its own WikiWeb. Users are of course free to modify their Wiki pages and any pages belonging to the projects they are members of. Project leaders may change the permissions on project pages, making them readable (and writable) by other Emulab projects and/or members, or they can make them world readable (and writable). External users (without Emulab accounts) may also apply for wiki accounts so they can access your Wikis.
  • My Mailing Lists: Emulab has switched its mailing lists over to the popular, open source, Mailman package. All of the per-project and group lists are now maintained as a Mailman list on users.emulab.net. In addition, any registered Emulab user can create (and administer) new lists. External users (without Emulab accounts) are free to join your lists.
  • My Bug Databases: Emulab has installed the popular FlySpray bug tracking package, making it available to all projects. Each project has its own bug tracking database, initially accessible by just project members. Project leaders may also allow external users read or read-write access to project bug database.
  • My CVS Repositories: Each project now has its own CVS repository, hosted on users.emulab.net. Repositories can be accessed by project members via the web, or directly on users.emulab.net, or with CVS over SSH. Project leaders can make their repositories publically readable via a toggle on the Emulab project page.
In summary, each of the four services defaults to read-write and restricted to project members, but you can open up each of them more broadly.

As always, please feel free to comment on these new services, report bugs, request new features, etc. We have plenty more coming and your comments can affect that.


More on new pc3000 nodes
Tuesday, September 6, 2005, 12:52PM; posted by mike (27).

For more details on the pc3000 machines, see this document.


160 new pc3000 nodes
Friday, September 2, 2005, 12:19PM; posted by lepreau (12).

Just a very quick note to help you avoid trouble; more details later.

The 160 new 'pc3000' nodes are available to all. 3.0Ghz, 2GB memory, 2 big fast SCSI disks, 4 experimental interfaces, with between 1-4 of those connected to a fast Gbit-capable switch; all are 100-mbit capable.

The potential "trouble" is that these nodes are hugely different in performance from the existing pc600/pc850 nodes that you use most of the time. So if your experiment specificies type "pc" you could now get a mix of nodes of very different performance characteristics. Previously, that was much less likely (we only had a small number of pc3000w's and pc2000's).

More later, but feel free to use them now. Try to wait to ask questions, as our upcoming docs should answer most.


New type name for WiFi nodes
Wednesday, July 20, 2005, 3:56PM; posted by mike (27).

We have changed the node type name for WiFi nodes. What was once 'pc3000' is now 'pc3000w'. I have attempted to fix all existing experiments, so you just need to make sure that you specify 'pc3000w' in all future experiments.

Note that this is the type name only, and does not affect the names of individual nodes. So if you use tb-fix-node for a specific pcwf node, you do not need to change that.

Why the change? Because we want to use 'pc3000' for our 160 new cluster machines. Given that we have pc600, pc850 and pc2000, pc3000 is the logical follow on.


Fedora Core 4 standard Emulab image now available
Tuesday, July 19, 2005, 6:27PM; posted by kwebb (10109).

An official Red Hat Fedora Core 4 image, using the 2.6 kernel, is now available for use under the name FC4-STD. This is a supported, functional Emulab image. Many thanks to Kevin Atkinson for putting this together.

Please note the following two caveats:

  • linktest (topology verifier) is unavailable as it needs to be ported to FC4
  • End-Node Traffic Shaping ("linkdelays") is unavailable as the required kernel modifications need to be ported to Linux 2.6.
Please note that FC4 Now Uses Gcc 4.0 which may cause some people/programs problems, however an older version of Gcc, 3.2 is also available under the name gcc32/g++32.


ops (users) node upgrade
Thursday, June 23, 2005, 4:54PM; posted by mike (27).

Well, it took most of the day, but users.emulab.net has been upgraded. It went from dual-850Mhz to dual-3000Mhz CPUs so you will notice a speed boost. More importantly, it has double the amount of disk space, so we should not be constantly running out!

If you had an experiment swapped in during the transition from old machine to new machine, you may have to reboot all the nodes in the experiment to clear "stale NFS file handles". Let us know of any problems.


New default images
Monday, May 23, 2005, 9:58AM; posted by mike (27).

I have updated the common standard images (FBSD410-STD, RHL90-STD, FBSD53-STD). This is largely a maintenance update to get the Emulab client scripts up to date. Both FreeBSD and Linux also have new kernels, required to include support for the SCSI controller on our upcoming cluster nodes. This kernel change should not affect the performance or function of the kernel.

Let us (testbed-ops) know if you encounter any problems.


Major Emulab cluster expansion
Wednesday, May 18, 2005, 6:07PM; posted by lepreau (12).

I'm pleased to announce that we will be bringing online a lot of new hardware in the next couple of months. Fast nodes, gigabit, a really fast switch, and tons of disk space! I/O capacity was the primary technical criterion for the nodes.

  • 160 new nodes, Dell 2850s:
      Processor: 3.0 GHz 64-bit Xeon, 800Mhz FSB
      Memory: 2GB DDR2 400Mhz
      I/O: Multiple PCI-X 64/133 and 64/100 busses
      Network: 6 10/100/1000 Intel NICs spread across the busses (one NIC is the control net)
      Disk: 2 x 146GB 10,000 RPM SCSI
  • New servers: users/ops, boss, and a new fileserver:
    Like the test nodes, but dual processor, 4G RAM, more disk, RAIDed.
  • Multi-terabyte storage array
  • Switches:
    Cisco 6509/Sup720 - 720Gbps switching fabric; hi-speed Gbit line cards
    Cisco 6513 - mostly 100Mbps
    Cisco 6506 - control net

Many machines will not have all 5 experimental NICs attached to switch ports, but we will have almost 400 Gbit switch ports immediately. We may directly connect some nodes. The Magic of Assign will transparently handle all this physical network heterogeneity.

We are retaining our current 200-odd nodes, so will have about 360 total. If we solve the enormous scaling problems on swapin, our back-of-the-envelope suggests one could run a 10,000-20,000 virtual node experiment. There are about 18,000 AS's in today's Internet...


New Windows XP image
Tuesday, April 26, 2005, 9:50PM; posted by mike (27).

We have fixed the problem that was causing Windows experiments created with Netbuild to fail. Netbuild creates all experiments with "Static" routing enabled, and that form of route computation was broken. There was also a problem with Windows finding all the interfaces when it booted. Hopefully that is fixed as well.

To summarize, use the WINXP-UPDATE image. This is an image of WindowsXP SP2 with security fixes up through yesterday. The firewall is disabled (as it will inform you repeatedly!) by default.


New: Mobile wireless motes, high security, Windows, wifi
Friday, February 18, 2005, 8:50AM; posted by lepreau (12).

We've opened for public use four major new features in Utah's Emulab network testbed. They are documented and ready for anyone's reasonable research or educational use, or just take them for a test drive.

1. 900MHz Motes and 802.11 Stargates on robots: a truly mobile wireless testbed, with experimenter-specified movements, simple path planning by Emulab, a vision-based tracking system, live maps, and webcams. Control and monitoring are completely integrated into the existing Emulab system, so a mobile experiment is very similar to a classic Emulab experiment. This first installation is small, but it all works.
Mobile robotic wireless tutorial.

2,3. Secure environments for running malicious or risky code:
      A per-experiment switch-enforced firewall.
      A per-experiment Emulab, by providing Emulab-in-Emulab.
Plus, at no extra charge, color-coded security levels that automatically set up different defense levels.
Secure environment docs.

4. Windows XP is now a supported test node OS, joining Linux and FreeBSD. Most Emulab features work, including ssh keys and file service. It's got Remote Desktop if you need Windows look-and-feel; it's got Cygwin if you prefer Unix.
Windows XP docs.

Finally, let me remind you that we also have a non-mobile 802.11a/b/g testbed available: 27 PCs scattered around our building, most with two Atheros cards. You can change the madwifi driver, the OS, everything.

Click here to request an account.

Kudos to the whole Emulab team, but especially to Tim Stack, David Johnson, Dan Flickinger, Leigh Stoller (robots); Mike Hibler, Leigh Stoller (secure env); and Russ Fish, Kirk Webb (Windows).

Jay Lepreau
University of Utah


Max Duration of Experiments
Monday, January 3, 2005, 5:30PM; posted by stoller (282).

In order to reduce the number of wasted nodes, we are now defaulting Max Duration in the Begin Experiment page, to on. Idle or not, your experiment will be forcibly swapped out after the allotted duration, currently 16 hours, unless you uncheck the box or change the duration.

Please don't uncheck it without good reason. Should you later find you need more time, you can alter this param using the "Edit Experiment Metadata" link on the experiment info page.


New FreeBSD 4.10 and Red Hat 9.0 images
Wednesday, November 17, 2004, 3:49PM; posted by mike (27).

I have installed a new default image. The only changes should be to the boot-time Emulab configuration scripts which should not affect your experiments, past, present or future. Let us know if you have any problems.


Linux 2.6 (aka Fedora Core 2) image
Tuesday, November 9, 2004, 10:33AM; posted by mike (27).

Due to popular demand (ok, one person asked for it :-) we have put out a prototype Fedora Core 2 image. This image should be considered unsupported, but of course we would like feedback about anything misconfigured or missing.

To use the image, put:

    tb-set-node-os $node FEDORA2-NONSTD
in your NS file (where $node is replaced with whatever your node is called of course).


Firewall your Experiment from the Internet
Wednesday, October 20, 2004, 4:26AM; posted by lepreau (12).

Mike added support to Emulab that provides a flexible control-network firewall between any experiment and the outside world. For example, key syntax is:

        # Create a firewall node
	set fw [new Firewall $ns]
        # Configure it
	$fw set-style <closed|open|basic>
The purpose of such a firewall is to prevent experimental traffic from accidently escaping to the Internet due to a misconfigured application or router within an experiment. In its initial limited form, the Emulab firewall is intended to prevent accidental misuse and not malicious abuse. We have more powerful firewall support brewing.


New versions of FreeBSD and RedHat Linux
Saturday, September 11, 2004, 6:48PM; posted by mike (27).

On Monday, September 13th at 9am MDT we will be switching our "default" OS images from FreeBSD 4.7 and RedHat 7.3 to FreeBSD 4.10 and RedHat 9.0.

How will this affect you? Well, if you explicitly specify an OSID in your new experiments (e.g., tb-set-node-os FBSD49-STD), then you won't notice at all. However, if you specify one of the "standard" images (FBSD-STD or RHL-STD) you will get the new OS version. Likewise, if you do not specify any OS, which defaults to RHL-STD, you will get the new version.

When you swapin an existing experiment which uses (directly or indirectly) either FBSD-STD or RHL-STD, the OS you get depends on when the experiment was created. Experiments created prior to 9am Monday will continute to be mapped to FreeBSD 4.7 and RedHat 7.3. Experiments created after that time will get 4.10 and 9.0. If you prefer that your older, existing experiment get the newer OS, then you will have to modify the experiment and set the node-os explicitly.

UPDATE: I have moved the changeover time to 10am MDT to make sure I am on-site when it happens.


We are back!
Saturday, September 4, 2004, 10:25PM; posted by mike (27).

We have reenabled the web interface and brought up 40 (Sep 7th: all) of our nodes.

If the new air conditioner is still running smoothly tomorrow (Sunday), we will bring up the rest of the testbed. We took advantage of the down time to upgrade a few things:

  • ops.emulab.net got a minor face lift. It is now a dual 850Mhz machine with 1GB of RAM (up from 1 500Mhz CPU and 512MB). It is also now back on a gigabit interface rather than 100Mb.
  • Both ops and boss were upgraded to FreeBSD 4.10 (from 4.7 and 4.9) and their various ports upgraded. There should not be compatibility issues, but let us know if there are!
  • Emulab has changed its IP space. As part of a campus wide "re-IPing", we have moved from 155.101.128/20 to 155.98.32/20. Addresses of note:
            boss    from 155.101.128.70 to 155.98.32.70
            ops     from 155.101.129.74 to 155.98.33.74
            pcNN    from 155.101.132/22 to 155.98.36/22
    

Still to come, later next week:

  • We will be switching the default OS images for the nodes from FreeBSD 4.7 and Redhat 7.3 to FreeBSD 4.10 and Redhat 9.0. If you do not specify any OSID, or use the generic "RHL-STD", for a new experiment you will now get RHL90-STD. If you specify the generic "FBSD-STD" you will get FBSD410-STD. Existing swapped experiments with those generic OSIDs will continue to get mapped to the old RHL73-STD and FBSD47-STD when swapped in.


New Feature: Event Groups
Thursday, July 15, 2004, 7:37AM; posted by stoller (282).

To make sending events to multiple agents easier, we have added Event Groups. Quick example, say if you have four links, named link0, link1, link2, link3:

	set mylinks [new EventGroup $ns]
	$mylinks add $link0 $link1 $link2 $link3

	$ns at 60.0 "$mylinks down"
See the advanced tutorial for more information on events and event groups.


New Emulab Features and Hardware
Monday, May 24, 2004, 3:05AM; posted by lepreau (12).

I'm pleased to announce public availability of these features and hardware on the Utah Emulab facility, for anyone with a valid research, educational, or development use. See www.emulab.net for details or to sign up.

  1. These five new types of nodes and networks can be mixed and matched, are fully integrated into Emulab, and support (almost) all of its features.
    • Wireless 802.11a/b/g. 9 nodes now, 30 any day, more later.
    • 8 IXP1200 network processors.
    • VM-based nodes and networks; scales to 2000 high-degree nodes.
    • All PlanetLab nodes; many features: www.emulab.net/doc/plabexamples.pdf and plab.html
    • ns-based simulated nodes and networks.
      And existing:
    • 180 PCs with 5 ethernet interfaces
    • 45 RON/netbed widearea nodes

    We've had some of these node types for ~8 months (VMs, PlanetLab) but they were not widely advertised; others are newly featureful (ns).

  2. XML-RPC interface to Emulab. Control Emulab from your desktop command line or roll your own client in your favorite scripting language.
  3. GUI client for creating and interacting with experiments, as an adjunct or alternative to the Web interface. Build/edit topologies graphically, click on nodes to login, click on links to change properties, etc. Alpha software, but useful. See www.emulab.net/netlab/client.php3

    • Build and interact with the topology from a single interface.
    • Interact with existing topologies.
    • Support for Emulab-specific extensions to the NS syntax.
    • Uses the Emulab XML-RPC interface.
    • Integrated access to node consoles.
  4. Many other features added long ago, including:
    • Flexible barrier synchronization
    • SFS support
    • Integrated event system:
      -Schedule events statically as in 'ns', or dynamically
      -Control arbitrary programs, links, nodes

Jay Lepreau
University of Utah


Wireless testbed available
Wednesday, May 19, 2004, 3:41AM; posted by lepreau (12).

We have extended the Emulab software to support wireless LANs, and have started deploying a medium-sized public testbed running 802.11a/b/g. These can be mixed and matched with other types of nodes and links. 9 wireless nodes are currently available; 20 more in boxes will be installed soon. We expect to add more in the coming year, as well as many mote-level devices.

Read all about it and give it a spin, but pay attention to the acceptable use policy.


New Simulation/Emulation Documentation
Thursday, April 1, 2004, 1:35PM; posted by shash (10082).

I have updated the documentation for Hybrid Experiments with Simulation and Emulation with all the new capabilities. There is also a picture illustrating a detailed example on using this.


New documentation
Wednesday, March 31, 2004, 5:32PM; posted by mike (27).

I've added a couple new pages of documentation:


XML-RPC interface to Emulab now available
Thursday, March 25, 2004, 7:32AM; posted by stoller (282).

An XML-RPC interface to Emulab is now available! This interface allows you to perform common operations from the command line, or you can roll your own client in your favorite scripting language (Python, Perl, etc).

Full documentation is here.


Two new FreeBSD images available
Friday, March 5, 2004, 10:04AM; posted by mike (27).

We have made two new FreeBSD images available, one for FreeBSD 4.9 and one for the recently released FreeBSD 5.2.1.

FBSD49-STD is intended to become our default image, replacing FBSD47-STD for use in delay nodes and virtual (jail) nodes as well as for everyday use. 4.9 is supposed to be the end of the road for the 4.x series, so I figured it was time to upgrade. Sources are accessible via /share/freebsd/4.9/src.

FBSD52-STD is a first attempt at the latest FreeBSD line. This image also has updated ports. Sources are at /share/freebsd/5.2.1/src.


Unofficial RedHat 9 Image Available
Friday, February 13, 2004, 11:12AM; posted by kwebb (10109).

Emulab user Craig Rodrigues of BBN has been kind enough to share his hard work in upgrading the standard Emulab RHL73 image to RHL9. We are providing it as an interim solution for those seeking RedHat 9 while we work on producing an official testbed release.

You can reference this image as "RHL9-NONSTD" in your ns files or from Netbuild.

Note that there are a few things to be aware of if you choose to use it:
* The image is _NOT_ supported.
If you run into problems, you're on your own. You are welcome to email Testbed Operations (NOT Craig!) with problems, but don't count on any responses.

* The 2.4.20 kernel in the image contains modifications.
It has been modified to include support for the SCTP protocol (an alternate to TCP and UDP). This shouldn't present a problem, but please be aware.


Slight change in /etc/hosts files
Wednesday, February 11, 2004, 4:54PM; posted by ricci (1182).

We have made a slight change in the way /etc/hosts files are generated on the nodes. The previous behavior was that we would only create "aliases" (short names, referring to the name of a node, and not a spicific interface) for nodes that are not directly-connected if there is a route between them. The new behavior is to do this for all nodes, regardless of whether or not a route exists.

For an explanation of the various ways you can name nodes within an experiment, see this FAQ entry.


PlanetLab support broken for now
Saturday, December 20, 2003, 2:40PM; posted by lepreau (12).

Emulab's Planetlab support, for creating and managing dynamic slices/experiments, has been broken by Plab's abrupt move to new software, triggered by their security breakin. We'll re-target as soon as we get details on the new APIs, and APIs that work.


Change to program objects
Tuesday, November 11, 2003, 1:33PM; posted by stoller (282).

The program object no longer allows you to specify the command to run when using the command line interface. The old syntax:

tevc -e foo/bar now prog0 start COMMAND='ls /'

You no longer specify COMMAND. Instead, the command is that which was specified when the progam agent was created in your NS file. In other words, we no longer provide a remote execution facility for arbitrary commands.
Instead you can start/stop existing program agents as they are specified in your NS file.


New Frisbee source release
Tuesday, October 21, 2003, 10:23PM; posted by mike (27).

I have put out a "snapshot" of the current Frisbee source code in the Software section. We have made a couple of bug fixes and improvements and wanted to get the code out there. See the README for more information. There is also an updated ISO image.


Emulab interface to Planetlab, in production
Monday, September 22, 2003, 7:22PM; posted by lepreau (12).

We've made PlanetLab resources available through the familiar Emulab interface, with many of the standard Emulab features and some new ones. New ones include load-driven allocation with admission control. Optionally combined with Emulab's queuing facilities, that is useful for sharing PlanetLab resources when they are scarce.

You might use the Emulab interface to provide a richer and more friendly interface to the PlanetLab nodes and to your experiment. Or, you might use it to get the N least-loaded nodes that satisfy your node type criteria, perhaps queuing your request until enough become available.

Note that we don't provide tunnels or link or topology emulation! Our PlanetLab support gets you a bunch of rich (v)nodes fully interconnected through the normal Internet: not any specific topology.

More details are available in the announcement message and in the prototype ns file, planetlab.ns.


Emulab cluster use RESTRICTED for next week
Monday, September 15, 2003, 12:52PM; posted by lepreau (12).

Sorry to to have to do this, but our cluster is overloaded and people with imminent important deadlines are not able to swapin, despite active coordination with us and trying at all hours by them. Often they cannot map due to just a couple of missing nodes.

Therefore, for the next week, until Tuesday 9/23 just after the NSDI deadline, or until earlier notice, use of the Emulab cluster is limited to people working on deadlines that are

  • imminent, and
  • important.
What qualifies is at our sole discretion.

If you think you might qualify, send mail to testbed-ops@flux.utah.edu. Otherwise, please don't create or swap in *any* experiments until 9/23 or further notice from us, and swap out any active experiment right away; thanks.

With luck the main deadline-driven users will get their work done soon and we'll be able to relax this policy early.

Additional alternatives are the University of Kentucky's Emulab cluster, which is available for external research, and perhaps Georgia Tech's is also. They are linked off the "Other Emulabs" link on our home page.

p.s. If you wish, talk to your funders, asking them to support getting us more nodes.


Starting experiments when nodes are scarce
Thursday, September 11, 2003, 1:55PM; posted by mike (27).

With the impending NSDI deadline, many people are having trouble getting experiments swapped in. A heretofore undocumented feature of batch experiments can help. If you submit an experiment as batch mode, without including tb-set-node-startcmd commands in the NS file, the experiment will be queued until sufficient nodes are available. See the FAQ entry and batch mode introducation for details.


Experimental IP subnets changed from 192.168 to 10.
Thursday, September 4, 2003, 2:25PM; posted by stoller (282).

In order to support more than 255 links in an experiment, we have switched the IP subnet base from 192.168.x.x to 10.x.x.x. If you have any scripts that assume 192.168, you will need to change them.

This only affects new experiments and experiments that you modify with the Modify option on the experiment info page. Existing experiments that are either swapped in or swapped out will continue to use their existing 192.168 address until they are terminated (obviously) or "modified"


Changes in "Begin Experiment" form and in Swapping
Thursday, July 17, 2003, 12:58PM; posted by newbold (2224).

You may notice changes in the "Begin an Experiment" form. We modified it to incorporate some new features we've recently developed. Along with it, the documentation in the Node Usage Policies/Swapping page has been significantly updated.

The previous "Swappable" field is replaced by the "Idle-Swap" field. "Idle-swap" lets you choose whether or not your experiment can be automatically swapped after it has been idle the designated time. If you uncheck it, you have to give a good reason. Note that even if you uncheck this, but your experiment is idle a long time, the system will send you mail, and eventually we will manually swap it for you if you don't respond. You may lower but not raise the idle-swap time.

To be extra clear, if you don't check idle-swap it doesn't mean you're totally unswappable, it just means that we'll attempt to interact with you before we manually swap you out. Talk to Testbed Ops if you must have a totally unswappable experiment or need the idle-time raised.

The new "Max Duration" field lets you set a timer to cap the length of time your experiment runs after swapin. At that time it will be swapped-out, whether or not it's idle. This helps if you forget to swap out, or know when your experiment will end. We send warning email an hour before your max duration expires, so you can avert disaster if necessary.

You may also notice that on the Experiment Information page the new fields are shown. On that page, you can edit those settings by using the "Edit Experiment Metadata" option. So you can turn the settings on or off, and adjust the times, for instance to change your max duration.

As always, we're here to help, so contact Testbed Ops with any questions, problems, or feedback about these changes, or other changes you'd like to see.


Pretty Pictures of Current and Recent Experiments
Tuesday, July 8, 2003, 8:55AM; posted by stoller (282).

See how your fellow Emulab experimenters are using the testbed on this page of topology pictures.


CD bootable system for running Frisbee
Wednesday, June 18, 2003, 12:41PM; posted by mike (27).

In the Software section, we have added an ISO image that you can download and burn on a CD to give you a hard-diskless environment from which to run the frisbee client or the disk image creation tool. The README has more info.


Frisbee disk loader source released
Saturday, June 14, 2003, 11:05AM; posted by mike (27).

In conjunction with our USENIX paper, we have released the source to the Frisbee disk loader and associated disk imaging tools. See the Software section for details.


Quota changes
Tuesday, May 27, 2003, 12:10PM; posted by newbold (2224).

Due to recent issues with disk space on the disk that holds all the /users directories, we've had to make a change in our quota policy. Quotas in home directories (/users) are now 50MB. Most users are already well under that in their current usage, but some people will need to clean up a bit.

Due to the disk space limitations we're under, our general policy is that /users should be used for your personal configuration information, and a small amount of space for experiment-related storage. Everything else should go in the larger /proj storage volume, where quotas are higher.

If you are over your quota, you'll get an email letting you know about it. The grace period is 7 days to get under the quota before you won't be able to use any more space. Besides deleting files, you may want to compress some of your files, do "make clean" where applicable, or move some of your files to storage at your institution or to one of the /proj directories.

To check your usage, run the "quota" command on ops.emulab.net or on an Emulab node.


List of Emulab-Assisted Publications
Thursday, May 15, 2003, 5:03PM; posted by barb (5927).

There is now a list of papers incorporating research conducted on Emulab/Netbed, via the "Emulab Users" link on the left. There is also a list of classes that have used the Testbed. If you have any additions or corrections, please let us know-- we'd like to keep both lists current.


Emulab Tutorial expanded and updated
Monday, May 12, 2003, 5:00PM; posted by newbold (2224).

Our Emulab Tutorial has recently been updated and expanded. Some changes that may be worth checking out include:

  • A new example that includes the use of LANs.
  • A new example of using loops in ns files, especially for creating LANs.
  • Improved text (and some links) regarding the difference between the "control net" and the "experimental net", and why not to use the control net for your experiments.

We're starting an effort to improve the Emulab documentation, partly based on preliminary results from the Survey. If you have other requests or ideas regarding documentation, please contact Testbed Ops and let us know!


Scheduled experiment halt/swapout
Thursday, May 1, 2003, 11:17AM; posted by stoller (282).

Added the long desired halt/swap event directives. You can now put this in your NS file:

$ns at 2000.0 "$ns halt" (or terminate) or $ns at 2000.0 "$ns swapout"

The first causes the experiment to terminate, the latter causes it to swap out. The units are seconds, as are all "at" statements.

NOTE: You can use halt (terminate) to cancel a batch experiment, but you cannot schedule a swapout.


New version of frisbee disk loader installed
Wednesday, April 9, 2003, 3:32PM; posted by mike (27).

I've installed the latest, greatest Frisbee (our multicast disk image distribution software). Gives us about a 5% improvement in performance, which means a speedup for swapping-in experiments which use custom images. See the ChangeLog for a summary of changes.


Linux image upgraded to Redhat 7.3 (from 7.1)
Tuesday, April 8, 2003, 3:15PM; posted by stoller (282).

The Linux image has finally been upgraded from Redhat 7.1 to Redhat 7.3. Many users had requested a more recent version of Linux, and we finally found someone crazy enough (thanks Kirk!) to take it on.


Testbed News System
Thursday, April 3, 2003, 2:39PM; posted by barb (5927).

Emulab has a new news system; news items less than a week old will show the icon next to their titles, as well as on the navigation bar to the left. As new features are added to the system or important events approach, we'll update the news on this page, so be sure to read new updates!


uky.emulab.net Now Up
Thursday, August 15, 2002, 2:42PM; posted by lepreau (12).

The first external site using our software to run their own Emulab is now up. Other sites are in the process of, or have plans to, bring up their own Emulab. If you're intrested in running your own, contact us!

uky.emulab.net, at the University of Kentucky, will be used primarily for classes, starting this fall.


New Routing Support
Friday, April 19, 2002, 2:43PM; posted by lepreau (12).

Emulab now has much improved routing support which should make setting up routes in your experiments easier than ever! Please see the updated "Setting up IP routing between nodes" section of the Emulab Tutorial.