(Prerelease 7 beta 2) VM Snapshot and restore

[bmartino1]

Is there a process and place to view the snapshots created and run a snapshot restore?

Edited August 12 by bmartino1

[SimonF]

 

Revert will put VM back to before snapshot.

 

There are options for Block Commit and Pull.

 

[bmartino1]

15 minutes ago, SimonF said:

 

Revert will put VM back to before snapshot.

 

There are options for Block Commit and Pull.

how did you get to that screen?

is the usb manger plugin breking the vm tab?

 

 

or is a separate plugin needed?

Edited August 12 by bmartino1
pictures

[SimonF]

11 minutes ago, bmartino1 said:

how did you get to that screen?

Click on vm name in vm manager view

[bmartino1]

Awesome. Thank You!

[bmartino1]

can we get a clarification on what each options does?

Revert snapshot:
Will restore  xml?

vs

Block Commit / Block Pull

I'm testing with these options atm with a quick setup.

Edited August 12 by bmartino1

[SimonF]

11 minutes ago, bmartino1 said:

can we get a clarification on what each options does?

Revert snapshot:
Will restore  xml?

vs

Block Commit / Block Pull

I'm testing with these options atm with a quick setup.

This should be in the prerelease tread, but there is this post you can review 

Revert will set the VM back to the state before the snapshot.

 

When doing a QEMU snap the changes to the disk are written into an overlay file.

 

Block commit with copy the changes back to the original file and set that disk back to the orignal file name but will have all changes since the snap.

 

Block pull will pull backing data from the original file into the new overlay. The original is a moment in time. Vm will use the new file and not be dependant on backing file.

 

 

 

 

[bmartino1]

On 8/12/2024 at 2:52 PM, SimonF said:

This should be in the prerelease tread, but there is this post you can review 

Revert will set the VM back to the state before the snapshot.

 

When doing a QEMU snap the changes to the disk are written into an overlay file.

 

Block commit with copy the changes back to the original file and set that disk back to the orignal file name but will have all changes since the snap.

 

Block pull will pull backing data from the original file into the new overlay. The original is a moment in time. Vm will use the new file and not be dependant on backing file.

 

 

 

 

the words for commit / pull are confuses even to me as a end user.

I want to know the option that combines them all back into a single vdisk.img file.

revert and pull to me sound the same while different implementations...

I don't want data loss so I would do a block commit if i'm understanding this

 

as i want to copy this vm to another unraid server for production.

Edited August 19 by bmartino1

[bmartino1]

Thank you for this clarfication:
https://wiki.libvirt.org/I_created_an_external_snapshot_but_libvirt_will_not_let_me_delete_or_revert_to_it.html

 

Quote

Revert will set the VM back to the state before the snapshot.

 

When doing a QEMU snap the changes to the disk are written into an overlay file.

 

Block commit with copy the changes back to the original file and set that disk back to the orignal file name but will have all changes since the snap.

 

Block pull will pull backing data from the original file into the new overlay. The original is a moment in time. Vm will use the new file and not be dependant on backing file.

SO yes theses options will vary based on how one made the snapshots...

A block pull is only when the vm is running per wiki documentation:
(so a snapshot while the vm is running could potetnail use block pull)
 

Quote

 

virsh blockpull: Remove one (or more) backing files, by pulling the content from the backing file into the active file. Limitation: as of qemu 1.6, you can only pull into the active image of an online guest (for offline images, qemu-img you can pull into any image with a rebase command). With this, it is possible to go from:

base <- snap1 <- snap2*

to:

base <- snap2*+^

where the contents of snap1 are now contained in snap2, and where snap2 had metadata rewritten to point to base.

 

while Block Commit is only when vm is off.
(so a snapshot when the machien is powered off)
 

Quote

virsh blockcommit: Modify a deep backing file so that one (or more) intermediate backing files are committed into the base. Limitation: as of qemu 1.6, you cannot commit from the active image of an online guest (for offline images, the qemu-img commit operation can commit, but only through one base file at a time). Also, if you commit into a backing file, you invalidate any other qcow2 file that has been based off the same backing file. With this, it is possible to go from:

base <- snap1 <- snap2*

to:

base^ <- snap2*+

so in my case as i powered off the vm and made the snapshots i need teh vm off and run a block commit to make it vdisk1.img and 1 snapshot (the lattest verion that i'm running...)

to fix my share to antoher unraid Vm i will still need to prefrom a virsh block copy to make a new vdisk1 file with the contents of both.
 

Quote

virsh blockcopy: Create a copy of the contents into any other format, and optionally pivot into the copy rather than the original. Limitation: as of qemu 1.6, this operation cannot be restarted, so libvirt 1.1.1 refuses to support this operation for anything except transient domains. With this, it is possible to go from:

base <- snap1 <- snap2*

to:

new^*

where the contents of the entire old chain is now in new. Other destination configurations are also possible, and with a sequence of several operations combined, a user can get back to the original file name with a minimum of data movement between temporary snapshot qcow2 files.

Note that which of the options is fastest will depend on how much the live image has diverged from the point in time where the snapshot was taken. Also note that the resulting file name of w (although qemu is still working on ways to decently expose that information to the user, so your best guess may be based on file sizes or relative length of time between a snapshot creation and your merge operation).

 

[bmartino1]

so with the vm powered off

i made a lattest snapshot default options

and ran block commit. Default --base --top ...

the unrand vm tab:



Now I have 1 vdisk again. YEAH!



not sure if the snapshots need manual deleted but the snapshot files are gone and the system boot to the last snapshot as i wanted.
 

[SimonF]

26 minutes ago, bmartino1 said:

so with the vm powered off

i made a lattest snapshot default options

and ran block commit. Default --base --top ...

the unrand vm tab:



Now I have 1 vdisk again. YEAH!



not sure if the snapshots need manual deleted but the snapshot files are gone and the system boot to the last snapshot as i wanted.
 

How did you run. The VM has to be running to show options in beta2 in next release beta or rc will show when VM is not running and will start in a suspended state to action. If you ran virsh then it would not remove the snapshots from the database also will not remove nvram snaps etc.

 

[SimonF]

49 minutes ago, bmartino1 said:

to fix my share to antoher unraid Vm i will still need to prefrom a virsh block copy to make a new vdisk1 file with the contents of both.

Block commit will do this but VM needs to be running. Block copy is really for migrations to others systems or file locations.

 

Commit copies data from all overlays back into the original img file.

 

Pull pulls data from the backing files into the latest file. So the orginal image is as before the snap and the backing file is a complete image will all the data pulled into it.

 

Block copy is not implemented in the VM Gui.

[bmartino1]

all my VM were off. On Source system The borg to my system BMM-Unraid.

On the borg anytime i wanted to make a snapshot in ubuntu I powered off the VM
clicked the VM name and click create snapshot:

I installed os did something power off VM same way made snapshot Untill i'm a few chains down and have everything the way i want in the VM.

Now I have 4 or so snapshot chains.
I created a snapshot called it before I block commit while the system is off...

then in the list of snapshot click on the recently created snapshot and run block commit option with default on screen

not changing a thing in the menu and click Block Commit


then waited until the action is competed in the window.

What i was left with was a mes of snapshots in teh vm tab but a singla vmdisk1. I booted the VM and it was working with the last edits... ATM I'm copying that file to my unraid to test on another machine...

[bmartino1]

side not to self. Also grab the extra meta data within  /etc/libvirit data when moving new VM with snapshot to a new Unraid System...

vdisk1 has all the data, but i still need to tranfer the qemu VM nvram bios file snapshot data and snapshot db data to teh new unraid system:

I have sucessfully moved the vm after a snapshot block commit to a new unraid system