From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57736) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFSMA-0005N8-Vx for qemu-devel@nongnu.org; Thu, 28 Apr 2011 10:38:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QFSM9-0000JP-RZ for qemu-devel@nongnu.org; Thu, 28 Apr 2011 10:38:14 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:53734) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFSM9-0000JK-Nh for qemu-devel@nongnu.org; Thu, 28 Apr 2011 10:38:13 -0400 Received: by ywl41 with SMTP id 41so1191137ywl.4 for ; Thu, 28 Apr 2011 07:38:13 -0700 (PDT) Message-ID: <4DB97BD3.6080104@codemonkey.ws> Date: Thu, 28 Apr 2011 09:38:11 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1303136821-13333-1-git-send-email-Jes.Sorensen@redhat.com> <1303136821-13333-2-git-send-email-Jes.Sorensen@redhat.com> <20110427120520.74e348d9@doriath> <4DB969E5.2060501@redhat.com> <20110428112124.5098f1ef@doriath> In-Reply-To: <20110428112124.5098f1ef@doriath> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 1/1] Add QMP bits for blockdev-snapshot-sync. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: kwolf@redhat.com, Jes Sorensen , qemu-devel@nongnu.org, Markus Armbruster On 04/28/2011 09:21 AM, Luiz Capitulino wrote: > On Thu, 28 Apr 2011 15:21:41 +0200 > Jes Sorensen wrote: > >> On 04/27/11 17:05, Luiz Capitulino wrote: >>>> +If a new image file is specified, the new image file will become the >>>>> +new root image. If format is specified, the snapshot file will be >>>>> +created in that format. Otherwise the snapshot will be internal! >>>>> +(currently unsupported). >>> Sorry for the stupid question, but what's a "new root image"? Also, all >>> these assumptions seem human features to me, as it can save some typing >>> and I can poke around to see where the snapshots are stored. >>> >>> All arguments should be mandatory in QMP, IMO. >> >> Sorry, but there is absolutely no reason to make all arguments >> mandatory. Sure it can be done, but the only result is a separate >> handling function for it, so we got more almost identical, but still >> different code to maintain. > > We shouldn't compromise our external interface quality because of > implementation details. What I'm really asking here is whether this is > a good command for our management tools. > > For example, I've just realized that the new root image is going to be > automatically created after the first call to this command, and subsequent > calls w/o the snapshot file name will re-use that file. Is that correct? > > Also note the optional format usage, the command (randomly) picks qcow2 if > the format is not given. What happens if I pass a raw image and don't specify > the format? Will it work as it works for qcow2? > > I'm not exactly asking for mandatory arguments. For the format argument for > example, we could try to auto-detect the format (is it possible)? And then > we could fail with a meaningful error message. > > And, I also would like to hear from Anthony, as he's picking up QMP maintenance. I've been ignoring this interface because it's fundamentally broken. Maybe we should not expose this via QMP and instead focus on making a proper interface for this operation. Regards, Anthony Liguori