> On Fri, Jan 21, 2011 at 05:19:13PM -0500, Chunqiang Tang wrote: > > This patch adds the 'update' command to qemu-img. FVD stores various > > image-specific configurable parameters in the image header. A user can use > > 'qemu-img update' to modify those parameters and accordingly controls FVD's > > runtime behavior. This command may also be leveraged by other block device > > drivers, e.g., to set the size of the in-memory metadata cache. Currently > > those parameters are hard-coded in a one-size-fit-all manner. > > There's a high risk that users will try this command while the VM is > running. A safe-guard is needed here in order to avoid corrupting the > image.
Good observation and this should be added. In FVD, once an image is open, a dirty bit is set in the image header. qemu-img update can refuse to work or ask for confirmation if it sees the dirty bit. > Please use qemu-option.h instead of int argc, char **argv just like > qemu-img create -o does. Will do. > Finally, is this interface really necessary? As a developer it can be > useful to tweak image values (in QED I actually have a free-standing > tool that can query and manipulate image internals). But should users > need to micromanage every image file in order to achieve desired > functionality/performance? What's the real need here? Default values of the image parameters may be suitable for most users, but there are cases where more control is needed, not only for performance tuning but also for functional control. This is especially true for copy-on-read and prefetching, and when many VMs are created based on the same image template (like that in a Cloud or the publicly shared VMware appliance http://www.vmware.com/appliances/). For example, the image template may turn on copy-on-read and prefetching, but a user wants to set it off. Even for prefetching, there are parameters that control when to start prefetching and how much bandwidth prefetching can use (as prefetching has to be conservative). This can be different in different environments, e.g., 100MB vs 10GB Ethernet, SAN disk array vs. a local disk. Without control, users share the same image template may often find it hard to use. Performance tuning may also be important. Because QEMU supports so many diverse platforms, we cannot expect one size fit all. Specifically, when doing benchmarking, I found QCOW2's metadata cache was way too small even for my 32-bit host, but I simply couldn't control that. Regards, ChunQiang (CQ) Tang, Homepage: http://www.research.ibm.com/people/c/ctang