qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 05/11] qemu-options: finesse the recommendations around -b


From: Kevin Wolf
Subject: Re: [PATCH v2 05/11] qemu-options: finesse the recommendations around -blockdev
Date: Tue, 11 Apr 2023 14:09:25 +0200

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 via email to

[Prev in Thread] Current Thread [Next in Thread]