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

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?

> 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