On Fri, Sep 28, 2012 at 4:37 AM, Ahmed Al-Mehdi <[email protected]> wrote:
> Who manages LVM VG - "nova-volumes". The operator is responsible for creating the LVM volume group, from the physical volumes's available on the system. This options specifies the name of the volume group that the volume-manager will use to provision volumes and snapshots. You get an error if it does not exist. > My thinking is nova-volume creates LV > out of this VG and feeds it into iSCSI Target using utilites - tgt-admin, > tgt-setup-lun (etc.). This LV is then exported as a block storage by the > iSCSI Target. This block storage is then attached to / seen by a VM > instance on the same or another physical host which has iSCSI connection to > the SCSI Tgt. Would that be correct Sounds right to me. > If so, I have a few questions: > - What if I want to "feed" additional disks/block devices or VGs to > nova-volume module? How and where would I specify that. Or do I have to > modify the nova-volume code to handle that. (One solution I can think of is > to pool the additional storage into the existing VG - nova-volumes.)> vgextend should do the trick. > - What if I don't want to feed any VG to nova-volume, but rather want > nova-volume to call into the iSCSI target to get block storage. > - I would like to understand the interaction/interface/API of nova-volume > (Cinder) that calls into iSCSI Target to expose storage or API to storage > appliance to get block storage. Is this a generic standardized API that > can call into any type of block storage - iSCSI , FCoE, etcv? If so, > pointers to API would be highly appreciated. None of the current drives support this to my knowledge. You would have to write a custom driver. -clayg _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
