vagrant snapshot restore - should not provision

[jstortz]

I currently have two issues with the snapshot restore functionality. They may both be simple lack of education, improper workflow, etc., I don't know. I'm looking, but cannot find the answers so far.

The Setup

1. I setup my Vagrantfile, including provisioning to get my machine close to how I need it
2. I vagrant up
3. I make final manual adjustments to get things "just so"
4. I shut the machine down with vagrant halt machineName
5. I use vagrant snapshot save machineName snapshotName and that works great too.
   

   Expectations

When I use vagrant snapshot restore machineName snapshotName there are two things that happen that I did not expect/want:

1. The machine actually boots up. I don't want it to that. I want it to restore and then await further use. I had previously taken the snapshot in a halted state. I expect the restore of the snapshot to put the machine back to the same state it was in when I took the snapshot (a.k.a., halted).
2. Provisioning occurs. I tried adding --no-provision, but that didn't seem to help. The snapshot is exactly how I wanted the machine. The provisioning happened earlier when I did my original vagrant up. I don' want provisioning to occur again.

So I expect I may have different/unusual expectations or lack knowledge of a command line switch to use etc. Anyway, let he debate begin.

Thanks,
Jason

[nedbat]

I also was surprised to see the provisioning happen. I use Virtualbox, and when I restore a snapshot with the GUI (which btw, seems to only be available as an option in the shutdown confirmation dialog box!?), it simply resets the state of the machine. Then "vagrant up" restarts the machine. No provisioning.

Please provide a way to restore snapshots without provisioning.

[ferventcoder]

@mitchellh This is also what I just found. I was looking forward to removing the sahara plugin for this native plugin but it appears that snapshot isn't quite ready for wider use yet?

snapshot has what appears on the surface to be better features than sahara, but running the provisioner should be an explicit after step and not part of the snapshot restore/pop commands.

[ferventcoder]

@jstortz perhaps update the title to something more like vagrant snapshot restore Should Not Provision and create a secondary issue for the machine booting up. I think you have two issues. It seems the more popular and critical issue here is the provisioning.

[jstortz]

@ferventcoder - agreed this is two issues in one. I was just getting a conversation about the new functionality going to see what "intended" functionality was and see if anyone wants to weigh in. Once we get some discussion going perhaps we can create all new issues based on some agreed upon direction from the collective hive.

[ferventcoder]

Makes sense.

[jtopper]

I've created PR #6879 which will allow the --no-provision flag to work with vagrant pop and vagrant restore, since I also don't want to re-run the provisioner on rollback in some use cases.

[ferventcoder]

I think the PR should be the opposite - the default behavior should be NOT to provision.

[jtopper]

Whilst I agree, a PR to do that would be backward-incompatible with the current released behaviour and thus probably wouldn't see the light of day until Vagrant 1.9. (The implementation would also be more complex, since the behaviour of vagrant snapshot restore/pop makes use of the same action as vagrant up and vagrant reload).

[ferventcoder]

That is a completely fair assessment and I agree with the semver boundary.

[ferventcoder]

Too bad it wasn't released as a preview - then it would not have been subject to the boundary.

[jstortz]

Perhaps we can create a choice? We could have an environment variable control the default behavior. So for example, I could set:

export VAGRANT_PROVISION_ON_RESTORE=false

This would be very similar to the variable we set for using VMWare Fusion instead of VirtualBox:

export VAGRANT_DEFAULT_PROVIDER=vmware_fusion

The variable could default to "true", thereby maintaining the current functionality, but allow us to set it to false getting a new default behavior similar to that described by @ferventcoder.

[yoke88]

vagrant suspend and then vagrant resume also run provision

[fhenri]

I was evaluating the snapshot feature for our project and I agree with others that vm should not be booted not provisioned.

@yoke88 vagrant suspend/resume does not run provision, at least not on the VM I am running

[jtopper]

6879 got merged this week, so you should be able to use --no-provision on snapshot restore in the next release.

To @yoke88's point, #7059 looks to add a change to check the provisioning sentinel file when running a vagrant resume which will solve this.

Should we ultimately be doing the same on snapshot restore/pop for the sake of consistency?

[jstortz]

Consistency is good.

[StefanScherer]

@jtopper I've just installed your plugin again as vagrant snap take and vagrant snap rollback is simple to remember and does what I want (no provisioning) and need. :+1:

[fhenri]

@jtopper I have a follow up question, using the --no-provision no provision will be run at all ?

Ideally we should have the same behavior as vagrant up so provision marked to run always will be run and the others will not be run.

[jtopper]

Just a reminder here that the changes added by #6879 aren't yet live - there hasn't been a vagrant release since December.

@fhenri: That's correct, if --no-provision is passed to vagrant pop or vagrant restore, no provisioner will be run. This is consistent with the behaviour of using vagrant up --no-provision

[fhenri]

@jtopper so vagrant had new release including this fix, but regarding provisioning its either all or nothing.

I have use case where I have one-time initial provisioning (set up db, import db, set up app server ...) and then I have provisioning that are run with always attribute (git pull changes and deploy latest changes ...)

I think the expected scenario using the snapshot feature is:

1. set up the box
2. push snapshot
3. pop snapshot with the always provisioning so it is consistent with vagrant up but it does not work as you have vagrant snapshot pop that will run all your provisioning (including the initial one) or vagrant snapshot pop --no-provision that will run no provisioning

[jtopper]

@fhenri so if I'm understanding correctly, you'd like another provisioning option on snapshot pop which will run the provisioners marked as always but none of the others?

[fhenri]

@jtopper actually I am not sure at first place why all provisioning needs to be run when we pop the snapshot, but I understand this is the way it works initially.

could we keep the same consistency as vagrant up:

• if no provision has been run before or if --provision flag is passed, all provisioners are run
• if provision has already been run once and nothing is passed, only the provisioner flagged with run: "always" will fire
• if --no-provision flag is passed, nothing is run at all

[fhenri]

@chrisroberts has there been an update on 1.9 finally ? looking at the changelog it does not seem, I did some tries on 1.9 but it seems it still the same behaviour

[kelbyers]

Is this issue still being used to consider the "booted" part of the initial comment? I find it annoying that restoring a snapshot made of a halted VM results in the VM being booted.

Is that issue still being considered?

[pagnmickie]

I'm curious about this same issue as well. Any changes?

[magicgoose]

This seems still unfixed in Vagrant 1.9.5. Very annoying issue, because one has to manually edit Vagrantfile each time when restoring a snapshot, to prevent re-running provisioning which may be very costly and not intended to be repeated.

[zofrex]

imho this has nothing to do with semver. The behaviour is a bug, it has never (AFAIK) been documented that Vagrant runs provisioners in this situation, so it's not backward-compatibility breaking to change it without a major version bump.

[ottosmittenaar]

When I make a snapshot (vagrant snapshot push) it is to preserve the current state. When I revert back to the previous state (vagrant snapshot pop) I do that to go back to how it was. When I now use vagrant snapshot push without thinking about disabling provision with --no-provision.

I do not have to think about disabling provisioning when I restart the vagrant so I agree with @fhenri and others it is currently not consistent, very confusing and annoying. I just broke my box by going back to the previous state and now all provisioning is running again. This was not the reason to go back and now my snapshot is gone.

Everything else is great ;-)

[jeffgreenca]

I expect a restore snapshot operation to restore the exact state of the snapshot, not apply additional changes.

This is based on my general experience across many tools and platforms. Automatic provisioning was a surprise to me. It looks like there is generally agreement in this thread, but some hesitation about implementing a change.

If the hesitation is due to breaking behavior that vagrant experts expect, perhaps we need to emit a warning message that the behavior will change in the future, paving the way for fixing this "bug". Thoughts?

[ferventcoder]

Paging @briancain - I thought this was set to be flipped to the default for v2. Did that not happen?

[briancain]

Hi @ferventcoder - Doesn't look like it did. I'll put it in the 2.0.4 milestone, which is the next release we're working on. Thanks!

[dragon788]

Perhaps more exciting to me was attempting to use the snapshot functionality with Virtualbox 5.1 on Ubuntu 16.04 and Vagrant 1.9.7 caused crashes in Vboxmanage and after attempting a couple vagrant snapshot push on the same machine and crashing but still being able to vagrant up or vagrant reload it finally corrupted the boot volume forcing me to vagrant destroy and start over. I'm going to test it with Vagrant 2.1.x now to see where things stand.

[dragon788]

With Vagrant 2.1.1 I can save a snapshot with vagrant snapshot push (which turns off/suspends the VM but doesn't restore it to the running state I started from) but when I attempt to restore the vm back to the running state via vagrant snapshot pop it fails all over itself. Will try with Virtualbox-5.2 next and maybe add a couple reboots to see if there might be anything else affecting it, but so far this is nowhere as nice as the behavior of vagrant-sahara I recall from a year or two ago.

[briancain]

Hi @dragon788 - thanks, but please open a new issue if you're experiencing problems with the snapshot command.

[kaveh-ahmadian]

So I don't understand why the default behavior is to run provision and now we have to explicitely specify the --no-provision option when restoring a snapshot. I've been following this issue for a while now and was excited to see it was finally fixed, only to discover it doesn't behave consistently with vagrant up. That command detects that the machine is already provisioned and appropriately skips provisioning. In fact, you have to specify --provision option to force provisioning. Why is this not the same case for the snapshot restore command? I can't think of any common use case where I would want to re-provision after restoring a snapshot. If anything, this would be the exception case, which would be handled by specify the --provision option, consistent with the behavior of vagrant up.

[zofrex]

It looks like this was slated for 2.0.4 and then 2.1 but missed both of those boats - was there an issue with the patch?

[kaveh-ahmadian]

@zofrex the issue is described in detail in my comment above. Basically, the patch fix is inconsistent. Not provisioning on snapshot restoration should be default behavior, rather than having to specify --no-provision flag each time.

[Adnn]

Preparing to party for the 3 years anniversary !

[StefanScherer]

Thanks @chrisroberts! looking forward to the next release 🎉

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.