Re: [Qemu-block] interactive qemu-img

[Jeff Cody]

On Mon, Jul 30, 2018 at 04:57:54PM -0400, Programmingkid wrote:
> 
> > On Jul 30, 2018, at 3:55 PM, Jeff Cody <address@hidden> wrote:
> > 
> > On Mon, Jul 30, 2018 at 12:30:01PM -0400, Programmingkid wrote:
> >> 
> >>> On Jul 30, 2018, at 11:09 AM, Eric Blake <address@hidden> wrote:
> >>> 
> >>> On 07/28/2018 08:22 PM, Programmingkid wrote:
> >>>> I thought of a way to make qemu-img much more user-friendly. When the 
> >>>> user opens qemu-img without any arguments, we could present a prompt 
> >>>> that guides the user on making an image file.
> >>>> This illustrates what I think should happen.
> >>>> <after user double-clicks on qemu-img...>
> >>>> Please select a format (qcow, qcow2, raw, vdi, vhdx, vmdk, vpc, vvfat):
> >>>> qcow2
> >>>> Please enter a size (e.g. 100M, 10G):
> >>>> 4G
> >>>> Please enter a name:
> >>>> WinXP.qcow2
> >>>> Creating image file...done
> >>>> The interactive prompt would contain enough options to make a usable 
> >>>> image file. If the user wants to use some of the more advanced features 
> >>>> of qemu-img he or she would still need to use the command-line.
> >>>> Would such a patch be welcomed?
> >>> 
> >>> qemu-img is a command line tool, not a gui.  Bloating it with a gui 
> >>> dialog box is probably not a wise idea.
> >> There would be no gui dialog box. Qemu-img would still be a command-line 
> >> tool. The patch would be done in printf/scanf calls.
> >> 
> > 
> > Even without a GUI, this would still add a not insignificant bloat and
> > unnecessary complexity to qemu-img, that doesn't add to the core
> > purpose of the tool.
> > 
> > It is not that the idea of such a dialog-driven tool (command-line or
> > otherwise) is without merit; it is that it would be better served as a
> > wrapper around qemu-img rather than built into qemu-img.  And it probably
> > wouldn't belong as part of the QEMU codebase, either, but more like other
> > management tools (e.g. libvirt) that wrap QEMU and add higher-level features
> > like that.
> > 
> > (One example of sorts, albeit of a GUI, is virt-manager. If you explore the
> > storage management, you can create qemu images of various types).
> 
> A wrapper around qemu-img might actually be a better idea than making 
> qemu-img interactive. I'm currently not sure which route to travel. Maybe 
> just improving the help of qemu-img might be good enough.
> 

Even as a standalone wrapper around qemu-img, there is still the question of
whether this is something to include in the QEMU git tree.

The biggest reason against it (IMO) is that it becomes another installed
tool that now has to be maintained from here on out (and not to mention,
essentially a management tool, at that).  I don't see why QEMU would start
shipping a management tool for qemu-img, when we don't ship any other
management tools that are user-facing.

I think an interactive wrapper could be nice, but it should be a separate
project outside of QEMU.  I also don't think this should discourage you from
making such a tool, if it is something you'd find useful.  Many a useful
project started from people creating tools for their own consumption!

-Jeff