I meant to add something under the -- in my email, but the fingers were
too quick... Although the commit message is quite lengthy - it does
hopefully give enough context to decisions made.
There was some consideration to perform kibibyte range checking in
libvirt; however, if the underlying utility (/sbin/tc) or kernel ever
changes that could be restrictive.
I also considered changing virsh to accept the 'bps' value and convert
it prior to calling the save routine; however, the problem with that is
once someone "sets" value they should expect the following "get" on
the
value to be what was set, not what was actually set using integer
arithmetic. Thus changing the documentation to indicate to use kibibytes
seemed the most reasonable option. Unfortunately we do leave some bytes
on the table in the maximum range.
Changing the code to use "bps" would be really invasive. Although I
suppose the XML could change to default to "kbps" and accept "bps",
"gbps", or "tbps" as the unit of measurement. I didn't see a
need/requirement for that (yet) though.
Finally after just switching between multiple screens and thinking about
everything I've read, the "kbps" used in virNetDevBandwidthSet() is
according to the /sbin/tc code 'kilobytes per second' and not "kibps"
or
'kibibytes per second'. So now, I'm beginning to think perhaps another
patch is needed to change the "kbps" to "kibps". But if I change
that,
then it almost seems reasonable to convert to "bps" on that call.
Hmmmm... But doing that still requires us to read existing xml files
that would have values saved as (purportedly) kibibytes. I'll see what
feedback I get this and go from there...
John