libvirt users - Sep 2017 - Re: Rollback to running VM

On 9/19/2017 9:56 AM, Martin Kletzander wrote:
> On Tue, Sep 19, 2017 at 01:28:45PM +0000, Jackson, Gary L. wrote:
>>
>> I would like to make a snapshot of a running VM, let it continue to run
>> after the shapshot, and then at some later time roll back the VM to
>> that previous running state. Can I do that with libvirt? If so, how? I
>> understand that this will cause all kinds of havoc with things like
>> ongoing TCP connections, and I accept that risk.
>>
>
> Check `man virsh` and the description to commands `snapshot-create-as`
> and `snapshot-revert`.  If more information is needed, feel free to ask,
> although if deep knowledge is required I might need to rely on someone
> else to reply then.
agreed. This is definitely achievable with snapshot-create-as. You'll
prefer to shutdown the VM to make it work, but it can be done live using
the --running flag. I've never tried this. The man page isnt entirely
clear but it seems like it will effectively reboot to the state when the
snapshot was taken.
 Mechanics wise, you take the snapshot. Now you have a new disk image
file (usually with -snap, but you can name it whatever using
snapshot-as), that will be recording the changes that are happening to
the OS. The old image at the time of the snapshot is still there under
the original name. If you look in the xml file, you'll see it has
changed the path of the disk image to the new snapshot file. The new
snapshot is a 'sparse copy' in that is recording all of the new changes
happening, but it has a reference pointer pointing back to the original
image for things that have not changed. At any point, you can shut down
your VM and boot off the original image, which discards all of the
changes. Or you can decide that you want to 'blockcommit' all of the
changes back to the original image which you can do online without impact.

(I use this with ZFS replication to provide rollback capability per VM
image to another host in case of host failure)

Will snapshot-revert restore the processor and memory state of the VM as it was
at the time of the snapshot?

-- 
Gary Jackson

On 9/19/17, 11:10 AM, "libvirt-users-bounces@redhat.com on behalf of Doug
Hughes" <libvirt-users-bounces@redhat.com on behalf of
doug.hughes@keystonenap.com> wrote:

    
    
    On 9/19/2017 9:56 AM, Martin Kletzander wrote:
    > On Tue, Sep 19, 2017 at 01:28:45PM +0000, Jackson, Gary L. wrote:
    >>
    >> I would like to make a snapshot of a running VM, let it continue to
run
    >> after the shapshot, and then at some later time roll back the VM to
    >> that previous running state. Can I do that with libvirt? If so,
how? I
    >> understand that this will cause all kinds of havoc with things like
    >> ongoing TCP connections, and I accept that risk.
    >>
    >
    > Check `man virsh` and the description to commands `snapshot-create-as`
    > and `snapshot-revert`.  If more information is needed, feel free to
ask,
    > although if deep knowledge is required I might need to rely on someone
    > else to reply then.
    
    agreed. This is definitely achievable with snapshot-create-as. You'll
    prefer to shutdown the VM to make it work, but it can be done live using
    the --running flag. I've never tried this. The man page isnt entirely
    clear but it seems like it will effectively reboot to the state when the
    snapshot was taken.
     Mechanics wise, you take the snapshot. Now you have a new disk image
    file (usually with -snap, but you can name it whatever using
    snapshot-as), that will be recording the changes that are happening to
    the OS. The old image at the time of the snapshot is still there under
    the original name. If you look in the xml file, you'll see it has
    changed the path of the disk image to the new snapshot file. The new
    snapshot is a 'sparse copy' in that is recording all of the new
changes
    happening, but it has a reference pointer pointing back to the original
    image for things that have not changed. At any point, you can shut down
    your VM and boot off the original image, which discards all of the
    changes. Or you can decide that you want to 'blockcommit' all of the
    changes back to the original image which you can do online without impact.
    
    (I use this with ZFS replication to provide rollback capability per VM
    image to another host in case of host failure)