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
