-
Notifications
You must be signed in to change notification settings - Fork 75
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
Snapshot UI feedback #1589
Comments
Sorry for the lack of response, we are a bit understaffed here. @mvollmer you recently looked a lot into snapshots, and may be able to answer?
|
No, it's really the "memory file", i.e. the file where the RAM gets written to. When the VM is off, then there is no memory to snapshot. The disk snapshots go somewhere else (libvirt determines the paths by itself). |
As @martinpitt has said, the "Memory file" is only used to store the contents of the RAM of the virtual machine. With the older snapshot format, the user didn't get a choice over this, but with the newer one they get. They also get a choice over where to store the snapshot of each individual disk (I think), and whether or not to snapshot a disk at all. One could argue that Cockpit shouldn't expose only half of this configurability. (Cockpit would silently use a reasonable default for the --memspec option, and hide the full complexity behind a tab or checkbox, or not offer it at all.)
You can't control the child/parent relationships directly. If you want a snapshot to be a child of a specific snapshot, you need to revert the VM first to that snapshot, use it a bit, and when you then take a new snapshot, it will be a child of the first. The snapshot that will be the parent of a new snapshot is the one with the green checkmark in the list. How did you measure the size of a snapshot? By looking at the two "Memory files"? |
Were you not able to do that before? Cockpit could make snapshots of VMs since version 225, released in 2020. |
Perhaps I was mistaken but I thought the snapshots were previous stored internally as a rollback but the VM had to be functional. External snapshots are a backup. |
Hmm, can you explain your expectations in more detail? Do you want to copy the created snapshot files to some offline storage? That is likely tricky since the files all interact with each other in complicated ways and can't easily be separated. Internal snapshots might actually be easier when trying to do backups. Libvirt has dedicated operations for backing up a machine: Cockpit has no UI for this. |
Ah, I think I get it! :-) That page actually talks about using external snapshots to perform a backup, but it's very low level and I think if you want to follow that approach you should be doing it all on the command line, very very carefully. (For example, I think the documented approach only really works as written when there aren't any snapshots yet. I was thinking of using "qemu-img convert -l snapshot-name" to extract the disk image corresponding to a snapshot, which I find to be easier to understand than digging into how external snapshots actually create overlays and I have to look at the base image instead of the file created by the snapshot, etc.) |
And yes, while I am backing up the stuff inside the VM, being able to periodically backup a VM to remote storage is part of the plan. My first attempt at testing external snapshots blew up a VM LOL. Now that I have more info I will try again. I will test with the VM turned off using Cockpit and the command line. |
Oh! Was that with Cockpit or with |
Nothing to learn from that. I was trying to figure out how it worked without understanding how it worked. I also messed around with the virsh CLI. I didn't find
|
Hi Cockpit-machines team
I have been following the discussions on the new snapshot feature and now that I have updated to Fedora 40 server on the metal, I have some feedback questions. If the answer is look it up on libvirt/virsh please tell me.
My questions are as follows:
IMO external snapshots are a big new feature. My Fedora 40 server on the metal has minimal customisation which can easily be regenerated, but the VMs have much more added value and easily backing them up makes Fedora 40 server a big deal!
Cheers
Mac
The text was updated successfully, but these errors were encountered: