[vdsm] How to handle qemu 1.3 dep for Gluster Storage Domain

Deepak C Shetty deepakcs at linux.vnet.ibm.com
Tue Aug 6 05:18:54 UTC 2013


Hi All,
     There were 2 learnings from BZ 
https://bugzilla.redhat.com/show_bug.cgi?id=988299

1) Gluster RPM deps were not proper in VDSM when using Gluster Storage 
Domain. This has been partly addressed
by the gluster-devel thread @ 
http://lists.gnu.org/archive/html/gluster-devel/2013-08/msg00008.html
and will be fully addressed once Gluster folks ensure their packaging is 
friendly enuf for VDSM to consume
just the needed bits. Once that happens, i will be sending a patch to 
vdsm.spec.in to update the gluster
deps correctly. So this issue gets addressed in near term.

2) Gluster storage domain needs minimum libvirt 1.0.1 and qemu 1.3.

libvirt 1.0.1 has the support for representing gluster as a network 
block device and qemu 1.3 has the
native support for gluster block backend which supports gluster://... 
URI way of representing a gluster
based file (aka volume/vmdisk in VDSM case). Many distros (incl. centos 
6.4 in the BZ) won't have qemu
1.3 in their distro repos! How do we handle this dep in VDSM ?

Do we disable gluster storage domain in oVirt engine if VDSM reports 
qemu < 1.3 as part of getCapabilities ?
or
Do we ensure qemu 1.3 is present in ovirt.repo assuming ovirt.repo is 
always present on VDSM hosts in which
case when VDSM gets installed, qemu 1.3 dep in vdsm.spec.in will install 
qemu 1.3 from the ovirt.repo
instead of the distro repo. This means vdsm.spec.in will have qemu >= 
1.3 under Requires.

What will be a good way to handle this ?
Appreciate your response

thanx,
deepak



More information about the vdsm-devel mailing list