[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] Supporting unsafe create when backing file
Re: [Qemu-block] [Qemu-devel] Supporting unsafe create when backing file is not accessible
Mon, 17 Jul 2017 10:42:05 +0200
Am 14.07.2017 um 21:13 hat Nir Soffer geschrieben:
> On Wed, Jul 12, 2017 at 5:40 PM Eric Blake <address@hidden> wrote:
> > On 07/12/2017 03:56 AM, Ala Hino wrote:
> > > Hi,
> > >
> > > We encountered a performance issue when creating a volume for a running
> > VM
> > > and we'd like to share the info with you. The root cause of the issue is
> > in
> > > our code but we found a workaround that relies on qemu-img create
> > > undocumented behavior.
> > >
> > > During our tests, we found that in order to create a volume with a
> > backing
> > > file, the baking file has to be valid and accessible.
> > In general, that's a good thing. But you're also right that it is nice
> > to have a mode where the backing file is not probed.
> > > This requires us to
> > > activate the entire chain before creating the volume, and deactivate the
> > > chain after the operation completes. Activating and deactivating the
> > chain
> > > are expensive operations that we prefer to avoid when possible. Below is
> > > the command we use to create volumes:
> > >
> > > qemu-img create -f qcow2 -o compat=1.1 -b
> > > 8a28cda2-548d-47da-bbba-faa81284f6ba -F raw
> > >
> > /rhev/data-center/e6b272af-84cb-43fc-ae5b-7fe18bc469a2/f47c980a-fd76-44a9-8b78-00d3ab2ffd2f/images/2ff0a3c0-f145-4f83-b668-fc0c39ba191f/d3b69657-892f-499c-9ac3-9c443ead7d9b
> > > 1073741824
> > >
> > > We also found that when providing the size and the backing format for
> > qemu,
> > > qemu doesn't open the backing chain, and in this case we don't have to
> > > activate/deactivate the entire chain - exactly the behavior we wish to
> > have.
> > Yes, that is currently the case. You are correct that patches have been
> > proposed to tighten things so that we would probe the existence of the
> > backing file in more cases (even when the size is provided); and that if
> > we do so, we'd also have to provide a backdoor for creating an image
> > without probing the backing file. But it is also the case that you can
> > create an image with NO backing file, and then use 'qemu-img rebase -u'
> > to add the backing file after the fact, without waiting for any proposed
> > patches to land.
> > > We we'd like to get your confirmation of the above behavior as it isn't
> > > documented, and whether it can be documented.
> > The fact that you are asking does mean that we should revive John's
> > proposed patches, in some form or another.
> Eric, we are more concerned about using the current qemu version.
> We can use the fact that providing both size and backing format,
> qemu does not open the backing file, but this is not documented, and
> we don't want to base oVirt code on undocumented behavior.
> What we would like to have is:
> - qemu blessing for using this undocumented behaviour
> - and documenting this behavior in qemu-img(1)
You already asked me whether you could rely on this behaviour in a
private email and my answer was a pretty clear no.
I'm not sure what you're hoping to get from asking someone else for the
same thing, but if you want an accurate answer, it won't change.
We won't document this undocumented behaviour because it isn't
intentional in the first place. It is simply a missing check of user
input in qemu-img.
> With this we can fix https://bugzilla.redhat.com/1395941
> now, instead of waiting for qemu 2.10.
Upstream doesn't compromise on interfaces to make life more convenient
for downstreams. The correct procedure here is to get a -u added for
2.10 and then backport it into the downstream.