Исправление DALDON, (текущая версия) :
Пока ты мне отвечал, я нагуглил такое:
Therefore, it is important to be able to reduce the length of a backing chain. Qemu exposes at least three options for shortening a backing chain; also, be aware that the options for manipulating a chain while a guest is running differ from the options for manipulating a chain when no guest is using the disk. When shortening a backing chain, the idea is that the guest must continue to see the same information, but that it takes fewer files to represent the information. Qemu's 3 options are:
virsh blockpull: Remove one (or more) backing files, by pulling the content from the backing file into the active file. Limitation: as of qemu 1.6, you can only pull into the active image of an online guest (for offline images, qemu-img you can pull into any image with a rebase command). With this, it is possible to go from:
base <- snap1 <- snap2*
to:
base <- snap2*+^
where the contents of snap1 are now contained in snap2, and where snap2 had metadata rewritten to point to base.
> virsh blockcommit: Modify a deep backing file so that one (or more) intermediate backing files are committed into the base. Limitation: as of qemu 1.6, you cannot commit from the active image of an online guest (for offline images, the qemu-img commit operation can commit, but only through one base file at a time).
То есть, sudo virsh blockpull - будет пахать ТОЛЬКО в онлайне, и тут похоже никуда не деться, рано или поздно, нужно будет делать: blockcommit. И при том, чем позже, тем дольше оно будет делаться, а оно как раз таки требует офлайна.
Исходная версия DALDON, :
Пока ты мне отвечал, я нагуглил такое:
Therefore, it is important to be able to reduce the length of a backing chain. Qemu exposes at least three options for shortening a backing chain; also, be aware that the options for manipulating a chain while a guest is running differ from the options for manipulating a chain when no guest is using the disk. When shortening a backing chain, the idea is that the guest must continue to see the same information, but that it takes fewer files to represent the information. Qemu's 3 options are:
virsh blockpull: Remove one (or more) backing files, by pulling the content from the backing file into the active file. Limitation: as of qemu 1.6, you can only pull into the active image of an online guest (for offline images, qemu-img you can pull into any image with a rebase command). With this, it is possible to go from:
base <- snap1 <- snap2*
to:
base <- snap2*+^
where the contents of snap1 are now contained in snap2, and where snap2 had metadata rewritten to point to base.
virsh blockcommit: Modify a deep backing file so that one (or more) intermediate backing files are committed into the base. Limitation: as of qemu 1.6, you cannot commit from the active image of an online guest (for offline images, the qemu-img commit operation can commit, but only through one base file at a time).
То есть, sudo virsh blockpull - будет пахать ТОЛЬКО в онлайне, и тут похоже никуда не деться, рано или поздно, нужно будет делать: blockcommit. И при том, чем позже, тем дольше оно будет делаться, а оно как раз таки требует офлайна.