wiki:Internal/Xen

Version 2 (modified by (none), 18 years ago) ( diff )

All these ideas are young and rough (9/28/2006).

http://www.xensource.com

Potential Uses in Scheduling ORBIT

Xen ORBIT can be used to run simultaneous experiments without modifying (what amounts to) the experimenter's API. In theory the Xen host could prevent experiments running in one guest from utilizing the radios at frequencies used by other simultaneous experiments. This may require special support in the device driver, but then we're already putting "regulatory controls" in at the driver level, so in theory we could just define our own regulations for the ORBIT locale.

A particular instance can be stopped, have its Xen image stored somewhere, and be restarted later. More robust scheduling of experiments might therefore be possible. While one experiment is running in a Xen guest, the host of that instance could simultaneously be downloading the image (imagezip or Xen) for the next experiment. This opens up a lot of scheduling flexibility.

Potential Problems

Some of the above features may be difficult to engineer for experiments that use a lot of the grid. It would probably require extremely well-tuned NAS connected to each node, among other things.

Scheduling that starts and stops experiments without the experiment explicitly yielding will probably prohibit some class of experiments. It's unclear which ones will be prohibited.

Simultaneous experiments, or host preparations for the next experiment during the current experiment, mean experiments may no longer run in real time. Granted, there is no hard real time scheduling in the operating systems running on the current nodes, but so long as the nodes are relatively unloaded they will probably run experiments fast enough so that you'll see similar performance as in the sandbox. Delays from the ORBIT scheduler may become intolerable.

There is no clear complete inventory of resources which need to be virtualized. For example, ESSID?

There are broader issues with scheduling ORBIT experiments. There is no way to detect when a particular experiment has failed. Often an experiment that runs on two nodes in a sandbox has significant problems when it hits the grid, and the experimenter needs interactive access.

Note: See TracWiki for help on using the wiki.