Re: [Qemu-devel] [PATCH 1/3] FVD: Added support for 'qemu-img update'

[Chunqiang Tang]

> 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