[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: Sunday, September 28, 2014 8:15:33 PM
> Subject: Re: [ovirt-devel] physical disk management for gluster in vdsm
> 
> 
> 
> ----- Original Message -----
> > From: "Balamurugan Arumugam" <barumuga at redhat.com>
> > To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > Cc: devel at 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 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?
> 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.


Thanks Saggi.  I will explore other options (blivet or our own) and update here.




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