Open mac2net opened 4 months ago
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?
Hi Martin, let's go through this one at a time. Image 1: 2 VMs - one off and one on
For the VM that is on I can save the image where I want
For the image that is off, I don't have that choice.
I see it is called a "Memory File", but it is the snapshot. Cheers Mike
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).
- What is the reason for not directing where a snapshot goes when the VM is off?
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.)
- I did 2 snapshots minutes apart and I see the parent-->child connection but the child snapshot was only about 20% smaller. Can one control whether follow on snaps are unique or a child?
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"?
but the VMs have much more added value and easily backing them up makes Fedora 40 server a big deal!
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.
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: virsh backup-begin
, see https://libvirt.org/kbase/live_full_disk_backup.html
Cockpit has no UI for this.
Libvirt has dedicated operations for backing up a machine:
virsh backup-begin
, see https://libvirt.org/kbase/live_full_disk_backup.html
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.)
Hmm, can you explain your expectations in more detail? Do you want to copy the created snapshot files to some offline storage? Months ago, I moved some VM from one computer to another. I followed the process and it was pretty easy. Also tested out the process for cleaning a VM of sweet nothings security stuff.
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.
My first attempt at testing external snapshots blew up a VM LOL.
Oh! Was that with Cockpit or with virsh
? Can we change anything in Cockpit to prevent this from happening again?
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 virsh backup-begin
. Not sure how I missed it.
FYI, I am developing a website and some videos to show how one can self-host actual business stuff on a MiniPC with Fedora server on the bare metal running VMs. I am working with the MinisForum UM 790 and 780, 64gb ram and 2 x 1TB SSD in software Raid 1. Until now I have mostly been a Mac guy starting inn '86. But, putting aside polemics, Apple doesn't make stuff suitable for self-hosting (to get the same RAM and storage for a Mac mini would cost x3 price) and pushes iCloud stuff for end user backup and syncing as you may know. So you can see why I am interested in backing up VMs.
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