openstack team mailing list archive

[Clay Gerrard <clay.gerrard@xxxxxxxxx>]

On Fri, Sep 28, 2012 at 4:37 AM, Ahmed Al-Mehdi <ahmed@xxxxxxxxxx> 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