and will take too much work to fix right now.

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.

find the interfaces inside containers.

with this now, but want to get it in before I push new XEN image out.

loc-bstore: local blockstore support
rem-bstore: remote blockstore support

Check for these when a user attaches a blockstore to a local node (local
blockstores), or to a link/lan (remote blockstores).  All nodes in a lan
containing one or more remote blockstores must have an OS with the
remote blockstores feature.

Utah has rewired some of the its pc3000s to a procurve, which supports
vlans > 1024. Since we do not have link features and desires, we need
to trick assign by using a different link type on the wire, in both
the ptop and vtop. The vtop looks for a vlan reserved tag greater then
1024, and changes the linktype to ethernet-highvlan. In ptopgen we
look for an attribute on the switch that says it can do highvlans, and
add that linktype for any wire attached it.

is on a switch.

Doing this required adding columns to the virt and physical blockstores
tables to mark the attributes that will be considered for mapping.
Unmarked entries just flow through to the client-side.

This commit also introduces filesystem support in the form of passing
through a mount point to the client-side.  It is left to the client to
decide what filesystem and fs options to use to setup the space, including
any logical volume aggregation required to support the request.

* Translate bandwidth spec "~" to 10Kbps, and complain if any other value
  is used on a lan with blockstores.

* Allow blockstores to be fixed to nodes.  Shunt through cases where the
  node a blockstore is fixed to isn't a blockstore pseudo-VM via a
  features / desires hack.  We do this to avoid having a more heavyweight
  blockstore pseudo-VM representation show up when users just want more
  local disk space setup on their nodes.

amount a physical has is stored in the node types table, and the
per-vm memory requirement is stored in the nodes table. ptopgen
adds up usage, and subtracts from the total for the ptop file.
The vtop number comes from a virt_node_attribute table, and we
pass this through to the client side. Note that this is less
important for openvz, more so for XEN.

In the NS file:

	tb-set-node-memory-size $node 1024

Number is in MBs. The mapper defaults this to 128 for openvz and 256
for xen. Maximum is hardwired to 256 and 512 respectively. Need to
think about a good way to configure this in.

Clean up some comments and error messages.

Also squash a couple of typos.

Was requiring a VirtExperiment object, for some functions.  Experiment objects,
I think, are preferred, and a VirtExperiment object can be requested from
them.

Clean up and add some comments.

traffic shaping or bw accounting anyway, and Geni users want to be
able to connect to more shared vlans then physical ports.