[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Let's remove some deprecated stuff
From: |
Eric Blake |
Subject: |
Re: Let's remove some deprecated stuff |
Date: |
Mon, 3 May 2021 13:21:47 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 |
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