From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:56340)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <den-lists@parallels.com>) id 1Ztvzi-0005cY-GC
	for qemu-devel@nongnu.org; Wed, 04 Nov 2015 06:12:47 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <den-lists@parallels.com>) id 1Ztvzf-0007Mn-5U
	for qemu-devel@nongnu.org; Wed, 04 Nov 2015 06:12:46 -0500
Received: from relay.parallels.com ([195.214.232.42]:36999)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <den-lists@parallels.com>) id 1Ztvzd-0007LU-8L
	for qemu-devel@nongnu.org; Wed, 04 Nov 2015 06:12:43 -0500
References: <87bnbbxhk4.fsf@emacs.mitica>
	<1446622348-2479-1-git-send-email-den@openvz.org>
	<87ziyuksbw.fsf@emacs.mitica>
From: "Denis V. Lunev" <den-lists@parallels.com>
Message-ID: <5639E812.5030303@parallels.com>
Date: Wed, 4 Nov 2015 14:12:18 +0300
MIME-Version: 1.0
In-Reply-To: <87ziyuksbw.fsf@emacs.mitica>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC PATCH 1/1] dataplane: alternative approach to
 locking
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: quintela@redhat.com, "Denis V. Lunev" <den@openvz.org>
Cc: qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>

On 11/04/2015 12:49 PM, Juan Quintela wrote:
> void hmp_delvm(Monitor *mon, const QDict *qdict)
> {
>      const char *name = qdict_get_str(qdict, "name");
>
>      if (!bdrv_find_snapshot_bs()) {
>          monitor_printf(mon, "No block device supports snapshots\n");
>          return;
>      }
>
>      del_existing_snapshots(mon, name);
> }
>
> Yes, we have changed the semantics "slightly".  Pervious version of
> hmp_delvm() will try to remove all the snapshots from any device with
> that name.  This one would remove them until it finds one error.  I
> think that the code reuse and the consistence trumps the change in
> semantics (really the change is only on error cases).

I think you are wrong here. You can not abort operation if one
disk does not have a snapshot assuming the following situation
- VM has one disk
- snapshot XXX is made
- 2nd disk is added
- remove XXX snapshot

Your position is understood. I'll send yet another proof of concept
in an hour.

Den