On 09/28/2014 05:45 PM, Saggi Mizrahi wrote:
----- 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.
with openlmi becoming the "way to remotely manage" fedora/rhel, and
hopefully adding REST API, i don't see why we wouldn't allow using it
directly from engine for single host admin operations to avoid to having
to wrap such calls via vdsm.
I would prefer doing this via its REST API if possible though.
_______________________________________________
Devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/devel
