From: Eric Blake <eblake@redhat.com>
To: John Snow <jsnow@redhat.com>, Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, qemu-block <qemu-block@nongnu.org>
Subject: Re: [Qemu-devel] qemu-img behavior for locating backing files
Date: Wed, 01 Apr 2015 10:28:24 -0600 [thread overview]
Message-ID: <551C1CA8.2050203@redhat.com> (raw)
In-Reply-To: <551C19F9.3020409@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]
On 04/01/2015 10:16 AM, John Snow wrote:
> Kevin, what's the correct behavior for qemu-img and relative paths when
> creating a new qcow2 file?
>
> Example:
>
> (in e.g. /home/qemu/build/ or anywhere not /home: )
> qemu-img create -f qcow2 base.qcow2 32G
creates /home/qemu/build/base.qcow2
> qemu-img create -f qcow2 -F qcow2 -b base.qcow2 /home/overlay.qcow2
Tries to create /home/overlay.qcow2; requires /home/base.qcow2 to exist
for the creation to be well-formed. (Any use of
/home/qemu/build/base.qcow2 should be wrong)
If you want, you could do:
qemu-img create -f qcow2 /home/overlay.qcow2 $size
qemu-img rebase -u -f qcow2 -F qcow2 -b base.qcow2 /home/overlay.qcow2
to create the file that would relatively point to /home/base.qcow2,
whether or not that file already exists; and it could be argued that we
may even want to support that via a single create command (that is,
'create an image with this string as the backing file, but without
actually chasing through that string')
>
> In 1.7.0., this produces a warning that the base object cannot be found
> (because it does not exist at that location relative to overlay.qcow2),
> but qemu-img will create the qcow2 for you regardless.
Sounds almost ideal (or at least an argument for the 'create with an
unsafe string for backing) - but how did it pick the size for that image?
>
> 2.0, 2.1 and 2.2 all will create the image successfully, with no warnings.
Oops.
>
> 2.3-rc1/master as they exist now will emit an error message and create
> no image.
Sounds like a bug fix, not a regression.
>
> Since this is a change in behavior for the pending release, is this the
> correct/desired behavior?
Yes, I think so.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2015-04-01 16:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-01 16:16 [Qemu-devel] qemu-img behavior for locating backing files John Snow
2015-04-01 16:28 ` Eric Blake [this message]
2015-04-02 9:38 ` Kevin Wolf
2015-04-07 0:31 ` John Snow
2015-04-07 8:44 ` Kevin Wolf
2015-04-07 15:55 ` John Snow
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=551C1CA8.2050203@redhat.com \
--to=eblake@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.