----- Original Message ----- > On Fri, Jun 21, 2013 at 02:27:39PM +0300, Itamar Heim wrote: > > On 06/18/2013 09:29 AM, Arik Hadas wrote: > > > > > >>- 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. > > > > > >So basically it seems that we need the following things in vdsm: > > > > > >1. The creation of the file that is expected to store the memory as qemu > > >image > > >seems to be redundant. instead, we need to have a way to create a file in > > >a > > >similar way to 'touch' command - just to verify that the file in the path > > >we > > >pass to libvirt is created with the right permissions. (it's probably true > > >for > > >the hibernation volume creation as well btw). > > > > how would this look for block devices? > > > > > > > >2. The more important issue is that we need to have a way to export files > > >which > > >are not qemu images to the export domain, which means without using the > > >qemu-img > > >process, just copy the file. > > > > ayal - anything close to this today - i remember various qemu-img > > vs. dd patches in the past for copy operations? > > Indeed, the problematic qemu-img call was introduced by > http://gerrit.ovirt.org/#/c/10979/5/vdsm/storage/image.py > > In my opinion, replacing it with "cp" (that implies --sparse=auto) would > do the right thing for all combinations of file/block > qemu-disk/snapshot-ram-data.
No, for qcow images it would not dedup zeros (and reclaim space where relevant) It would also not be able to collapse images. > > Regards, > Dan. > _______________________________________________ > vdsm-devel mailing list > vdsm-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
