qemu-img needs "-O host_device" describing

I've been trying to convert some personal KVM qemu (raw) file images
to raw LVs using kvm-img -O raw.  There's a short version and long
version of this tale.

The short version is "here is a patch to add '-O host_device' to the
manpage", perhaps we should also warn if "kvm-img convert -O raw" is
used on a block device (or even just automatically use host_device?)

The long version is that first of all I changed block/raw-posix.c so
that it didn't try and ftruncat() block devices and then eventually
tracked down why "kvm-img convert -O raw" fails to block devices (it
seeks past holes effectively which is good on files, but not block
devices).

Digging a bit deeper I found reference to "host_device" type and it
turns out that using that as an output format fixes both these issues
- with only one buglet - a hopefully irrelevant error:

  kvm-img convert -O host_device /var/lib/vm/bishop-disk /dev/rootvg/bishop-disk 
  Unknown option 'size'

This on qemu-kvm 0.11.

Thanks,

Adrian

The qemu-truncate.diff patch should be ignored (since host_device
doesn't need it).  Ah, the hazards of using postponed emails!

Adrian

Am 30.09.2009 23:27, schrieb Adrian Bridgett:
> I've been trying to convert some personal KVM qemu (raw) file images
> to raw LVs using kvm-img -O raw.  There's a short version and long
> version of this tale.
> 
> The short version is "here is a patch to add '-O host_device' to the
> manpage", perhaps we should also warn if "kvm-img convert -O raw" is
> used on a block device (or even just automatically use host_device?)
> 
> The long version is that first of all I changed block/raw-posix.c so
> that it didn't try and ftruncat() block devices and then eventually
> tracked down why "kvm-img convert -O raw" fails to block devices (it
> seeks past holes effectively which is good on files, but not block
> devices).

What is the result of this patch? Will raw instead of host_device work
without an error message for devices? If so, I'm against the change.
It's dangerous: qemu-img would leave zero blocks unchanged instead of
overwriting them with zeros, silently corrupting the converted data.

> Digging a bit deeper I found reference to "host_device" type and it
> turns out that using that as an output format fixes both these issues
> - with only one buglet - a hopefully irrelevant error:
> 
>   kvm-img convert -O host_device /var/lib/vm/bishop-disk /dev/rootvg/bishop-disk 
>   Unknown option 'size'

Yes, this is a bug in the host_device definition. I'll send a fix.

Your documentation fix looks fine. Can you resubmit it in a new
(top-level) mail with [PATCH] in its subject and a Signed-off-by line in
it? Only this way the maintainers will pick it up.

Kevin

On Thu, Oct  1, 2009 at 11:57:02 +0200 (+0200), Kevin Wolf wrote:
> Am 30.09.2009 23:27, schrieb Adrian Bridgett:
[snip]
> > The long version is that first of all I changed block/raw-posix.c so
> > that it didn't try and ftruncat() block devices and then eventually
> > tracked down why "kvm-img convert -O raw" fails to block devices (it
> > seeks past holes effectively which is good on files, but not block
> > devices).
> 
> What is the result of this patch? Will raw instead of host_device work
> without an error message for devices? If so, I'm against the change.
> It's dangerous: qemu-img would leave zero blocks unchanged instead of
> overwriting them with zeros, silently corrupting the converted data.

Yep - that's exactly what happens - I was going to send a subsequent
one to stop qemu-img convert from skipping past unallocated blocks -
but then found the host_device format and that sorted it all out,
sorry if that wasn't clear.  I do wonder if -O raw should warn when
run against output devices which aren't regular files though.

> Your documentation fix looks fine. Can you resubmit it in a new
> (top-level) mail with [PATCH] in its subject and a Signed-off-by line in
> it? Only this way the maintainers will pick it up.

Absolutely, thanks for the help :-)

Adrian

Am 01.10.2009 12:48, schrieb Adrian Bridgett:
> I do wonder if -O raw should warn when
> run against output devices which aren't regular files though.

I'd consider an error message pointing to host_device helpful (error
meaning that qemu-img aborts, not just a warning). So if you like to add
the check, go ahead.

Kevin

Kevin Wolf wrote:
> Am 01.10.2009 12:48, schrieb Adrian Bridgett:
> > I do wonder if -O raw should warn when
> > run against output devices which aren't regular files though.
> 
> I'd consider an error message pointing to host_device helpful (error
> meaning that qemu-img aborts, not just a warning). So if you like to add
> the check, go ahead.

Why not simply provide the host_device behaviour when -O raw is used
on a device?  Is there anything to be gained from not doing so?

-- Jamie