Hi Fam, Stefan,
Thanks for answering.
We use "qemu-img convert" to convert a image in the middle of the chain,
not the active one.
Those images (and the previous ones in the chain) are read-only and
there should be no risk in converting them:
E.g.: for the following chain:
base --> snap1 ---> snap2 ---> snap3 (active)
we do "qemu-img convert" on snap2 (readonly), generating a snap2' with
the same content as snap2.
Then we do the rebase while the VM is suspended to make sure the image
files are reopened.
Please confirm if I'm missing something here.
We are not using block-commit since we want to have more control (keep
the base snapshot unmodified, use compression, etc).
Best regards,
Christopher
On 19-Dec-16 10:55, Stefan Hajnoczi wrote:
On Mon, Dec 19, 2016 at 09:07:43AM +0800, Fam Zheng wrote:
On Sun, 12/18 20:52, Christopher Pereira wrote:
Hi,
We are doing a "qemu-img convert" operation (qcow2, with compression) to
shorten the backing-chain (in the middle of the backing-chain).
In order to force qemu to reopen files, we do a save and restore operation.
Is there a faster way to reopen image files using virsh or qemu?
No, don't use qemu-img when the image is in use by QEMU. You want to use
"block-commit" command provided by QMP.
It's worth being more explicit here:
You will corrupt the image file if you access it with another program
while QEMU is using it!
Stefan
