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

[Saggi Mizrahi]

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