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:
> >
> >1. 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?
> >
> >2. 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

In my opinion, replacing it with "cp" (that implies --sparse=auto) would
do the right thing for all combinations of file/block

vdsm-devel mailing list

Reply via email to