----- Original Message -----
On Sun, Jun 23, 2013 at 06:24:50AM -0400, Ayal Baron wrote:
----- Original Message -----
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.
This is a file created by qemu/libvirt and represents part of the VM. If that is not a qemu image then I'm not sure what is.
The file is created by libvirt, concatenating VM memory dump to its metadata. That something else to the qemu disk images which qemu-img was designed for (and named after).
A raw file is a raw file, the data inside it is irrelevant. This is part of the VM. qemu-img was also not originally designed for block devices, nor was qemu...