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. Regards, Dan. _______________________________________________ vdsm-devel mailing list firstname.lastname@example.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel