On Sun, Jun 23, 2013 at 04:44:19AM -0400, Ayal Baron wrote:
> 
> 
> ----- Original Message -----
> > 
> > ----- Original Message -----
> > > VDSM sync meeting Monday June 17th 2013
> > > =======================================
> > > 
> > > - Dan requests reviews for pending patches from Mei Liu and himself (
> > >   http://gerrit.ovirt.org/#/c/15356/8 ) for mom.
> > > 
> > > - Toni to fix the problem with Mark's patch that Dan reviewed so that it
> > > can
> > >   be merged together with the smaller following patches.
> > > 
> > > - Federico has three high priority patches for features and two lower
> > > priority
> > >   ones that need reviews in order to make it for the release deadline. 
> > > They
> > >   are
> > >   related to disk extension and image upload/download (glance):
> > >   + http://gerrit.ovirt.org/#/c/15442 - constants: unify the BLANK_UUID
> > >   def...
> > >   + http://gerrit.ovirt.org/#/c/14589 - volume: add the BLOCK_SIZE 
> > > constant
> > >   +1
> > >   + http://gerrit.ovirt.org/#/c/14590 - volume: add the extendVolumeSize
> > >   method
> > >   + http://gerrit.ovirt.org/#/c/15614 - vm: add the live diskSizeExtend
> > >   method +1
> > >   + http://gerrit.ovirt.org/#/c/14955 - image: add support to
> > >   upload/download
> > >   images
> > > 
> > > - Adam and others to review Gluster patches:
> > >   + http://gerrit.ovirt.org/#/c/13785/
> > >   + http://gerrit.ovirt.org/#/c/11094/
> > > 
> > > - 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.
> 
> This is not correct.
> qemu-img is a utility to manage images.

And here, we are trying to use it to copy something that is not a qemu
image.

> There is no format limitation on images, and the content of this file/device 
> is no exception and no reason to treat it as one.  This is a raw device/file, 
> we don't and shouldn't care about whether it has xml, compression, 
> encryption, qcow, whatever.
> This is an image we pass to libvirt to use in order to dump the memory.
> qemu-img manages raw files/devices and is used to keep sparseness, dedup 
> zeros, etc.

It should not be hard to fix qemu-img to work with binary files of any
length. The only question is whether handling non-qemu-images is the
job for qemu-img.

Dan.
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to