qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Supporting unsafe create when backing file is not acces


From: Kevin Wolf
Subject: Re: [Qemu-devel] Supporting unsafe create when backing file is not accessible
Date: Mon, 17 Jul 2017 14:39:01 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 17.07.2017 um 14:25 hat Eric Blake geschrieben:
> On 07/17/2017 07:19 AM, Kevin Wolf wrote:
> 
> > While I think adding -u today is reasonably realistic, I'm doubtful that
> > we can get an introspection mechanism in place today. Perhaps we can
> > declare it a bug fix, but I'd rather not rush something like that.
> > 
> > How does libvirt detect qemu-img features today? Just try and then check
> > the error message?
> 
> Yeah, when it comes to non-advertised feature detection, the best you
> can do is try using the feature, and fall back to the older approach if
> the feature was not present (this approach only works for features that
> gracefully fail without side effects when attempted on older versions,
> but fortunately that's the case for most true feature additions).

Yes, for adding a new option like -u this should work.

> And note that creating an image without a backing file, then using
> 'qemu-img rebase -u' to give it a backing image without probing the
> backing image, IS currently documented and supported (so we DO have a
> safe fallback, regardless of when 'qemu-img create -u ... size' actually
> lands).

I thought so, too, but in fact this is not documented behaviour (yet):

   Unsafe mode

   qemu-img uses the unsafe mode if "-u" is specified. In this mode,
   only the backing file name and format of filename is changed without
   any checks on the file contents. The user must take care of
   specifying the correct new backing file, or the guest-visible content
   of the image will be corrupted.

   This mode is useful for renaming or moving the backing file to
   somewhere else.  It can be used without an accessible old backing
   file, i.e. you can use it to fix an image whose backing file has
   already been moved/renamed.

So we explicitly allow the old backing file to be missing, and we
guarantee that rebase -u doesn't check the image content, but we don't
say anything yet about whether the new backing file must exist.

As this is already unsafe mode, I think for rebase we can indeed just
clarify the documentation.

Kevin

Attachment: pgpKcQmb7ybL6.pgp
Description: PGP signature


reply via email to

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