GitLab

Also fix for xl toolstack error; teardown called with no XENBUS path,
so no way to find the bridge name. But we know what it is, so add it
to the env so that vif-bridge does not croak.

We were using pygrub to suck the kernel and ramdisk out before
booting the guest, but doing that makes it impossible for for
the guest to change its kernel and reboot.

Other minor fixes.

1. The backend process that starts the XEN vm (xl/xm) was not happy
   with the signal mask settings. By pass that for the vnodeboot call
   so that xl/xm sees a clean mask. The sympton was processes getting
   left behind.

2. Watch for a XEN container being rebooted from inside, by waiting a
   little bit to see if comes back on its own. We used to fold right
   away, but now keep running.

As of FreeBSD 9, the race condition in mountd has been addressed.
We automatically (based on the OS running) add the option to mountd (-S)
as part of ops-install. There is also a configuration variable, NFSRACY,
that we auto-detect and set in elabinelab setup. For regular installs,
you need to set this manually in the defs-* file. Note that the setting
in the defs file does not affect very much. It is passed to the client-side
which uses it in one copy function (used as a fall back for getting the
topology file).

There are still a couple of places in the Emulab code where handling
the race condition is hardwired into the code (most notably, imagezip).
These remain.

The -n option says to turn off the log file. We do not want to store
thes on the XEN host, will take too much room.

The -C option adds a circular buffer to store the last 8K of output
from the console. When a new client connects, dump the contents of
the circ buffer so the user sees context. At this point no longer
save output. When the user disconnects, start saving the output again
in the buffer, to dump at the next connection.

trying to start the testbed.

info from the capture process we now start for each VM. Capture
cannot do this directly, since experimental nodes cannot talk
to the capserver.

We need lock/unlock to atomically check quotas.
The explicit IsUnlimited, SetUnlimited methods are to avoid a potentially
ambiguous convention (is no quota, unlimited? is a zero quota unlimited?)

Add a swapout-time triggered program agent that does a "rc.storage fullreset"
to ensure that the client has unmounted and detached from SAN volumes.
Eventsys shutdown (which triggers the swapout event sequence) is done before
VLAN teardown so this works.

Right now it is just full of comments about what should be checked.

Note that we don't actually have an install target for FreeNAS, so this
file mostly serves as a reminder that we must overwrite the FreeBSD version
of rc.kname on freenas.

In parse-ns, we generate a list of accessible blockstores and put that in
the .input file. The accessiblity check right now is just that the blockstore
(actually lease) pid must match that of the experiment. This needs to be
generalized.

The blockstore set-lease command verifies that the asked-for lease matches
one of those accessible blockstores. If it does, it make sure the correct
size and other info wind up in the virt_blockstores table. Less obviously,
but of critical importance, it emits a "lease" virt_blockstore_attribute
with the correct lease index. This attributes gets converted into the
desire that is added by vtopgen to the .vtop file.

Quite simple actually. In ptopgen we add all persistent stores, which
are identified by having a non-zero lease_idx. To ensure they are only
matched up with the correct virt_blockstore, we add a feature "bs-lease-NN"
where NN is the unique lease index with weight 1.0.

In vtopgen, when a request is made to map a persistent store, we first
verify that the experiment pid matches that of the blockstore's lease
(this is a fer-now simple check which is actually redundant as we make
this check in the parser too) and ensure that the blockstore is not already
mapped (indicated by the blockstore_state entry having size==0) and then
we emit an entry with desire "bs-lease-NN" and weight 1.0.

Most of the file changes were actually to get the "preassign" flag to
vtopgen forwarded into the various libvtop modules so that I can check it
and not perform the permission/size check if it is set.

This is a bit hacky as noted in the comment:

               * XXX we only put out the PERSIST flag if it is set.
               * Since the client-side is stupid-picky about unknown
               * attributes, this will cause an older client to fail
               * when the attribute is passed. Believe it or not,
               * that is a good thing! This will cause an older
               * client to fail if presented with a persistent
               * blockstore. If it did not fail, the client would
               * proceed to unconditionally create a filesystem on
               * the blockstore, wiping out what was previously
               * there.

This specifies what types of bstores are allowed to be allocated from
the space. Currently, just used to isolate datasets to one particular pool.

Move the command execution and storage-related stuff from
libvnode to libfreenas. The interface and vlan stuff is still in
libvnode since it is currently the only one that uses it.

We don't want to alloc/dealloc them on vnode setup.

Right now, libfreenas.pm is largely a duplication of libvnode_freenas.
The two need to be refactored.

Also, provide the server to bscontrol since we know what it is.

approvelease is the place where storage actually gets allocated for
a lease. It uses bscontrol to contact an appropriate freeNAS storage
server and allocate a ZFS volume.

deletelease is the place where storage is deallocated. Note that once
a lease has been approved and storage allocated, it cannot be returned
to the unapproved state. The only way to free storage is to delete the
lease.

Both approve and delete use an intermediate state, "initializing", to
signal that the lease is in the middle of a potentially time-consuming
allocation/deallocation procedure. I probably should have just used the
lease locking mechanism instead.

Approve, delete, and mod all DO use the locking mechanism when examining
and manipulating the state of a lease. Nonetheless, I am sure that are
still plenty of races.