Re: [ovirt-devel] physical disk management for gluster in vdsm

----- Original Message ----- > From: "Balamurugan Arumugam" <barumuga(a)redhat.com&gt; > To: "Saggi Mizrahi" <smizrahi(a)redhat.com&gt; > Cc: devel(a)ovirt.org > Sent: Thursday, September 25, 2014 3:41:05 AM > Subject: Re: [ovirt-devel] physical disk management for gluster in vdsm > > > ----- Original Message ----- >> From: "Saggi Mizrahi" <smizrahi(a)redhat.com&gt; >> To: "Balamurugan Arumugam" <barumuga(a)redhat.com&gt; >> Cc: devel(a)ovirt.org >> Sent: Wednesday, September 24, 2014 1:34:46 PM >> Subject: Re: [ovirt-devel] physical disk management for gluster in vdsm >> >> >> >> ----- Original Message ----- >>> From: "Balamurugan Arumugam" <barumuga(a)redhat.com&gt; >>> To: devel(a)ovirt.org >>> Sent: Tuesday, September 23, 2014 2:46:59 PM >>> Subject: [ovirt-devel] physical disk management for gluster in vdsm >>> >>> >>> Hi All, >>> >>> Currently gluster management in ovirt is not complete if disks in hosts >>> are >>> not formatted/mounted. It expects those actions done prior in the host >>> added to ovirt. We have a requirement to manage physical disks by >>> >>> 1. identify and populate physical disks. >>> 2. identify and manage hardware raids. >>> 3. create thick and thin logical volumes in unused physical disks. >>> 4. format and mount logical volumes. >>> 5. fstab management for new logical volumes. >>> >>> To have this feature, I would like to start a discussion here to explore >>> possible options suitable for vdsm/engine. >>> >>> We have done a small PoC with OpenLMI[1] by having verbs in vdsm to >>> achieve >>> this. Also we explored ovirt-engine directly calling >>> tog-pegasus/cim-server >>> to get cim object to avoid two level of hopes ("ovirt-engine calls vdsm >>> <-> >>> vdsm calls openlmi locally <-> openlmi does the job" than "ovirt-engine >>> calls vdsm <-> openlmi does the job") which also works. >>> >>> I would like to get your feedback about the PoC and suggestions/ideas how >>> physical disk management can be. >> I would prefer not depending on something like openlmi. It replicates or >> goes against ovirt topology. There is no reason for VDSM to call open >> something >> that calls something that goes back to the host and runs fdisk. >> > > Thanks for your input. > > Could you also comment on ovirt-engine directly calling openlmi to do the > job? Adds dependency on openlmi. I'd prefer not to depend on that. Makes installing harder. Has more points of failure. And we already have vdsm.