What is "node state"?
Some experiments have state that is stored exclusively on the nodes
themselves, saved to the local hard drive. This is state that is not
in your NS file and files it references, and which is not preserved in
our database across swapin/swapout. This is state you add to your
machines "by hand" after Emulab sets up your experiment, like files
you add or modify on filesystems local to test nodes. Local node state
does not include any data you store in /users or /proj, since they are
saved on a fileserver, and not on the local nodes.
Most experiments don't have any local node state, and can be swapped
out and in without losing any information. This is highly recommended,
since it is more courteous to other experimenters. It allows you to
easily free up your nodes on request without losing any of the work
you have done on your experiment. Please make your experiments adhere
to this guideline whenever possible.
Wherever possible it is discouraged to have local node state, since
swapping out causes this data to be lost. An experiment that needs
local state should be marked "unswappable" when you create it. If you
must have node state, you can save it before you swap out by creating
a disk image of the node in question, and later reloading it to a new
node after you swap in again. Disk images in effect create a "custom
OS" that can be loaded automatically based on your NS file. More
information about disk images can be found on our Disk Image
page (you must be logged in to use it). We are currently working
on a system that will allow you to save disk images from all the nodes
in your experiment at swapout time, and reload them automatically when
you swap back in.
I just received an email asking me to swap or terminate my
experiment
Emulab has a system for detecting node use, to help achieve more
efficient and fair use of Emulab's limited resources. This system
sends email messages to experiment leaders whose experiments have been
idle for over 24 hours. If you get a message like this, your
experiment has been inactive for too long and should free up the nodes
it has allocated. If the experiment continues to be idle, more
reminders will be sent. On the third reminder and subsequent messages,
your project leader will be one of the recipients. If you feel you
receive the message in error, please respond to Testbed Operations
(testbed-ops@flux.cs.utah.edu) as soon as possible, describing how
you have used your node in the last 24 hours. There are some types of
activity that are difficult to accurately detect, so we'd like to know
how we can improve our activity detection system. Above all, do not
ignore these messages. If you get several reminders and don't
respond, your experiment may be swapped out, potentially causing loss
of some of your work (see "node state" above). If there is a reason
you need to keep your experiment running tell us so we don't
inadvertently cause problems for you.
Someone swapped my experiment!
As described above, we will typically try to contact you about your
idle experiment before we swap it out. However, if the experiment has
been idle for many hours, we may swap it out for you unless you marked
it as "unswappable" when you created your experiment. Because of this,
it is critical that you keep in close contact with us about an
experiment that we may perceive as idle if you want to avoid any loss
of your work.