No. Reservations are made by node type not by individual node. For example, you can request one "d430" node but you could not specifically request "pc701".
Since reservations are for a specific node type, you will have to create multiple reservations, one per node type, covering the same time period.
Since reservations are for a specific node type and node types are specific to individual clusters, you will have to create one or more reservations at each cluster covering the same time period.
Reservations start at one hour boundaries and their duration is expressed in hours.
There is currently no limit. This will likely change in the future.
The reservation system will allow you to schedule up to three years in the future, In practice however, you should not reserve nodes out past a year or so, since CloudLab cluster resources may come and go.
A reservation only ensures that at least the specified number of nodes of the indicated type are available for use at the given time. You must explicitly instantiate a profile to use the nodes. If you do not, or if your instantiation uses fewer than the reserved number of nodes, the remaining nodes are unavailable to anyone else outside of your project. Moral: choose your reservation size carefully!
You can edit your reservation as needed before the start time has been reached (see the List Reservations option in the experimentation menu). Be aware that if your reservation has been already been approved, changing it might move it back into the pending state.
No. You will have to create a new reservation that abuts your current reservation. You may however be able to extend experiments started in your reservation window to run past the end of your reservation, if no other reservation is scheduled immediately after yours. The experiment extension page will allow you to extend an experiment up until the point it conflicts with a future reservation for the same node type(s).
No. You must explicitly instantiate a profile within the reservation time period. A reservation only ensures that at least the specified number of nodes of the indicated type are available for use during the given time period.
No. Your experiment will only be forcibly terminated when the experiment duration time is reached. However, it is quite possible that you will not be able to extend an experiment past the reservation end time. It depends on whether there is another reservation for the node resources immediately following yours. The experiment extension page will allow you to extend an experiment up until the point it conflicts with a future reservation for the same node type.
Yes. You do not need to create an explicit reservation in order to use node resources. Instantiating an experiment creates an implicit reservation starting at the current time and extending through the default duration of the experiment. If that time frame conflicts with an existing reservation, the instantiation will fail.
There are a couple of possible reasons. The most common reason is that one or more of the desired node type has suffered hardware failure or was otherwise taken out of service unexpectedly after you made your reservation. It is also possible that the network topology you specify in an experiment cannot be instantiated on the set of nodes that are available when the reservation starts.
As noted in the manual, reservations are tied to a project: any experiment belonging to that project may use the reserved nodes. This makes it possible for another user in the same project to use the nodes you have reserved. This can result in not being to start your experiment or extend an existing experiment. See the manual for a more detailed explantion of "admission control."