Am 24.06.2013 um 11:50 hat Arik Hadas geschrieben:
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 ----- > [...] > > - 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.
Not everything that is part of a VM is an image - or to be more specific for you: a disk image. I think the content we're talking about is really VM state here, not the content of some disk.
qemu-img is clearly meant as a tool for managing disk images (it even calls itself "QEMU disk image utility" in the --help output). Using it for anything else is abuse.
I haven't closed the bug against qemu yet because I think there may in theory be some device that doesn't require that the image size is a multiple of 512, so I'm considering to patch this in order to make it work. This is of course not an urgent bug fix, but a feature extension for a very theoretical case with low priority.
But even if it worked eventually, it would be wrong for you to use it for copying arbitrary files. You should really use qemu-img only for disk images and resort to things like 'cp --sparse=always' for copying other files.
qemu-img was also not originally designed for block devices, nor was qemu...
Not really relevant for this discussion, but block devices were considered from the beginning - and most importantly, they are about disks.
Kevin