From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47154 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PiqzY-000361-AS for qemu-devel@nongnu.org; Fri, 28 Jan 2011 11:16:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PiqzV-0005w5-NS for qemu-devel@nongnu.org; Fri, 28 Jan 2011 11:16:07 -0500 Received: from mail-gw0-f45.google.com ([74.125.83.45]:43282) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PiqzV-0005vv-J1 for qemu-devel@nongnu.org; Fri, 28 Jan 2011 11:16:05 -0500 Received: by gwaa12 with SMTP id a12so1256244gwa.4 for ; Fri, 28 Jan 2011 08:16:05 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1295648355-17359-1-git-send-email-ctang@us.ibm.com> <20110128095753.GC3082@stefanha-thinkpad.localdomain> Date: Fri, 28 Jan 2011 16:16:03 +0000 Message-ID: Subject: Re: [Qemu-devel] [PATCH 1/3] FVD: Added support for 'qemu-img update' From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chunqiang Tang Cc: qemu-devel@nongnu.org On Fri, Jan 28, 2011 at 2:51 PM, Chunqiang Tang wrote: >> 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. =A0A 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 wor= k > 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? =A0As 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). =A0But should users >> need to micromanage every image file in order to achieve desired >> functionality/performance? =A0What's the real need here? > > Default values of the image parameters may be suitable for most users, bu= t > 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 se= t > 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 =A0vs. a local > disk. Without control, users share the same image template may often find > it hard to use. It should be possible to change prefetching and copy-on-read while the VM is running. For example, having to shut down a VM in order to pause the prefetching is not workable. In the QED image streaming tree there are monitor commands for this: http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/stream-command Stefan