Trying to use KVM with libgfapi and getting wrong path

I’m trying to move to using libgfapi from just a standard NFS mount and I can’t seem to get ONE to feed libvirt the right path in the deployment.0.

Here’s one as an example:

<domain type='kvm' xmlns:qemu=''>
            <type arch='x86_64'>hvm</type>
            <boot dev='hd'/>
            <disk type='network' device='disk'>
                    <source protocol='gluster' name='gv0/177/disk.0'>
                            <host name='kvm01' port='24007' transport='tcp'/>
                    <target dev='vda'/>
                    <driver name='qemu' type='qcow2' cache='none'/>
            <disk type='file' device='cdrom'>
                    <source file='/var/lib/one/datastores/0/100/177/disk.1'/>
                    <target dev='hda'/>
                    <driver name='qemu' type='raw'/>
            <interface type='bridge'>
                    <source bridge='pubbr0'/>
                    <mac address='XX:XX:XX:XX:XX:XX'/>
            <graphics type='vnc' listen='' port='6077'/>

The gluster disk in the above isn’t the correct path. The cdrom path is correct though which has me confused. Where is the 100 in

<source file='/var/lib/one/datastores/0/100/177/disk.1'/>

coming from and why isn’t in the

<source protocol='gluster' name='gv0/177/disk.0'>

Because if I do:

qemu-img info gluster://kvm01:24007/gv0/177/disk.0
qemu-img: Could not open 'gluster://kvm01:24007/gv0/177/disk.0': Could not open 'gluster://kvm01:24007/gv0/177/disk.0': No such file or directory

it fails, but if I fix the path to this:

qemu-img info gluster://kvm01:24007/gv0/100/177/disk.0

Then it works:

image: gluster://kvm01:24007/gv0/100/177/disk.0
file format: qcow2
virtual size: 10G (10737418240 bytes)
disk size: 830M
cluster_size: 65536
Format specific information:
compat: 0.10

What am I missing? I have the gluster fuse mount mounted per the documentation at:

/var/lib/one/datastores/1 -> /var/lib/one/datastores/0

Any ideas?

I’ve switched gears and decided to go with LizardFS (MooseFS fork) instead. Seems to be easier maintenance and fits our needs better. Also adding a new TM for it was pretty easy.