----- Original Message ----- > From: "Saggi Mizrahi" <[email protected]> > To: "Balamurugan Arumugam" <[email protected]> > Cc: [email protected] > 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" <[email protected]> > > To: "Saggi Mizrahi" <[email protected]> > > Cc: [email protected] > > 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" <[email protected]> > > > To: "Balamurugan Arumugam" <[email protected]> > > > Cc: [email protected] > > > 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" <[email protected]> > > > > To: [email protected] > > > > 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 _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
