qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Reinoud Zandijk <reinoud@netbsd.org>
Cc: "Michael Tokarev" <mjt@tls.msk.ru>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	qemu-devel@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>,
	"Ryo ONODERA" <ryoon@netbsd.org>,
	qemu-block@nongnu.org, "Hanna Reitz" <hreitz@redhat.com>,
	"Warner Losh" <imp@bsdimp.com>, "Beraldo Leal" <bleal@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Kyle Evans" <kevans@freebsd.org>,
	kvm@vger.kernel.org,
	"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
	"Cleber Rosa" <crosa@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>,
	armbru@redhat.com
Subject: Re: [PATCH v2 05/11] qemu-options: finesse the recommendations around -blockdev
Date: Tue, 11 Apr 2023 14:09:25 +0200	[thread overview]
Message-ID: <ZDVN9TlzrCOJHlDR@redhat.com> (raw)
In-Reply-To: <ZC8qXxB6X8t7RBa+@gorilla.13thmonkey.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



  reply	other threads:[~2023-04-11 12:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-03 13:49 [PATCH v2 00/11] more misc fixes for 8.0 (tests, gdbstub, meta, docs) Alex Bennée
2023-04-03 13:49 ` [PATCH v2 01/11] scripts/coverage: initial coverage comparison script Alex Bennée
2023-04-03 13:49 ` [PATCH v2 02/11] gdbstub: Only build libgdb_user.fa / libgdb_softmmu.fa if necessary Alex Bennée
2023-04-03 13:49 ` [PATCH v2 03/11] gdbstub: don't report auxv feature unless on Linux Alex Bennée
2023-04-03 13:49 ` [PATCH v2 04/11] MAINTAINERS: add a section for policy documents Alex Bennée
2023-04-03 13:49 ` [PATCH v2 05/11] qemu-options: finesse the recommendations around -blockdev Alex Bennée
2023-04-04 13:57   ` Kevin Wolf
2023-04-04 14:55     ` Alex Bennée
2023-04-04 15:07     ` Michael Tokarev
2023-04-04 16:17       ` Kevin Wolf
2023-04-06 20:23         ` Reinoud Zandijk
2023-04-11 12:09           ` Kevin Wolf [this message]
2023-04-11 13:03             ` Alex Bennée
2023-04-03 13:49 ` [PATCH v2 06/11] metadata: add .git-blame-ignore-revs Alex Bennée
2023-04-03 13:49 ` [PATCH v2 07/11] Use hexagon toolchain version 16.0.0 Alex Bennée
2023-04-03 13:49 ` [PATCH v2 08/11] tests/qemu-iotests: explicitly invoke 'check' via 'python' Alex Bennée
2023-04-03 13:49 ` [PATCH v2 09/11] tests/vm: use the default system python for NetBSD Alex Bennée
2023-04-04 11:24   ` Philippe Mathieu-Daudé
2023-04-03 13:49 ` [PATCH v2 10/11] gitlab: fix typo Alex Bennée
2023-04-03 13:49 ` [PATCH v2 11/11] tests/avocado: Test Xen guest support under KVM Alex Bennée

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZDVN9TlzrCOJHlDR@redhat.com \
    --to=kwolf@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=armbru@redhat.com \
    --cc=bleal@redhat.com \
    --cc=crosa@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=imp@bsdimp.com \
    --cc=kevans@freebsd.org \
    --cc=kvm@vger.kernel.org \
    --cc=mjt@tls.msk.ru \
    --cc=pbonzini@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=reinoud@netbsd.org \
    --cc=ryoon@netbsd.org \
    --cc=thuth@redhat.com \
    --cc=wainersm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).