On Sun, Jun 23, 2013 at 05:29:40AM -0400, Ayal Baron wrote:
----- Original Message -----
On Fri, Jun 21, 2013 at 02:27:39PM +0300, Itamar Heim wrote:
On 06/18/2013 09:29 AM, Arik Hadas wrote:
- Is there a filing for Qemu image handling reported by virt team?
Background about the problem:
As part of the ram snapshots feature (http://wiki.ovirt.org/Features/RAM_Snapshots) we pass a path to file to libvirt, where the memory of the VM should be saved as part of the snapshot creation. the output file is identical to the one that is created to store the memory on hibernate command.
When VM with snapshot(s) that has memory is being exported, we want the snapshot's memory file to be exported to the export domain as well. when trying to export such memory file, we saw that the file is being truncated to the closest size that is a multiple of block size (512). we found that the file is being truncated by qemu-img that is being used to copy the file to the export domain.
We previously thought that it is a problem in qemu - not handling files with size that is not a multiple of block size, and a bug to qemu was opened (bz 970559).
We now understand that the issue described above might be a problem in qemu that needs to be solved, but it is not the problem in our case: treating the memory file as qemu image is wrong - the created file is not a qemu image. the file has a special format: it contains xml part at the beginning and the memory dump as a binary data right after that.
So basically it seems that we need the following things in vdsm:
- The creation of the file that is expected to store the memory as qemu
image seems to be redundant. instead, we need to have a way to create a file in a similar way to 'touch' command - just to verify that the file in the path we pass to libvirt is created with the right permissions. (it's probably true for the hibernation volume creation as well btw).
how would this look for block devices?
- The more important issue is that we need to have a way to export files
which are not qemu images to the export domain, which means without using the qemu-img process, just copy the file.
ayal - anything close to this today - i remember various qemu-img vs. dd patches in the past for copy operations?
Indeed, the problematic qemu-img call was introduced by http://gerrit.ovirt.org/#/c/10979/5/vdsm/storage/image.py
In my opinion, replacing it with "cp" (that implies --sparse=auto) would do the right thing for all combinations of file/block qemu-disk/snapshot-ram-data.
No, for qcow images it would not dedup zeros (and reclaim space where relevant) It would also not be able to collapse images.
The relevant code runs for RAW file format. I.e., no qcow at the source and no chains.