On 08/31/14 06:02, Eric Blake wrote:
Expose the new flag just added to virDomainGetBlockJobInfo.
With --raw, the presence or absence of --bytes determines which
flag to use in the single API call. Without --raw, the use of
--bytes forces an error if the server doesn't support it,
otherwise, the code tries to silently fall back to scaling the
MiB/s value.
My goal is to eventually also support --bytes in bandwidth mode;
but that's a bit further down the road (and needs a new API flag
added in libvirt.h first).
This changes the human output, but the previous patch added
raw output precisely so that we can have flexibility with the
human output. For this commit, I used qemu-monitor-command to
force an unusual bandwidth, but the same will be possible once
qemu implements virDomainBlockCopy:
Before:
Block Copy: [100 %] Bandwidth limit: 2 MiB/s
After:
Block Copy: [100 %] Bandwidth limit: 1048577 bytes/s (1.000 MiB/s)
The cache avoids having to repeatedly attempt a flag probe when
talking to an older server, when multiple blockjob commands are
issued during a batch session and the user is manually polling
for job completion.
* tools/virsh.h (_vshControl): Add a cache.
* tools/virsh.c (cmdConnect, vshReconnect): Initialize the cache.
* tools/virsh-domain.c (opts_block_job): Add --bytes.
* tools/virsh.pod (blockjob): Document this.
Signed-off-by: Eric Blake <eblake(a)redhat.com>
---
tools/virsh-domain.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++------
tools/virsh.c | 2 ++
tools/virsh.h | 2 ++
tools/virsh.pod | 8 +++++--
4 files changed, 67 insertions(+), 9 deletions(-)
ACK
Peter