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@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