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:
> > > >
> > > >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
> > 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.
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to