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

From: "Saggi Mizrahi" <smizrahi(a)redhat.com&gt; To: "Balamurugan Arumugam" <barumuga(a)redhat.com&gt; Cc: devel(a)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(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.

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