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