Only works if the image file is readable since mfrisbee protocol doesn't
return this info, at least not right now.

can wreak havoc.c

rules to ensure that the guest cannot change their assigned IP.

on modern linux, instead of our older qdisc hacks.

die. Mostly a workaround, since I do not know why the signal that was
sent is not delivered when mkvnode unblocks them. So, just send the
signal multiple times. Gack. Needs a lot more thought!

Cannot figure out why this happened, but at least don't crash if it
happens again!

Conflicts:
	protogeni/scripts/GNUmakefile.in

All incoming rspecs are now validated with rspeclint.
Multiple Create calls are now permitted.
Slivers now have URNs at allocation time.
Delete now returns a list of ex-slivers.
Advertisement now specifies an operational state machine.
Other minor fixes.

Previously tb-set-node-failure-mode of "nonfatal" only applied to failures
when rebooting a node. If there was an error during the disk reload phase,
the experiment would still fail.

This makes sense, as it is pretty dicey to let a node boot with an unloaded
or partially-loaded disk. But there are situations, such as 500+ node
experiments on PRObE, where it makes sense to not fail the experiment.

What we do if a node fails reload, is to clear the OSIDs and partition info
for the node and then force it to reboot (by setting the state to TBFAILED,
for which there is a REBOOT trigger in stated). This causes the node to come
up and park in pxeboot in the PXEWAIT state. It should remain in this state
across reboots. The user can manually os_load the machine, or do a swap
modify which will force the node to try to reload the original OS.

Since this may not be for everyone, this new allow non-fatal osload failures
requires that the "OsloadFailNonfatal" feature be enabled. This allows the
new behavior to be global, per-group, per-experiment or per-user. The default
is disabled.

Snapshots are done a little differently then openvz of course, since
there are potentially multiple disk partitions and a kernel. The basic
operation is:

1. Fire off reboot_prepare from boss. Changes to reboot_prepare result
   in the guest "halting" insted of rebooting.

2. Fire off the create-image client script, which will take imagezips
   of all of the disks (except the swap partition), and grab a copy of
   the kernel. A new xm.conf file is written, and then the directory
   is first tar'ed and then we imagezip that bundle for upload.

3. When booting a guest, we now look for guest images that are
   packaged in this way, although we still support the older method
   for backwards compatability. All of the disks are restored, and a
   new xm.conf created that points to the new kernel.

can mount the NFS filesystems. Only doing this for shared hosts
at this time, to avoid driving up the number of exports too much.
Might reconsider later.

in the proper reverse map.

of reboot since otherwise the domU just reboots and keeps running.

they do not have to be created at swapin. This is mostly for the
tutorial sessions, where we have dozens of containers launching
at the same time.

Works a lot better!