Support vagrant 1.8 snapshots

[varac]

Vagrant 1.8 added a feature to make snapshots.

from https://github.com/mitchellh/vagrant/blob/master/CHANGELOG.md:

Snapshots: The vagrant snapshot command can be used to checkpoint and restore point-in-time snapshots.

Using latest vagrant-libvirt release (0.0.32), i get:

--- vms/jessie » vagrant snapshot list  
==> jessie: This provider doesn't support snapshots.
==> jessie: 
==> jessie: This may be intentional or this may be a bug. If this provider
==> jessie: should support snapshots, then please report this as a bug to the
==> jessie: maintainer of the provider.

I'm using sahara for working with snapshots, so this is not urgent, but a feature request.

[shaleh]

Is calling the equivalent of virsh snapshot-create-as myvm snapshot1 "snapshot1 description" sufficient here? Or do we need some kind of Vagrant variable setting which type of snapshot to use.

[infernix]

For the base box this shouldn't be very difficult to implement since it's always qcow2. There are some unanswered questions though for additional disks:

• Should we snapshot additional disk together with the base box snapshot?
• If the answer is maybe, do we want to make that an option for each extra disk? What default value?
• What happens when a snapshot is made for a disk of type raw? Libvirt creates a qcow2 snapshot of it going forward but not at all sure what happens on the next vagrant up in this case.
• Do we sync before snapshotting live outside of whatever libvirt does, and if so, how?
• Do we need to do atomic snapshots, and if that fails, how do we handle failure?

I am also not sure about the difference between snapshot-create-as ... and `snapshot-create-as ... --live. This will need some testing.

[shaleh]

I am trying to imagine a case where I would want the primary disk and secondary disks to not be in sync. Not having much success.

As for the other questions I do not have enough libvirt experience to make a reasonable suggestion.

[infernix]

• Secondary disk is shared
• Secondary disk is part of something like ceph/gluster/other SDS
• Secondary disk contains generated data across multiple test iterations

Probably rare, and likely unexpected based on vagrant snapshotfunctionality description, so we are probably fine with assuming snapshots are for the entire domain, at least initially.

I think we mainly need to test the various disk types and determine if atomic is needed, which I suspect will be with multiple disks. When I have some time, I will play with libvirt snapshotting to better understand it since I never really used it before. We then need to figure out whether if we can use fog or have to talk to libvirt directly.

[tjanez]

@infernix, any progress on this?

[nick4fake]

@infernix Could you point me to the solution? I'd like to help in implementing this.

[pronix]

i though we have it :)

[infernix]

Recent update in libvirt docs explain --live better:

If --live is specified, libvirt takes the snapshot (checkpoint) while the guest is running. Both disk snapshot and domain memory snapshot are taken. This increases the size of the memory image of the external checkpoint. This is currently supported only for external checkpoints.

So the way vagrant describes snapshots as being point-in-time, I think we need to aim for live snapshots, e.g. include memory state.

As far as implementation goes, fog-libvirt does not support snapshots. So we either need to add snapshots to fog-libvirt and then leverage from vagrant-libvirt, or vagrant-libvirt needs to call ruby-libvirt methods directly. Some examples on the latter are in ruby-libvirt-0.7.0/tests/test_domain.rb.

[electrofelix]

For basic snapshotting if someone wishes to test that jedi4ever/sahara#51 works for recent vagrant-libvirt and respond on that ticket it might something for those that don't mind doing a restart of their VM's after rolling back

[varac]

@electrofelix I use jedi4ever/sahara together with vagrant-libvirt and it works nicely for me.

[nick4fake]

Is there any known workaround? Like calling qemu-img manually, etc.