Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vagrant snapshot restore - should not provision #6752

Closed
jstortz opened this issue Dec 28, 2015 · 39 comments · Fixed by #10490
Closed

vagrant snapshot restore - should not provision #6752

jstortz opened this issue Dec 28, 2015 · 39 comments · Fixed by #10490
Assignees
Milestone

Comments

@jstortz
Copy link

jstortz commented Dec 28, 2015

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
Copy link

nedbat commented Dec 30, 2015

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
Copy link

@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
Copy link

@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
Copy link
Author

jstortz commented Jan 5, 2016

@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
Copy link

Makes sense.

@jtopper
Copy link
Contributor

jtopper commented Jan 16, 2016

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
Copy link

ferventcoder commented Jan 16, 2016

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

@jtopper
Copy link
Contributor

jtopper commented Jan 16, 2016

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
Copy link

ferventcoder commented Jan 16, 2016

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

@ferventcoder
Copy link

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

@jstortz
Copy link
Author

jstortz commented Jan 16, 2016

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
Copy link

yoke88 commented Feb 6, 2016

vagrant suspend and then vagrant resume also run provision

@fhenri
Copy link

fhenri commented Mar 3, 2016

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
Copy link
Contributor

jtopper commented Mar 6, 2016

#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
Copy link
Author

jstortz commented Mar 6, 2016

Consistency is good.

@StefanScherer
Copy link
Contributor

@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. 👍

@fhenri
Copy link

fhenri commented Apr 27, 2016

@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
Copy link
Contributor

jtopper commented May 13, 2016

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
Copy link

fhenri commented Jun 17, 2016

@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
Copy link
Contributor

jtopper commented Jun 17, 2016

@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
Copy link

fhenri commented Jun 17, 2016

@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

@chrisroberts chrisroberts added this to the 1.9 milestone Oct 3, 2016
@fhenri
Copy link

fhenri commented Dec 8, 2016

@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
Copy link

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
Copy link

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

@magicgoose
Copy link

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
Copy link

zofrex commented Sep 24, 2017

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
Copy link

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
Copy link

jeffgreenca commented Mar 5, 2018

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
Copy link

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

@briancain
Copy link
Member

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!

@briancain briancain modified the milestones: Secondary, 2.0.4 Mar 8, 2018
@briancain briancain self-assigned this Mar 8, 2018
@briancain briancain assigned chrisroberts and unassigned briancain Apr 9, 2018
@chrisroberts chrisroberts modified the milestones: 2.0.4, 2.1 Apr 9, 2018
@dragon788
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Member

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

@kaveh-ahmadian
Copy link

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
Copy link

zofrex commented Jul 20, 2018

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
Copy link

@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.

@chrisroberts chrisroberts modified the milestones: 2.1, 2.2 Oct 15, 2018
@Adnn
Copy link

Adnn commented Dec 6, 2018

Preparing to party for the 3 years anniversary !

chrisroberts added a commit to chrisroberts/vagrant that referenced this issue Dec 8, 2018
Both of these commands failed to default the options disabling
the provisioning from ignoring the sentinel file. This resulted
in different behavior than what was seen with the `up` and
`resume` commands which would only provision items with run set
to "always". This defaults the options to proper match the behavior
of `up` and `resume` to be consistent.

This also adds an extra `--no-start` flag to allow users to restore
a snapshot but not start the restored guest immediately.

Fixes hashicorp#6752
@chrisroberts chrisroberts modified the milestones: 2.2, 2.2.3 Dec 8, 2018
@StefanScherer
Copy link
Contributor

Thanks @chrisroberts! looking forward to the next release 🎉

gitebra pushed a commit to gitebra/vagrant that referenced this issue Dec 17, 2018
Both of these commands failed to default the options disabling
the provisioning from ignoring the sentinel file. This resulted
in different behavior than what was seen with the `up` and
`resume` commands which would only provision items with run set
to "always". This defaults the options to proper match the behavior
of `up` and `resume` to be consistent.

This also adds an extra `--no-start` flag to allow users to restore
a snapshot but not start the restored guest immediately.

Fixes hashicorp#6752
@ghost
Copy link

ghost commented Mar 28, 2020

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.

@ghost ghost locked and limited conversation to collaborators Mar 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.