We tried this 14 or so years ago and it didn't work on FreeBSD 4.7.
But this does work on Linux at least.

A concession to performance. Previously, PXEBOOTING was reported on
the PXE DHCP request and BOOTING on the following OS-originated request.
This is conceptually ideal, as that is what those states were intended
to mean, but it causes two synchronous "reportboot" command executions
from dhcpd for every node boot. Worse, the time gap between the second,
OS-originated DHCP call and the first explicit state reported by the
node itself (e.g., TBSETUP or RELOADSETUP) is generally small enough
that the node reported state often arrived at stated before the BOOTING
state from dhcpd. This can cause excess node reboots or other undesirable
behaviors from stated.

So now we only invoke "reportboot" on the first PXE-originated call and
tell reportboot to send both PXEBOOTING and BOOTING events at that time.
This does not eliminate the race condition above, but makes it unlikely
as there is the whole kernel boot process (10s of seconds) between the
dhcpd state reports and the first node state report.

users yet.

all users. Cloudlab added to the list, but not exposed except to
admins and studly users.

2.68 is installed on FreeBSD 8.x.

is not killed, the image upload will fail, and it takes 30 minutes for
frisbeed to idle exit. We really need to know if the frisbeed process has
any clients for this.

add for VMs, but we were never deleting them and after a while
sshd refuses to start.

Do not remove iscsi startup files in the guest on XEN44.

XEN43-64-STD, but is XEN44-64-BIGFS on APT and probably Cloud.

to a local disk image we were creating a duplicate of the image via
image_import in the project of the experiment. Change LookupByURL() to
notice that the URL refers to a local disk image, and return that image.

the public IP of ops for the mounts.

exported. Does not appear to happen automatically.

We pass through a flag in the tmcd loadinfo call to tell whether to attempt
to do a TRIM when loading the disk (or after loading the disk). If TRIM=1
then we do so.

Since it is not clear from what I have read whether repeated TRIMming is
a detriment to SSD life, we throttle it as follows:

1. We don't TRIM at all unless the sitevariable general/bootdisk_trim_interval
   is non zero. If it is set, we will wait at least that many seconds after
   the previous TRIM before we do it again.

2. We keep track of the last trim via the node_attribute "bootdisk_lasttrim"
   which is a unix timestamp of the last time that tmcd responded to a
   loadinfo request in which it returned TRIM=1.

2. We track, on a per-node basis, whether the boot disk should be TRIMmed
   or not. If the node or node-type attribute "bootdisk_trim" is non-zero,
   we will attempt a trim if the interval has passed since the last trim.

So, we never trim if the sitevariable is 0 (the default value). If it is
non-zero, we only trim the boot disk of those nodes that have the node or
node_type attribute set and only after a sufficient interval has passed.

This does not address non-boot disks, but currently frisbee won't mess
with any other disk anyway. Eventually, we will have to have per-disk or
per-disktype attributes if we want to do this better.

Should be using last rather than next at the end of each "case".