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
> 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.
vdsm-devel mailing list