[libvirt] [PATCH v2 1/8] blockcopy: virDomainBlockCopy with XML destination, typed params

[Eric Blake]

On 08/26/2014 08:39 AM, Peter Krempa wrote:
> On 08/26/14 13:21, Eric Blake wrote:
>> This commit (finally) adds the virDomainBlockCopy API, with the
>> intent that it will provide more power to the existing 'virsh
>> blockcopy' command.
>>

>> +/**
>> + * VIR_DOMAIN_BLOCK_COPY_BANDWIDTH:
>> + * Macro for the virDomainBlockCopy bandwidth tunable: it represents
>> + * the maximum bandwidth (in MiB/s) used while getting the copy
> 
> I'll re-iterate here. MiB/s seems a pretty big granularity with a lot of
> headroom in the big numbers (2^64 MiB/s networks won't be around for a
> while) but not enough options at the small end where we have 1 MiB/s, 2
> MiB/s and nothing between.

Oh, good call!

> 
> Regarding your comment virDomainBlockJobSetSpeed specifies default unit
> in MiB/s:
> 
> 1) this is a new API so we can choose an arbitrary unit (not that it
> would be nice)
> 
> 2) for virDomainBlockJobSetSpeed we can add a flag for the smaller
> granularity.
> 
> 3) 2^32 KiB/s is also plenty for today's standard: I'd like to have a
> 4TiB/s network/disk drive.
> 

Since we already scale by >>20 in converting to qemu, I think this
proposal makes the most sense:

add a new flag to all existing virDomainBlock* API that take 'unsigned
long bandwidth'; if the flag is present, bandwidth is scaled in bytes,
if the flag is absent, bandwidth is scaled in megabytes.

For the new virDomainBlockCopy, the parameter is ONLY scaled in bytes
(but is a long long everywhere, so it can represent the values that a
32-bit machine can only represent as megabytes - even though no one has
an interface with a limit of 2 billion megabytes...)

Where things get trickiest is in virsh, where we document that negative
values represent effectively unlimited bandwidth - so I have to make
sure that I don't cause overflow warnings if a user passes bandwidth -1
(it may be just easier to say that bandwidth 0 is unlimited, and forbid
negative numbers).

> 
> You've fixed all the problems with docs I've pointed out and I don't
> have any additional comments.
> 
> ACK

I'll push shortly, with the change to make the parameter scaled in
bytes, and do a followup patch for the new flag to the existing APIs.
Getting the new API in before the freeze is the important part, the rest
of the series can dribble in after freeze if necessary.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 539 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140826/4f78af29/attachment-0001.sig>