Hi T Masteen,
first of all, I'm afraid there is no such document around providing additional context on that topic.
I consider this a good opportunity to be picked up for a future IBM RedBook project, though.
With regards to your questions:
Apparently, you have mixed parameters for both satask stopnode and svctask stopsystem commands.
Let me try to sort this a bit:
- reboot and warmstart are arguments of Service Assistant CLI
satask stopnode
- reset is an argument for management CLI
svctask stopsystem
I'd like to emphasize the difference between both commands and their contexts.
Clustered system commands, those with (optional) prefix svctask, are graceful commands, which will check for redundancy and prevent the user from inadvertently causing unwanted impact.
Service Assistant commands (prefix satask) however, will act straigth away regardless of any potential impact, as for instance vdisks which would go offline for depending on the node to be rebooted.
satask commands do require superuser privileges for a good reason, they should be used with appropriate precaution thus.
For the different effects of the commands:
satask stopnode -reboot: immediately instigates a node reboot, preceeded by a graceful shutdown (from the node OS perspective), but not graceful to in-flight I/Os. satask stopnode -warmstart: immediately kicks of a restart of the I/O process, say: the Storage Virtualize software portion in charge of handling the I/O will be restarted. Although this procedure takes less than a minute, ongoing I/O may not be finished gracefullysvctask stopsystem -node -reset: the graceful variant of a node warmstart. As all other management tasks (svctask), this is a graceful operation. In-flight I/Os will be finished, no new I/Os will be accepted.svctask stopsystem -node -enterservicestate: the graceful way to put a node into service state. This can be used, for instance, to then trigger a node reboot by satask stopnode -reboot command.