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