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:
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.