[libvirt] [PATCH 1/1] qemu: add support for multiple gluster hosts

[Peter Krempa]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20151006/8c020bc0/attachment-0001.sig>