Am 11.01.2023 um 08:55 hat Zhiyong Ye geschrieben: > Hi Kevin, > > Thank you for your reply and detailed answers. > > In my scenario is the iSCSI SAN environment. The network storage device is > connected to the physical machine via iSCSI, and LVM is used as the middle > layer between the storage device and the VM for storage management and > metadata synchronization. Every VM uses both raw and qcow2 formats, with the > system disk being qcow2 and the data disk being raw. Therefore block devices > need to support snapshot capability in both raw and qcow2 store methods. In > addition, snapshot images should also be stored in iSCSI storage, which is a > block device. > > Both internal and external snapshots can implement snapshots of block > devices, but they both have their drawbacks when multiple snapshots are > required. > > Internal snapshots can only be used in qcow2 format and do not require > additional creation of new block devices. As you said, the block device has > much more space than the virtual disk. There is no telling when disk space > will be full when creating multiple snapshots. > > External snapshots require the creation of additional block devices to store > the overlay images, but it is not clear how much space needs to be created. > If the space is the same as the virtual disk, when there are multiple > snapshots it will be a serious waste of disk space, because each time a new > snapshot is created the previous one will become read-only. However, if the > disk space created is too small, the snapshot data may not be stored when > the disk space is full. > > The problem with both is the uncertainty of the space size of the block > device at the time of creation. Of course, we can rely on lvm's resize > function to dynamically grow the space of the block device. But I think this > is more of a workaround.
Yes, this is why I said it's challenging. oVirt uses resizing of LVs to achieve this, and it's still very complex. You need to decide yourself if you think implementing the management software for this is worth it. > It is mentioned in the Qemu docs page under "QEMU disk image utility" that > the qemu-img rebase can be used to perform a “diff” operation on two disk > images. > > Say that base.img has been cloned as modified.img by copying it, and that > the modified.img guest has run so there are now some changes compared to > base.img. To construct a thin image called diff.qcow2 that contains just the > differences, do: > > qemu-img create -f qcow2 -b modified.img diff.qcow2 > qemu-img rebase -b base.img diff.qcow2 > > At this point, modified.img can be discarded, since base.img + diff.qcow2 > contains the same information. > > Can this “diff” operation be used on snapshots of block devices? The first > snapshot is a copy of the original disk (to save space we can copy only the > data that has already been used), while the subsequent snapshots are based > on the diff of the previous snapshot, so that the space required for the > created block device is known at the time of the snapshot. Yes, you can use raw block devices for both base.img and modified.img. But of course, the result is still a qcow2 file that you need to store somewhere. Kevin
