The main goal is that all the shells will have a unified interface for save & restore so that CloudShell can run an orchestration command that saves the entire sandbox.
We need the vCenter to support these two commands:
orcestration_save (mode="shallow", custom_params = null)
orcestration_restore (saved_details)
saved_details{
restore_rules: {
}
saved_location : {
"type": "vm-snapshot"
"identifier": "snapshot01"
"cloud-provider": "vCenter1"
}
custom_params: {
}
}
Notes:
• orchestration-save should return the saved_details json object.
• orchestration-restore takes the same saved_details json and restores the snapshot
• when we call the save_snapshot function internally in orchestration_save we just generate a name - best to use resource_name + timestamp.
Bottom line - we need to create additional connected commands in vCenter which calls the functions (save/restore) already created for snapshots and returns a different value.
The main goal is that all the shells will have a unified interface for save & restore so that CloudShell can run an orchestration command that saves the entire sandbox.
We need the vCenter to support these two commands:
orcestration_save (mode="shallow", custom_params = null)
orcestration_restore (saved_details)
saved_details{
restore_rules: {
}
saved_location : {
"type": "vm-snapshot"
"identifier": "snapshot01"
"cloud-provider": "vCenter1"
}
custom_params: {
}
}
Notes:
• orchestration-save should return the saved_details json object.
• orchestration-restore takes the same saved_details json and restores the snapshot
• when we call the save_snapshot function internally in orchestration_save we just generate a name - best to use resource_name + timestamp.
Bottom line - we need to create additional connected commands in vCenter which calls the functions (save/restore) already created for snapshots and returns a different value.