It's not quite correct to say that only Vivek was in the room at the storage summit: Fernando Cao presented the state of dm-ioband and the reasons for wanting it quite eloquently. What was missing was io-throttle.
dm-ioband solves exactly the problem of allocating bandwidth to virtual machines because it operates at the VM level. The problem is that it's too high up in the stack efficiently (it's many layers away from the physical I/O driver, which is where the actual bandwith allocations are done). io-throttle looks to be substantially similar to dm-ioband in this regard, so it would suffer from the same problem. Conversely, io-controller can regulate exactly and efficiently the bandwidths at the physical layer, but it's too far away from the virtual machine layers to ensure exact compliance with VM based limits (in fact one can prove cases where one VM can run away with all the bandwidth).
Where I thought we'd got to at the storage summit was an appreciation that the physical layer is the correct one to regulate at (being the closes to the device) but that to solve the VM bandwidth allocation problem, we'd also need much of the machinery of dm-ioband (the page tracking and I/O accounting per VM) then what it would do is periodically apply corrections to the static limits of io-controller to ensure the per VM limits were respected (a bit like the way irqbalanced operates to keep interrupts well distributed).
Unfortunately the agreement seems to be misphasing again ... fortunately I can say this is Jens' problem now ...