refactor: Refactor snapshot/migrate functionality to rename to "save" #1555
Conversation
…grate) reword help docs for vm snapshot remove empty append
… save" as a combined state/disk saving mechanism.
…and documentation.
…t should be used rather than creating a new snapshot
|
@sdelliot is it possible to leave the old commands in place for some amount of time (perhaps marked as deprecated)? Renaming the commands will break some functionality in phenix, so if they can't be left in for a little bit then we might want to coordinate some activities. Thoughts? /cc @jacdavi @glattercj |
That totally makes sense to me. I adjusted it so that the old commands still exist but point to the new functionality. So there should no longer be API changes but the underlying functionality will still be modified. I tested it out and it looks like it works as expected. |
There was a problem hiding this comment.
Haven't had a chance to run things yet, but did a quick read through.
One general question, compared to #1540 we're losing the functionality of saving just the disk of a VM. I think that's what we had agreed on previously, but I'm just wondering again if that feature was useful.
| log.Info("Copied existing snapshot file from %s to %s", src, dst) | ||
| return nil | ||
| } | ||
|
|
There was a problem hiding this comment.
I'm a bit confused by this section, but may just be getting things mixed up.
If a user has disk B backed by disk A and calls "snapshot B C" my expectation would be a backing chain of C -> B -> A, but it seems like this will produce C(really A), B -> A which breaks the chain. Is there a reason we want that?
There was a problem hiding this comment.
So this section was largely put in for two reasons.
- The chain of snapshots
C -> B -> Awas not working correctly. I haven't tested now that fix error when rebasing onto no backing image #1557 was merged, but that may have fixed the issue. It also could have been that one of the intermediate images,Bwasn't in the "files" directory. I'll test with the latest changes and see what happens. - The secondary reason is that having a chain of snapshots makes it more difficult for a user to actually capture (save off/compress/etc.) the entire chain. Suppose you have a chain
B->AwhereAis the backing image andBis the running version. Then you snapshot that, we save off the state ofB. Then when you start the experiment again, this method is called and creates a new snapshotCwhich has the chainC->B->A. With this code, rather than creating a newCwe will take a copy ofB. So that if you snapshot again the original case would end up withC->B->A, but this version will end up withB'->AwhereB'isC+B. Basically, instead of creating continually longer chains, you never end up with a chain larger than two.
That's correct. How it was previously implemented, I believe the VM has to be paused to save off the disk, assuming that's correct, there is no loss of functionality as users can just ignore the memory state. If we don't pause a VM and instead used a live migration of just the disk then there would be some loss of functionality. |
This PR accomplishes the primary task of #1540 with the refactoring of
vm snapshotandvm migrate. This includes the following:Breaking Changes
vm migrate->vm savens snapshot->ns savevm configure migration->vm configure stateAdditional Changes
disk snapshotand 2) where there were only internal references but could conflict with "state" where state could be overloaded (e.g.,vm state(BUILDING, RUNNING,...) or the saved VM memory).ns saveoutput.