Hi Kevin, That's the thread I told you about Can you please sound your opinion on this?
Thanks, Arik ----- Original Message ----- > > > ----- 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: > > > > > > > + 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. > > > > > > 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... > _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel