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
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to