[SOLVED] How works VM snapshots in PVE?

[squirell]

Hi!

Please tell me how works VM snapshots in PVE?

1. I create snapshot (disk type qcow2), do some changes on disk, and snapshot size - 0 (screenshot).
2. How creates RAW-image snapshot (backend ext4) during backup VM with type "snapshot"?

 

[Stefan_R]

1. I create snapshot (disk type qcow2), do some changes on disk, and snapshot size - 0 (screenshot).

Hm, this might be a visual bug? What happens if you do a rollback, is the data correct afterwards? Snapshots created via PVE should really always be viewed from PVE itself, as we include some snapshot metadata in the VM config as well, not just the disk image, but still, this probably shouldn't just show 0...

2. How creates RAW-image snapshot (backend ext4) during backup VM with type "snapshot"?

Backup mode "snapshot" only refers to snapshot semantics (i.e. the data will be backed up as it is when the backup starts, any data written during the backup will not be visible in it, thus the backup will be consistent). There is no actual file system or disk "snapshot" taken, it all happens internally in QEMU (more technically speaking, data is written to the backup in a copy-before-write manner).

 

[squirell]

Hm, this might be a visual bug? What happens if you do a rollback, is the data correct afterwards? Snapshots created via PVE should really always be viewed from PVE itself, as we include some snapshot metadata in the VM config as well, not just the disk image, but still, this probably shouldn't just show 0...

I try rollback and all ok (VM start normally).

qemu monitor:

# info block
drive-scsi0 (#block104): /var/lib/vz/images/104/vm-104-disk-0.qcow2 (qcow2)
    Attached to:      scsi0
    Cache mode:       writeback, direct
    Detect zeroes:    on

# info snapshots
List of snapshots present on all disks:
ID        TAG               VM SIZE                DATE     VM CLOCK     ICOUNT
--        s1                    0 B 2021-06-15 14:14:07672:10:45.445

Backup mode "snapshot" only refers to snapshot semantics (i.e. the data will be backed up as it is when the backup starts, any data written during the backup will not be visible in it, thus the backup will be consistent). There is no actual file system or disk "snapshot" taken, it all happens internally in QEMU (more technically speaking, data is written to the backup in a copy-before-write manner).

Thank you.
Can you give link to qemu documentation, which describe this technology? I know about block-stream and block-commit, but PVE don't use them by backup.

 

[Stefan_R]

Thank you.
Can you give link to qemu documentation, which describe this technology? I know about block-stream and block-commit, but PVE don't use them by backup.

We use a custom 'backup' QMP command and apply a bunch of custom patches to our QEMU build to make it work with VMA and PBS. Check our git repository for the code, there's not a lot of docs on the internal interface I'm afraid, as backups are usually managed via the 'vzdump' utility and not directly via QEMU.

 

[squirell]

We use a custom 'backup' QMP command and apply a bunch of custom patches to our QEMU build to make it work with VMA and PBS. Check our git repository for the code, there's not a lot of docs on the internal interface I'm afraid, as backups are usually managed via the 'vzdump' utility and not directly via QEMU.

thank you for link to the repository.

Can you tell where is the file, which describe in string (qemu monitor):

Backup file: /dev/fdname/backup

This file no such in /dev tree during backup

 

[Stefan_R]

/dev/fdname/backup is a special path indicating to QEMU that it should use it's "named file descriptor" subsystem to access the output stream.

See:
https://git.proxmox.com/?p=pve-qemu...b687e3cac350d75cb1d8b7681ba3957b6e92b9a#l1223
https://git.proxmox.com/?p=qemu-ser...f5274f55eeb61dfe143e93e23734a603;hb=HEAD#l694