From: Kevin Wolf <kwolf@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Michael Tokarev <mjt@tls.msk.ru>,
QEMU Developers <qemu-devel@nongnu.org>,
"open list:Network Block Dev..." <qemu-block@nongnu.org>,
BALATON Zoltan <balaton@eik.bme.hu>,
"Daniel P. Berrange" <berrange@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: -drive if=none: can't we make this the default?
Date: Thu, 2 Nov 2023 15:06:38 +0100 [thread overview]
Message-ID: <ZUOs7j823+a6FBD2@redhat.com> (raw)
In-Reply-To: <CAFEAcA8hssUvz8kb4VYXNZSyrQhRyo+=AebA-hskm64bmhG-MA@mail.gmail.com>
Am 02.11.2023 um 12:01 hat Peter Maydell geschrieben:
> On Thu, 2 Nov 2023 at 10:43, Kevin Wolf <kwolf@redhat.com> wrote:
> >
> > Am 01.11.2023 um 12:21 hat Peter Maydell geschrieben:
> > > On Tue, 31 Oct 2023 at 18:45, Kevin Wolf <kwolf@redhat.com> wrote:
> > > > Am 16.10.2023 um 13:58 hat Michael Tokarev geschrieben:
> > > > > Almost everyone mentions -blockdev as a replacement for -drive.
> > > >
> > > > More specifically for -drive if=none. I honestly don't know many common
> > > > use cases for that one.
> > >
> > > One use case for it is "create a drive with a qcow2 backend to use
> > > for -snapshot snapshots, but don't plug it into anything". See
> > > https://translatedcode.wordpress.com/2015/07/06/tricks-for-debugging-qemu-savevm-snapshots/
> > > I dunno whether that counts as "common", though :-)
> >
> > Ok, I was already wondering what good -snapshot was for an image that
> > isn't even used, but what the article describes is actually not using
> > -snapshot, but internal snapshots with savevm/loadvm, i.e. using the
> > image to store the VM state.
> >
> > This actually makes a lot of sense for if=none, as one of the few cases
> > where "none" accurately tells what device it will be used with.
>
> Whoops, have I got the terminology wrong again? To me these are
> "snapshots" (they do store the whole VM state including the current
> state of the disk, and "qemu-img info" lists them as "snapshots"),
> whereas I never use the '-snapshot' option, so I never remember
> that we have two different things here. Sorry for introducing
> confusion :-(
It is confusing, -snapshot really doesn't have the best name.
But anyway, your case with savevm/loadvm should work fine with
-blockdev.
Kevin
next prev parent reply other threads:[~2023-11-02 14:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-14 19:16 -drive if=none: can't we make this the default? Michael Tokarev
2023-10-14 19:59 ` BALATON Zoltan
2023-10-31 18:56 ` Kevin Wolf
2023-10-16 8:57 ` Daniel P. Berrangé
2023-10-16 9:55 ` Paolo Bonzini
2023-10-16 11:58 ` Michael Tokarev
2023-10-31 18:44 ` Kevin Wolf
2023-11-01 11:21 ` Peter Maydell
2023-11-02 7:09 ` Markus Armbruster
2023-11-02 10:43 ` Kevin Wolf
2023-11-02 11:01 ` Peter Maydell
2023-11-02 14:06 ` Kevin Wolf [this message]
2023-11-02 14:11 ` Michael Tokarev
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=ZUOs7j823+a6FBD2@redhat.com \
--to=kwolf@redhat.com \
--cc=balaton@eik.bme.hu \
--cc=berrange@redhat.com \
--cc=mjt@tls.msk.ru \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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).