Re: qemu-img convert vs writing another copy tool

[Max Reitz]

On 23.01.20 19:35, Richard W.M. Jones wrote:
> I guess some people are aware that virt-v2v, which is a tool which
> converts guests from VMware to run on KVM, and some other
> OpenStack-OpenStack migration tools we have, use "qemu-img convert" to
> copy the data around.
> 
> Historically we've had bugs here.  The most recent was discussed in
> the thread on this list called "Bug? qemu-img convert to preallocated
> image makes it sparse"
> (https://www.mail-archive.com/address@hidden/msg60479.html)
> 
> We've been kicking around the idea of writing some alternate tool.  My
> proposal would be a tool (not yet written, maybe it will never be
> written) called nbdcp for copying between NBD servers and local files.
> An outline manual page for this proposed tool is attached.
> 
> Some of the things which this tool might do which qemu-img convert
> cannot do right now:
> 
>  - Hint that the target already contains zeroes.  It's almost always
>    the case that we know this, but we cannot tell qemu.  This was the
>    cause of a big performance regression last year.
> 
>  - Declare that we want the target to be either sparse or
>    preallocated.  qemu-img convert can sort of do this in a
>    round-about way (create the target in advance and use the -n
>    option), but also it's broken at the moment.

Both of these would be solved by --target-is-zero, I think.

>  - NBD multi-conn.  In my tests this makes a really massive
>    performance difference in certain situations.  Again, virt-v2v has
>    a lot of information that we cannot pass to qemu: we know, for
>    example, exactly if the server supports the feature, how many
>    threads are available, in some situations even have information
>    about the network and backing disks that the data will travel over
>    / be stored on.

As far as I understand it, you use qemu-img convert with an NBD source
or target, too?

I suppose it’s always easier to let a specialized and freshly written
tool handle such information.  But it sounds like if such information is
useful and makes that big of a difference, then it would be good to be
able to specify it to qemu’s NBD block driver, too.

>  - Machine-parsable progress bars.  You can, sort of, parse the
>    progress bar from qemu-img convert, but it's not as easy as it
>    could be.  In particular it would be nice if the format was treated
>    as ABI, and if there was a way to have the tool write the progress
>    bar info to a precreated file descriptor.

It doesn’t seem impossible to add this feature to qemu-img, although I
wonder about the interface.  I suppose we could make it an alternative
progress output mode (with some command-line flag), and then the
information would be emitted to stdout (just like the existing progress
report).  You can of course redirect stdout to whatever fd you’d like,
so I don’t know whether qemu-img itself needs that specific capability.

OTOH, if you need this feature, why not just use qemu itself?  That is,
a mirror or a backup block job in an otherwise empty VM.

>  - External block lists.  This is a rather obscure requirement, but
>    it's necessary in the case where we can get the allocated block map
>    from another source (eg. pyvmomi) and then want to use that with an
>    NBD source that does not support extents (eg. nbdkit-ssh-plugin /
>    libssh / sftp).  [Having said that, it may be possible to implement
>    this as an nbdkit filter, so maybe this is not a blocking feature.]

That too seems like a feature that’s easily implementable in a
specialized tool, but hard to implement in qemu-img.

I suppose we’d want a dirty bitmap copy mode which copies only the
regions that the bitmap reports as dirty – but at that point you’re
probably again better off not using qemu-img, but qemu itself.  Then
we’d need some way to import bitmaps, and I actually don’t think we have
that yet.

But again, if this is a generally useful feature, I think we want it in
qemu anyway.

> One thing which qemu-img convert can do which nbdcp could not:
> 
>  - Read or write from qcow2 files.
> 
> So instead of splitting the ecosystem and writing a new tool that
> doesn't do as much as qemu-img convert, I wonder what qemu developers
> think about the above missing features?  For example, are they in
> scope for qemu-img convert?

What I think is that there may be features that we don’t want in
qemu-img, because they are more appropriate for the mirror or backup
block job.  For example, I don’t think we want to let qemu-img convert
mess around with dirty bitmaps.

But apart from that, the features you propose all seem useful to have in
qemu itself.  Maybe some of them are too hard to implement (specifically
importing bitmaps from external sources), then it might be pragmatic to
write a new tool where such features can be easily implemented because
they don’t need to be integrated into an existing API.

As for performance, well, if qemu’s NBD driver is slow, then naively I’d
think that’s a bug, isn’t it?  And if improving performance requires
knobs, then that’s how it is.

Max

signature.asc
Description: OpenPGP digital signature