cloning a VM with all snapshots

[j_s]

I have a VM that has 13 snapshots in my qcow2 file. While unintentional, I want to conduct a few performance tests without potential consequences to the production VM. For the tests I want all of the snapshots to remain. Per my reading, I did this with the command:

qm clone 116 334 --full true

The VM is off, and the VM is stored on an NFS share on a TrueNAS with all-SSD storage. The networking itself is all 10Gb.

The qm clone command does its thing and goes up to 100%, then throws this error:

command '/usr/bin/qemu-img info '--output=json' /mnt/pve/sandisk_ssd/images/334/vm-334-disk-0.qcow2' failed: got timeout
could not parse qemu-img info command output for '/mnt/pve/sandisk_ssd/images/334/vm-334-disk-0.qcow2' - malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "(end of string)") at /usr/share/perl5/PVE/Storage/Plugin.pm line 969.

I tried running the qemu-img command that allegedly timed out, and it responded within 1 second with the output. The VM seems to exist in the WebGUI of proxmox, but there are no snapshots listed. Kind of wondering what the next steps are, or if I can change the timeout. For my test, it is important that I keep all of the snapshots.

Any ideas?

When in production, the VM performs fine. Creation and destruction of snapshots is slow, but does work. I did have to change the timeout to 2 hours for snapshot deletion in the file /usr/share/perl5/PVE/QMPClient.pm.

Thanks!

 

[dakralex]

Hey there!

Unfortunately I couldn't reproduce the timeout error you got. Could I ask you what version of Proxmox VE you are using and how large the qcow2 file of the original VM was and how long it (approximately) took to clone it with qm clone <vmid> <newid> --full true?

In general and AFAIK, I want to point out that you cannot copy all of the snapshots with qm clone. It's intended usage is to allow the cloning of a VM with the current or a specific snapshot, but not all of them.

If you really want to clone a VM completely with snapshots, then you could do the following workaround (Do this at your own risk):

1. Go to the directory on your NAS share, where the VM's qcow2 file is located (usually called `images`) and copy the whole directory and rename the files accordingly to the new VM's id (you may need to use send for zfs, or something else depending on your filesystem and configuration).

$ mkdir 334/ && cp -v 116/* 334/
$ cd 334/ && rename '/s/^vm-116/vm-334/' vm-116-*

2. Go to the directory where the configuration file is located (i.e. `/etc/pve/qemu-server`) and clone the configuration file of the original VM. As we renamed the paths, we must replace them to match the new paths. It would also be helpful to replace the new VM's name.

$ sed -e 's/116/334/g' -e 's/oldname/newname/g' 116.conf > 334.conf

 

[j_s]

Sorry, I basically gave up and moved in a different direction. I made a new VM, then edited the conf file as appropriate and manually did a copy of the .qcow2 file. I had no intention of running the VM, just removing snapshots for an experiment for a followup for this thread:

https://forum.proxmox.com/threads/deleting-snapshots-from-qcow2.141054/

I should be posting the results in the next 48 hours. It was very interesting to do this test, and I think the results will at least be unexpected.

 

[Kingneutron]

I think backing up a VM with all snapshots and then restoring it with a different VMID and Unique checked √ might do the trick, but haven't tested this

 

[dakralex]

The "Snapshots" functionality works on the guest-level, so usually they are not transferred by clones or backups. It is possible to create backups of the current state (by default) or specify a specific snapshot you want to make a backup of.

I think backing up a VM with all snapshots and then restoring it with a different VMID and Unique checked √ might do the trick, but haven't tested this

The backups done of a VM with vzdump do not contain the snapshots of the guest, so when restoring it, it won't contain the snapshots of the other. The "Unique" checkbox is only to auto-generate options that should be guest-specific, e.g. the MAC address of the network interface.

 

[Kingneutron]

vzdump doesn't do the snapshots?! That could be a problem from a DR perspective - i.e. if we restore then we don't have exactly the same environment as before

 

[dakralex]

vzdump doesn't do the snapshots?! That could be a problem from a DR perspective - i.e. if we restore then we don't have exactly the same environment as before

I see where you come from, but there are a few intricacies to make the backup format storage-independent, as each storage type does snapshots differently. That is why it's recommended to use backups for disaster recovery in the long term. But you can always rsync the qcow2 files for backup so that the created snapshots remain after e.g. a disk failure.

FYI, you can look here for some information why the decision about the backup format was taken.