On 09/12/2014 06:32 AM, Peter Krempa wrote:
On 09/12/14 05:55, Eric Blake wrote:
> Take the previous patch one step further. In addition to
> automatically selecting byte mode with fallback if the
> user's result would be rounded, we also want to give the
> user a way to guarantee byte mode even if rounding is not
> required, with no fallback if the remote side doesn't
> support byte mode. This way, virsh can be used to more
> fully test the impact of setting the bytes flag.
>
> * tools/virsh-domain.c (blockJobBandwidth): Adjust return type and
> check for --bytes flag.
> (cmdBlockCommit, cmdBlockPull, cmdBlockJob): Add --bytes flag.
> (cmdBlockCopy): Likewise, and adjust caller.
> (blockJobImpl): Adjust caller.
> * tools/virsh.pod (blockcommit, blockcopy, blockpull, blockjob):
> Document this.
>
> Signed-off-by: Eric Blake <eblake(a)redhat.com>
> ---
> tools/virsh-domain.c | 57 ++++++++++++++++++++++++++++++++++------------------
> tools/virsh.pod | 48 +++++++++++++++++++++----------------------
> 2 files changed, 61 insertions(+), 44 deletions(-)
>
> diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
Whoah, this is getting a bit too complex IMHO for a simple task.
How about not doing any automagic switching and if the user specifies
the --bytes flag then it would be passed and otherwise just the old
MiB/s value. The --bytes flag could also parse the value as a scaled
integer then.
So if I understand your proposal,
old call, in MiB:
blockjob $dom $disk --bandwidth 1
invalid (attempt to scale, but no --bytes present)
blockjob $dom $disk --bandwidth 1B
new call, in bytes (awfully small value!), fails if server doesn't work
blockjob $dom $disk --bandwidth 1 --bytes
new call, in bytes, but using scaling to match old call
blockjob $dom $disk --bandwidth 1M --bytes
and no automatic fallbacks. I can live with that, but it means ditching
patches 5 and 6, and posting a complete alternative. Give me a couple
days (I've got another project I'm working at the moment, for image
allocation high-watermark reporting), and we'll compare the two approaches.
This would allow to drop a lot of the complexity while still allow to
use the new flags as we unfortunately have to stick with MiB/s in virsh.
That on the other hand doesn't force us to do overly complex logic that
can be left on the operator.
Any other opinions on whether virsh should be user-friendly (automagic
fallback) vs. more literal exposure (no scaled input without --bytes,
but maps closer to API)?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org