Kb290

Emulab FAQ: Using the Testbed: Features and Desires

On a finer granularity than type selection (tb-set-hardware), Emulab also supports features and desires. Features are associated with physical nodes, and indicate special qualities of a node, such as special hardware. Desires are associated with virtual nodes in your NS file, and are requests for features. Unfulfilled desires---that is, desires of a virtual node that are not satisfied by the corresponding features on the mapped physical node---are penalized in the scoring function. Likewise, wasted features---features that exist on a physical node, but were not requested by the virtual node mapped to it---are also penalized.

The chief use of features and desires is to put a premium on scarce hardware. If some nodes have, for example, extra RAM, extra drive space, or higher-speed links, the penalty against using these features if they are not requested will tend to leave them free for use by experimenters who require them. As, an example, consider this NS file fragment:

       set nodew1 [$ns node]
       $nodew1 add-desire pc600wifi 1.0

Other uses are possible as well. Features and desires can be used to prefer nodes that already have a certain set of software loaded. For example, custom operating systems can be loaded, but features can be used to prefer nodes that already have the correct OS loaded, saving the substantial time it would take to load the OS. Or, if some subset of physical resources have been marked as only usable by a certain experimenter (for example, by some sort of advance reservation system), those nodes can be preferred.

Specifying features and desires is easy, since they are represented as arbitrary strings in the input files (like types are). Penalties for wasted features can be intuitively derived. In general, it is sufficient to choose a penalty based on a feature's relative importance to other resources---for example, one may choose to penalize waste of a gigabit interface more than using an extra link (thus preferring to use another link rather than waste the feature), but less than the cost of using an extra node (thus preferring to waste a gigabit interface before choosing to use another node). Weights can be made infinite by setting them 1.0, to indicate that a solution failing to satisfy a desire, or wasting a feature, should not be considered a feasible mapping. This is analogous to a hard vclass.

For the testbed administrator, setting up features requires a little bit of SQL programming. The first example sets up a type feature; one that applies to all nodes of a particular type, and are typically used to penalize certain node types so that they are less likely to be picked if other node type are available.

       mysql> insert into node_type_features values
               ('pc2000', 'pc2000', 0.5);

So, pc2000's will be somewhat penalized unless they are specifically requested, thus attempting to keep them free for people who really need that particular node type.

This next example sets up a feature for a particular node. This kind of feature is used when you have a group of nodes of the same type, but only some of them have the feature, in this case a wifi card.

       mysql> insert into node_features values
               ('pc17', 'pc600wifi', 0.7);

As an administrator, you might use a weight of 0.0 if you had a feature that you wanted users to ask for explicitly, but that you do not care about preserving (ie: the node can be allocated). A weight of 1.0 means that the node should not be picked if the desire was not explicitly requested. In general, the closer to 1.0, the harder assign will try to avoid using a node with the feature. Yes, its a bit of a guessing game, and we recommend 0.5 as a reasonable default.

For a very technical description of how the resource mapper works, please see the SIGCOMM paper.