qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Markus Armbruster <armbru@redhat.com>, qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, Peter Krempa <pkrempa@redhat.com>,
	"libvirt-list@redhat.com" <libvirt-list@redhat.com>
Subject: Re: Let's remove some deprecated stuff
Date: Mon, 3 May 2021 13:21:47 -0500	[thread overview]
Message-ID: <ccc48bde-3e8f-3abb-f062-77bd04d6cc93@redhat.com> (raw)
In-Reply-To: <87y2d1csxe.fsf@dusky.pond.sub.org>

On 4/29/21 4:59 AM, Markus Armbruster wrote:
> If you're cc'ed, you added a section to docs/system/deprecated.rst that
> is old enough to permit removal.  This is *not* a demand to remove, it's
> a polite request to consider whether the time for removal has come.
> Extra points for telling us in a reply.  "We should remove, but I can't
> do it myself right now" is a valid answer.  Let's review the file:
> 

[adjusting cc for this response]

> 
> Eric Blake:
> 
>     qemu-img amend to adjust backing file (since 5.1)
>     '''''''''''''''''''''''''''''''''''''''''''''''''
> 
>     The use of ``qemu-img amend`` to modify the name or format of a qcow2
>     backing image is deprecated; this functionality was never fully
>     documented or tested, and interferes with other amend operations that
>     need access to the original backing image (such as deciding whether a
>     v3 zero cluster may be left unallocated when converting to a v2
>     image).  Rather, any changes to the backing chain should be performed
>     with ``qemu-img rebase -u`` either before or after the remaining
>     changes being performed by amend, as appropriate.
> 
>     qemu-img backing file without format (since 5.1)
>     ''''''''''''''''''''''''''''''''''''''''''''''''
> 
>     The use of ``qemu-img create``, ``qemu-img rebase``, or ``qemu-img
>     convert`` to create or modify an image that depends on a backing file
>     now recommends that an explicit backing format be provided.  This is
>     for safety: if QEMU probes a different format than what you thought,
>     the data presented to the guest will be corrupt; similarly, presenting
>     a raw image to a guest allows a potential security exploit if a future
>     probe sees a non-raw image based on guest writes.
> 
>     To avoid the warning message, or even future refusal to create an
>     unsafe image, you must pass ``-o backing_fmt=`` (or the shorthand
>     ``-F`` during create) to specify the intended backing format.  You may
>     use ``qemu-img rebase -u`` to retroactively add a backing format to an
>     existing image.  However, be aware that there are already potential
>     security risks to blindly using ``qemu-img info`` to probe the format
>     of an untrusted backing image, when deciding what format to add into
>     an existing image.

I'm not sure how widely used these were, but I'm game for writing a
patch to drop them.  I'm fairly certain libvirt is not using them.

> 
> Kevin Wolf:
> 
>     ``nbd-server-add`` and ``nbd-server-remove`` (since 5.2)
>     ''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> 
>     Use the more generic commands ``block-export-add`` and ``block-export-del``
>     instead.  As part of this deprecation, where ``nbd-server-add`` used a
>     single ``bitmap``, the new ``block-export-add`` uses a list of ``bitmaps``.

Peter, is libvirt good for this one to go?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



  parent reply	other threads:[~2021-05-03 18:23 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-29  9:59 Let's remove some deprecated stuff Markus Armbruster
2021-04-29 10:18 ` Gerd Hoffmann
2021-04-29 10:24   ` Daniel P. Berrangé
2021-04-29 10:29     ` Peter Maydell
2021-04-29 10:35       ` Daniel P. Berrangé
2021-04-29 10:55         ` Gerd Hoffmann
2021-04-30 10:47           ` Markus Armbruster
2021-04-29 11:07         ` Paolo Bonzini
2021-04-29 10:25 ` Peter Maydell
2021-04-29 10:32 ` Daniel P. Berrangé
2021-04-30  6:47   ` Markus Armbruster
2021-04-29 11:06 ` Paolo Bonzini
2021-04-29 12:40   ` Gerd Hoffmann
2021-04-29 13:12     ` Kevin Wolf
2021-04-29 13:46       ` Gerd Hoffmann
2021-04-29 15:05         ` Philippe Mathieu-Daudé
2021-04-30  7:01           ` Markus Armbruster
2021-04-30  7:01           ` Gerd Hoffmann
2021-05-03 15:10     ` Paolo Bonzini
2021-04-29 11:17 ` Thomas Huth
2021-04-29 11:24   ` Peter Maydell
2021-05-03 10:39     ` Markus Armbruster
2021-04-29 14:49 ` Stefan Hajnoczi
2021-04-29 16:32 ` Eduardo Habkost
2021-04-30  3:22 ` Robert Hoo
2021-05-03  1:41 ` Alistair Francis
2021-05-03  4:49   ` Thomas Huth
2021-05-03  7:12     ` Alistair Francis
2021-05-03 15:13       ` Paolo Bonzini
2021-05-03 22:57         ` Alistair Francis
2021-05-03 13:14 ` Philippe Mathieu-Daudé
2021-05-03 18:21 ` Eric Blake [this message]
2021-05-04 13:59   ` Peter Krempa

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=ccc48bde-3e8f-3abb-f062-77bd04d6cc93@redhat.com \
    --to=eblake@redhat.com \
    --cc=armbru@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=libvirt-list@redhat.com \
    --cc=pkrempa@redhat.com \
    --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).