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

[Balamurugan Arumugam]

----- Original Message -----
> From: "Saggi Mizrahi" <smizrahi at redhat.com>
> To: "Balamurugan Arumugam" <barumuga at redhat.com>
> Cc: devel at 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 at redhat.com>
> > To: devel at 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?



> I would suggest implementing our own wrappers over the regular linux tools
> or something local like blivet[1] (used by anaconda).
> 

I had similar thought on blivet would be a choice of a library.  I will explore on this.


> In general I would like to avoid depending on other daemons as much as
> possible.
> We are already having a lot of trouble managing libvirtd and superVDSM.
> 


Regards,
Bala