On 10/06/2015 06:12 PM, Peter Krempa wrote:
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.
Yes and many thanks for that. I just put it there to confirm our
understanding
as we are slowly inching towards being on the same page with you :)
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.
Great to be on same page with you till here :)
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.
This is still not clear to me. When libvirt pre-creates the file, how
does it
do it ? Using URI or json syntax ? Since libvirt needs to know the way to
talk with glusterfs, which is either using URI or json, so its still not
clear to
me how libvirt is able to pre-create the file when --reuse-external is
absent.
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.
Why on next start only ?
When snap creation is successfull from qemu,
the backing file will be json syntax, so when the flow comes back to
libvirt, it needs to parse json syntax in order to update the backingStore
info in the domain XML, right ?
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.
So when libvirt pre-creates the file, i thought it will use:
qemu-img create -f qcow2 (either json: or URI syntax)
dependingon the support present in libvirt code, right ?
[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?)
Yes, we had some issues with libgfapi, so libvirtd with those configure
options
wasn't starting, so we were working w/o them, and it worked until we needed
to create a snap. Now we are fine.
thanx,
deepak
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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list