Consider using imago based tool as replacement for qemu-img

[nirs]

We are using https://github.com/lima-vm/go-qcow2reader to convert qcow2 images to raw.

For uncompressed images we have good performance (similar to qemu-img), but for uncompressed images (the common case for cloud images) we are much slower.

There is the imago rust library supporting reading and writing qcow2 images, used by libkrun to run vms sing qcow2 images.

We can use it or a simple tool written with it to do qcow2 conversion, and save the work of maintaining a pretty complicated go code.

Converting images is very slow, and delegating the work to external tool is better than adding complicated libraries in the same process.

Tasks:

• Check if we already have a tool using this library for converting image format
• If it does not exist, write one - should be similar to https://github.com/lima-vm/go-qcow2reader/blob/master/convert/convert.go
• Evaluate the performance of converting compressed images (most common) and uncompressed images
• We probably don't want to add another language to the project, but packing a small tool should be fine

[AkihiroSuda]

We probably don't want to add another language to the project, but packing a small tool should be fine

What do you mean by "packing a tool" ?

[nirs]

We probably don't want to add another language to the project, but packing a small tool should be fine

What do you mean by "packing a tool" ?

Assuming there is a tool using this library, if it is available in brew, is this good enough for our needs? Or we want to be able to use the single file standalone lima executable?

[AkihiroSuda]

We probably don't want to add another language to the project, but packing a small tool should be fine

What do you mean by "packing a tool" ?

Assuming there is a tool using this library, if it is available in brew, is this good enough for our needs? Or we want to be able to use the single file standalone lima executable?

Yes, but the current go-qcow2reader should be kept as a fallback option.
Also, brew install lima should not have a hard dependency on that tool, although it may suggest installing the tool.

[nirs]

Assuming there is a tool using this library, if it is available in brew, is this good enough for our needs? Or we want to be able to use the single file standalone lima executable?

Yes, but the current go-qcow2reader should be kept as a fallback option. Also, brew install lima should not have a hard dependency on that tool, although it may suggest installing the tool.

If we keep go-qcow2reader there is point in using another tool.

[AkihiroSuda]

Assuming there is a tool using this library, if it is available in brew, is this good enough for our needs? Or we want to be able to use the single file standalone lima executable?

Yes, but the current go-qcow2reader should be kept as a fallback option. Also, brew install lima should not have a hard dependency on that tool, although it may suggest installing the tool.

If we keep go-qcow2reader there is point in using another tool.

The tool might be faster?

[jandubois]

I don't understand the suggestion. If we use an external tool, why would we not use qemu-img?

[afbjorklund]

I think it was about being able to configure the qemu-img, to optionally use a similar rust CLI program instead.

But brew install lima shouldn't depend on either, but use the fallback and suggest the other two as optimizations.

[nirs]

I don't understand the suggestion. If we use an external tool, why would we not use qemu-img?

@AkihiroSuda mentioned before that installing qemu-img may be hard impossible in some cases. Maybe in this case depending on another tool will be the same issue?

Anyway if we don't want any dependency, we need to use the go qcow2 reader.

[afbjorklund]

We could provide the tools as separate projects, if it is really important. We considered this for QEMU as well.

The main issue here (for starters) seems to be that the Rust program does not exist yet, only the Rust library?

[jandubois]

Anyway if we don't want any dependency, we need to use the go qcow2 reader.

Maybe we can create a wrapper that can use multiple external tools: if it finds qemu-img, it will use that. Otherwise it looks for imago-tool (or whatever it will be called), and then use that. If it doesn't find anything, it will throw an error.