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/