(Click to open topic with navigation)
AGGREGATENODEFEATURES causes Moab to aggregate features reported by the different RMs. For example, if you have two RMs reporting different features for the same node, Moab will add both features together (instead of one being overwritten by the other).
In order to set features manually, you can use mnodectl -m features (for details, see mnodectl).
|ALLOWINFINITEJOBS||ALLOWINFINITEJOBS allows infinite wallclock times to be accepted. Previously, jobs with infinite job times were allowed by default.|
|ALLOWMULTICOMPUTE||ALLOWMULTICOMPUTE tells Moab how to resolve conflicting information from different resource managers. If ALLOWMULTICOMPUTE is specified, Moab will use the STATE and OS information from the resource manager that reports the node as online.|
|DISABLEPERJOBNODESETS||Disables a job's ability to override the system specified node set. See 13.3 Resource Manager Extensions for more information.|
|DISABLEPARTIALNODERESERVATIONS||Blocks partial node reservations.|
|ENFORCERESERVEDNODES||Without this flag Moab tries to optimize the reservation for a job before it starts, meaning a job may start on nodes that weren't part of its reservation. With this flag Moab tries to start jobs only on the nodes that were reserved.|
|ENFORCESAMENODESET||The same node set is not enforced across job requirements by default, rather each requirement is scheduled separately and the node sets are determined on a per-req basis. To have Moab enforce the same node set across all job requirements set this flag.|
|FASTGROUPLOOKUP||Moab will use the system call getgrouplist to gather group information. This can significantly improve performance on some LDAP systems.|
Speeds up start time if there are existing reservations.
FASTRSVSTARTUP is incompatible with partial node reservations.
On very large systems, if there is a reservation in the checkpoint file on all the nodes, it would take a really long time for Moab to start up. For every node in the reservation, Moab checks every other node. With this flag, Moab just uses the nodelist that was checkpointed to create the reservation. It speeds up the startup process because it doesn't have to check every node. Where Moab would take 8 - 10 minutes to start up with an 18,000 node reservation without the flag, Moab can start up in 2-3 minutes with the flag.
With the flag you will see one difference in checknode. A reservation that uses all the procs on a node initially shows that all the procs are blocked. Without the flag, and as jobs fill on the node, the blocked resources will be configured - dedicated (ex. 5/6). With the flag, the blocked resources will always be what the reservation is blocking and won't change when jobs fill on the node.
When you set the FASTRVSSTARTUP flag, Moab will also set the DISABLEPARTIALNODERESERVATIONS flag.
|FILELOCKHA||This is a High Availability feature. FILELOCKHA prevents scheduling conflicts between multiple Moab servers.|
|IGNOREPIDFILELOCK||Moab will not fail if it cannot get a lock on the .moab.pid file. This is useful when Moab is running on a shared file system where file locking can be unpredictable.|
|JOBSUSERSVWALLTIME||Allows jobs submitted without a walltime request or default walltime received from a class or queue but with an ADVRES:reservation to inherit their walltime limit from the reservation instead of the Moab default. The job walltime limit is then the remaining time of the reservation to which the job was submitted.|
|NOCLASSUPDATE||While running against TORQUE, Moab will not update classes when it refreshes each iteration. Moab loads the classes at startup, but does not refresh them until the next time it is restarted.|
Instructs Moab to normalize all tasks that it receives via an mshow -a command. Moab normalizes the task definition to one processor and then changes the tasks requested to the number of processors requested. For example, when the following is received by Moab:
mshow -a -w mintasks=1@procs:4+mem:4096
It is changed to this:
mshow -a -w mintasks=4@procs:1+,mem:1024,tpn=4
|NOVMDESTROYDEPENDENCIES||The destroy job a in cloud workflow does not have any dependencies, allowing it to run whenever you cancel the service. For more information about destroy jobs, see DESTROYTEMPLATE and Creating a cloud workflow.|
|OPTIMIZEDBACKFILL||On large systems that utilize system-wide reservations, backfill can take a considerable amount of time. This flag speeds up backfill scheduling by using an alternative BETA backfill algorithm. This flag will be the default in future versions of Moab.|
Causes Moab to put reservations on untracked VMs (VMs that are created outside of Moab) so that the untracked VMs are visible when you use checkjob, mshow, checknode, etc. commands. These reservations are updated each new iteration, so if the VM is migrated or modified outside of Moab, the reservation will accordingly adjust automatically.
The reservations are not checkpointed. The system re-creates them when you restart Moab (new reservation IDs, etc.). If a VM tracking job appears for the VM, then the reservation will be removed.
This scheduler flag is highly recommended for Cloud users. For more information, see About workload-driven cloud services.
|SHOWREQUESTEDPROCS||Shows requested processors regardless of NodeAccessPolicy in showq. When SINGLEJOB NODEACCESSPOLICY is used and the job requests one processor, showq displays the job with one processor.|
|SHOWUSERJOBSONLY||Causes Moab, when a non-admin user runs showq, to return only that user's jobs. If an administrator runs showq when this flag is set,Moab returns the jobs of all users; no restrictions are placed on administrators.|
|STRICTSPOOLDIRPERMISSIONS||Enforces at least a 511 permission on the Moab spool directory.|
|UNMIGRATEONDEFER||Forces Moab to unmigrate a job if it enters a deferred state.|