From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 348F1C76196 for ; Tue, 11 Apr 2023 12:10:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229548AbjDKMKW (ORCPT ); Tue, 11 Apr 2023 08:10:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58232 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229451AbjDKMKV (ORCPT ); Tue, 11 Apr 2023 08:10:21 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 59F7D10B for ; Tue, 11 Apr 2023 05:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1681214975; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5IVfwhrEHTxPIKyLpf6NqeW3t3CoaOLvsQwlw+bos94=; b=fUZskO1WoskOFYDgKfIGCSJs6AqklzYFJSPp65AHbM+qgdCb1bAkkNGR1m+/Xht6U6IE4i QB98SxvSlseRs7S5gY5zI6M5i8CNn33ADqDd3wT3H+/iTotApoqulE5bXxzx20sB+jFqhj 4yu0xLn8Td7+L+1cBpCgM24f1Wy8xaY= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-153-rCsjhhBWOhicwK3M74TQ6A-1; Tue, 11 Apr 2023 08:09:30 -0400 X-MC-Unique: rCsjhhBWOhicwK3M74TQ6A-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 08D3F101A54F; Tue, 11 Apr 2023 12:09:30 +0000 (UTC) Received: from redhat.com (unknown [10.39.193.156]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 00925202701E; Tue, 11 Apr 2023 12:09:26 +0000 (UTC) Date: Tue, 11 Apr 2023 14:09:25 +0200 From: Kevin Wolf To: Reinoud Zandijk Cc: Michael Tokarev , Alex =?iso-8859-1?Q?Benn=E9e?= , qemu-devel@nongnu.org, Paolo Bonzini , Ryo ONODERA , qemu-block@nongnu.org, Hanna Reitz , Warner Losh , Beraldo Leal , Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= , Kyle Evans , kvm@vger.kernel.org, Wainer dos Santos Moschetta , Cleber Rosa , Thomas Huth , armbru@redhat.com Subject: Re: [PATCH v2 05/11] qemu-options: finesse the recommendations around -blockdev Message-ID: References: <20230403134920.2132362-1-alex.bennee@linaro.org> <20230403134920.2132362-6-alex.bennee@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Am 06.04.2023 um 22:23 hat Reinoud Zandijk geschrieben: > On Tue, Apr 04, 2023 at 06:17:45PM +0200, Kevin Wolf wrote: > > Am 04.04.2023 um 17:07 hat Michael Tokarev geschrieben: > > > 04.04.2023 16:57, Kevin Wolf пишет: > > Maybe -snapshot should error out if -blockdev is in use. You'd generally > > expect that either -blockdev is used primarily and snapshots are done > > externally (if the command line is generated by some management tool), > > or that -drive is used consistently (by a human who likes the > > convenience). In both cases, we wouldn't hit the error path. > > > > There may be some exceptional cases where you have both -drive and > > -blockdev (maybe because a human users needs more control for one > > specific disk). This is the case where you can get a nasty surprise and > > that would error out. If you legitimately want the -drive images > > snapshotted, but not the -blockdev ones, you can still use individual > > '-drive snapshot=on' options instead of the global '-snapshot' (and the > > error message should mention this). > > I didn't know that! I normally use the -snapshot as global option. Is there a > reason why -blockdev isn't honouring -snapshot? The philosophy behind -blockdev is that you're explicit about every image file (and other block node) you want to use and that QEMU doesn't magically insert or change things behind your back. For simple use cases that might not seem necessary, but many of the newer functions added to the block layer, like the block jobs, are operations that can work on any node in the block graph (i.e. any of the open images, including backing files etc.). If QEMU changed something behind your back, you can easily access the wrong image. Especially for management software like libvirt this kind of magic that -drive involves was really hard to work with because it always had to second guess what the world _really_ looked like on the QEMU side. For example, imagine you open foo.img with -snapshot. Now you want to create a backup of your current state, so tell QEMU to backup the block node for foo.img because that's what your VM is currently running on, right? Except that nobody told you that the active image is actually a temporary qcow2 image file that -snapshot created internally. You're backing up the wrong image without the changes of your running VM. So it's better to always be explicit, and then it's unambiguous which image file you really mean in operations. Kevin