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

Peter Krempa pkrempa at redhat.com
Wed Oct 7 05:50:14 UTC 2015

On Tue, Oct 06, 2015 at 18:54:25 +0530, Deepak C Shetty wrote:
> 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:


> >> 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.

I suggest you actually read the code if you are going to work on this.

Good entry points would be:
qemuDomainSnapshotCreateActiveExternal (top level snapshot function)
qemuDomainSnapshotCreateDiskActive (disk snapshot sub-part)
qemuDomainSnapshotCreateSingleDiskActive (singe disk image sub-part)

The last mentioned function is probably the most relevant one in this

The last function calls 'virStorageFileCreate' which is another good
read to start. The backend it calls is

Yet another good read in this case is qemuDomainDetermineDiskChain and
the call tree below it.

> >
> >> 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 ?

Okay, not actually at 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 ?

... snapshot creation code is actually able to manipulate the backing
data tracked internally in the proper way, but the data is then
overriden by the reloaded data.

> >
> >> 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 ?

See the functions mentioned above for an answer.

-------------- 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/20151007/965ee9f6/attachment-0001.sig>

More information about the libvir-list mailing list