On Mon, Nov 30, 2020 at 06:58:00PM +0200, Nir Soffer
wrote:> On Wed, Nov 25, 2020 at 12:31 PM Richard W.M. Jones <rjones at
redhat.com> wrote> > Aim (e):
> >
> > Better progress bars: nbdcopy should have support for
> > machine-readable progress bars, once I push the changes. It will
> > mean no more need to parse debug logs.
>
> I don't think this is only about the progress bar, but the entire
process.
>
> The tool should have an option to generate output for machines, for example
> GUI showing what the tool is doing. Typically such application needs to get
> events when changing the state or when progress changes.
>
> It can be simple stream of lines:
>
> event: Setting up ...
> event: Converting disk ...
> event: Copying disk ...
> progress: 0
> progress: 1
> ...
> progress: 100
> event: Creating vm ...
>
> The program consuming this can change the text on each "event:"
line and
> update the progress bar on each "progress:" line.
I suspect the reality will be that these will have to go to several
separate file descriptors, just because that's the only way to make it
work when you have separate processes doing to work. However it
should be an improvement over trying to parse debug logs.
> This can be enhanced by providing additional info about the
> process. For example in RHV it will be helpful if we have the
> transfer id, disk id, and vm id when try to debug
> failures. Currently we have to use keep debug logs and grep the log
> to get the values, but it would be more useful if the details were
> reported by the tool:
>
> info: disk_id=xxxyyy transfer_id=yyyzzz
>
> If the process failed the tool can report:
>
> error: Why it failed...
>
> This is something that every tool doing complex/slow stuff needs to
> implement, like qemu-img convert or dd.
>
> Like https://testanything.org/ for watching processes - watch anything
protocol?
OK.
> > Aim (f):
> >
> > Better logging: I hope we can log each step separately.
> >
> > A custom supervisor program would also be able to tell which
> > particular step failed (eg. did it fail in conversion? did it fail
> > copying a disk and which one?)
>
> For logging it would be useful to support logging to file, so tools
> do not have to read the logs and write them to file.
>
> This is true for all virt-* tools.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/