On Tue, Oct 06, 2015 at 15:35:05 +0530, Deepak C Shetty wrote:
> On 10/06/2015 02:53 PM, Peter Krempa wrote:
> > On Tue, Oct 06, 2015 at 10:38:23 +0530, Deepak C Shetty wrote:
> >> On 10/05/2015 07:33 PM, Peter Krempa wrote:
> >>> On Mon, Oct 05, 2015 at 18:59:54 +0530, Deepak C Shetty wrote:
> >>>> On 10/05/2015 04:31 PM, Peter Krempa wrote:
> >>>>> On Mon, Oct 05, 2015 at 15:30:42 +0530, Prasanna Kumar Kalever wrote:
[...]
> We just figured ....
>
> 1) qemu-img create -f qcow2 -b json:"{...}"
> gluster://hostname/volname/snapfile.qcow2 - works
Okay, you can use it as the backing store string ...
> 2) qemu-img create -f qcow2 -b json:"{.../base.img}"
> json:"{.../snapfile.qcow2}" - fails saying json: protocol unsupported
... but not as the image itself. That is workable, since you could
emulate the behavior by re-trying the command with different
single-server URIs.
>
> This is probably bcos qemu-img utility doesn't have support for json:
> syntax and IIRC in the qemu thread it was said
> that we don't need to add this to the qemu-img utility as it adds complexity
>
> So using #1 we are able to pre-create snapfiles that have backing-file:
> json string
[...]
> >>>> gluster protocol*
> >>> Erm, how are you attempting to test this if you don't even have libvirt
> >>> with gluster support installed?
> >> Hmm, what makes u think we don't have libvirt with gluster support
> >> installed ?
> >> libvirtd is running from source with this patch included.
> > So your configure options or build environment is wrong then. The hint
> > is the error message you've posted.
> >
> > error: internal error: missing storage backend for network files using gluster protocol
>
> We configured it correctly now --with-gluster and --with-storage-gluster
>
> >
> > That is a generic message from the storage driver that is used in case
> > when the appropriate backend is not available.
> >
> > As I've pointed out, it's the part of the storage driver that assists
> > the qemu driver in regular operations like reading the image header or
> > setting permissions on image files, not the actual pool/volume storage
> > driver.
>
> So just to understand this correctly, the storage driver is called as part
> of parsing the backing file and yes we do see that it fails when backing
> file
> is of json: syntax but works when its URI syntax.
Well, this is the thing I've pointed out in the original review.
> This also means that the snapshot operation (of having the VM switch to the
> new active file) is done on qemu side and when it returns back to libvirt,
> libvirt is unable to parse as the backing file is json format, so fixing
> the parse URI to support parseJSON needs to be done.
Exactly, that's why I've requested it.
> What happens when we don't use --reuse-external. IIUC the newfile is
If you don't use --reuse-external, then the file is pre-created by
libvirt and the image metadata (including the backing store string) are
filled by the qemu process once we start the "blockdev-snapshot-sync"
operation in qemu.
> created by libvirt so which part of libvirt needs to be fixed so ensure that
> libvirt creates the file using json: syntax and not URI syntax ? The above
No, this happens in qemu. Libvirt needs to be able to process that file
on next start of the VM.
> qemu-img snip shows that json is only supported as part of -b option
> only, so will that be a inhibitor for libvirt when creating new files ?
Not at this point, but we might want to use it in the future in that
way.
>
> >
> > [2]
> >
> > Additionally this might be the reason you are not seeing any failures
> > right now. The code that uses the storage backend queries whether the
> > storage backend is actually supported before attempting to use it, so
> > please make sure that your daemon is properly built with gluster
> > support.
>
> pkalever is now working with libvirtd having gluster support
(Shouldn't that be a pre-requisite for posting a patch like this?)
> We will know more as we make more experiments... the whole gamut
> of network disk support in qemu/libvirt is confusing esp with the addn
> of json and URI syntax both :) So pls bear with our questions above :)
Peter
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list