Hi Eric,
We may have our first user (Tomas, CC'd) of the rate filter to limit
NBD connections. As you recall it lets you do commands like:
nbdkit --filter=rate memory size=64G rate=10M
to limit network bandwidth to 10 Mbps. However a twist is that he
needs to vary the parameter while nbdkit is running in response to a
UI, and we haven't really thought about that before.
In the grand and noble tradition of qemu we don't actually systematize
parameters. For the server they are just (key, value) strings. (It's
even possible for filters to modify plugin parameters, thankfully
nothing does that.)
The only filter we have which does anything similar is the error
filter, where the error-file parameter lets you enable and disable the
filter at runtime based on the presence of a file.
rm -f /tmp/inject
nbdkit --filter=error file disk.img error-rate=100% error-file=/tmp/inject
sleep 60; touch /tmp/inject
I think our options are:
* One-time hack in the rate filter.
* One-time hack in the rate filter, but make it compatible with a
possible future revision of parameter handling. eg: If we decided
that "rate:file" would in future mean "read ‘rate’ parameter from a
file" then we could add this as a simple parameter now but
systematize it in future.
* Systematize parameters. This would require a great deal of work and
likely another version of the API. (I pushed a note into the TODO
file for this.)
If we went all the way and allowed parameter values to change, would
this be triggered only by simple file changes, or would we want an
administration interface to the server? (a la QMP)
But I wonder if you have any better ideas?
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/