it’s still possible to use inernal snapshots btw
Dear OpenSource and other communities,
[+] virt-manager is a neat tool to manage virtual machines without having to go thorugh pains such as:
# delete remove vmname (cleanly)
# including its storage columes
virsh destroy vmname 2> /dev/null
virsh undefine vmname
virsh pool-refresh default
virsh vol-delete --pool default vmname.qcow2
[+] what is also great to see CPU RAM DISK NETWORK usage of every vm in an nice overview
so far so good, what is not good
[-] when a clone is created via virt-manager
the user can give it a name, but the resulting new disk file has the name of the original vm.snapshot, why? this is very confusing! what vm does the qcow2 disk file belong to? the orignal or the new clone?
the usual workflow is like this:
- thin (! which should be the default?) provisioning a new virtual harddisk
-
qemu-img create -f qcow2 debian-13-template.qcow2 1024G
-
- create a new virtual machine with virt-manager specifying this disk file
- install the OS
- download script that automates the install of basic tools and config
- making a snapshot after success
- clone the template in order to install more specialized tools software and so on
- making several snapshots after every success
- tidyup once and a while by cloning the disk to a new disk in order to save disk space
- THEN DELETING THE OLD VM
- if there are STILL qcow2 files with the old (original template) vmname the user might delete those too, because the user thinks virt-manager did not delete the old vm, but the user then deletes the cloned (new) vm 🙁 leading to dataloss + precious lifetime lost, having to install all this over again X-D (it could be worse if the original vm was holding unique data)
ALSO why remove the qcow2 extension?
original: debian13-no-gui.qcow2
clone: debian13-no-gui.test <- no qcow2 = confusing
so currently after clone have to remember to manually name the disk files for better overview (anti confuse the situation = prevent dataloss)
but manually renaming qcow2 files also comes with the problems:
- that even when editing the name in virt-manager
- snapshots done to this point will still use the old filename.qcow2 = virt-manager gets confused = can not delete snapshot = can not rename vm
Error deleting snapshot ‘test’: internal error: unable to execute QEMU command ‘block-commit’: Could not open ‘/media/user/nvme3/debian13-no-gui.qcow2’: Permission denied
Traceback (most recent call last):
File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 71, in cb_wrapper
callback(asyncjob, *args, **kwargs)
~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 107, in tmpcb
from github:
du -hs /home/user/vms/kvm/vmnameA*
208K /home/user/vms/kvm/vmnameA.1741610062
931M /home/user/vms/kvm/vmnameA.1741612940
3.6G /home/user/vms/kvm/vmnameA.1741697634 <- a snapshot (but which snapshot? can not tell by that name X-D)
41G /home/user/vms/kvm/vmnameA.qcow2 <- seems to be the original disk image- external snapshot files: recently implemented into libvirt and virt-manager switched to external snapshots as default.
- main reason is that internal snapshots are no longer actively developed in QEMU and they have some limitations
- when user creates a snapshot libvirt will use the snapshot name as suffix to the new files
- however, when user reverts to external snapshot libvirt needs to create new qcow overlay files and in that case it will just use timestamp as the suffix in order to make sure there is no name collision
while someone is on it:
PLEASE also make the list of snapshots in CHRONOLOGICAL ORDER! (also VERY confusing X-D)
liked this article?
- only together we can create a truly free world
- plz support dwaves to keep it up & running!
- (yes the info on the internet is (mostly) free but beer is still not free (still have to work on that))
- really really hate advertisement
- contribute: whenever a solution was found, blog about it for others to find!
- talk about, recommend & link to this blog and articles
- thanks to all who contribute!
