A resource manager (RM) is a PVM task responsible for making task and host scheduling (placement) decisions. The resource manager interface was introduced in version 3.3. The simple schedulers embedded in the pvmd handle many common conditions, but require the user to explicitly place program components in order to get the maximum efficiency. Using knowledge not available to the pvmds, such as host load averages, a RM can make more informed decisions automatically. For example, when spawning a task, it could pick the host in order to balance the computing load. Or, when reconfiguring the virtual machine, the RM could interact with an external queuing system to allocate a new host.
The number of RMs registered can vary from one for an entire virtual machine to one per pvmd. The RM running on the master host (where the master pvmd runs) manages any slave pvmds that don't have their own RMs. A task connecting anonymously to a virtual machine is assigned the default RM of the pvmd to which it connects. A task spawned from within the system inherits the RM of its parent task.
If a task has a RM assigned to it, service requests from the task to its pvmd are routed to the RM instead. Messages from the following libpvm functions are intercepted:
------------------------------------------------ Libpvm function Default Message RM Message ------------------------------------------------ pvm_addhost() TM_ADDHOST SM_ADDHOST pvm_delhost() TM_DELHOST SM_DELHOST pvm_spawn() TM_SPAWN SM_SPAWN ------------------------------------------------
Queries also go to the RM, since it presumably knows more about the state of the virtual machine:
------------------------------------------------ Libpvm function Default Message RM Message ------------------------------------------------ pvm_config() TM_CONFIG SM_CONFIG pvm_notify() TM_NOTIFY SM_NOTIFY pvm_task() TM_TASK SM_TASK ------------------------------------------------
The call to register a task as a RM (pvm_reg_rm()) is also redirected if RM is already running. In this way the existing RM learns of the new one, and can grant or refuse the request to register.
Using messages SM_EXEC and SM_ADD, the RM can directly command the pvmds to start tasks or reconfigure the virtual machine. On receiving acknowledgement for the commands, it replies to the client task. The RM is free to interpret service request parameters in any way it wishes. For example, the architecture class given to pvm_spawn() could be used to distinguish hosts by memory size or CPU speed.