cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: add connect method on KVM storage code
Date Sat, 28 Sep 2013 06:28:11 GMT
Yeah, maybe we just add a "Map<String, String> connectDetails =
cmd.getConnectDetails()" into attachVolume, and pass that along to
connectPhysicalDisk. Then just set the details where you're currently
setting the chap info prior to the attach command.

On Sat, Sep 28, 2013 at 12:25 AM, Mike Tutkowski
<mike.tutkowski@solidfire.com> wrote:
> CHAP credentials are per SolidFire/CloudStack account. A volume on the
> SolidFire SAN belongs to an account. I have a one-to-one mapping between a
> CloudStack account and a SolidFire account.
>
> As far as Volume Access Groups (VAGs) go, I'm not sure what kind of limits
> they have.
>
> I'd hate to have, say, 10,000 KVM hosts all stuck in the same VAG...each
> host having access (technically) to, say, 20,000 volumes.
>
> VAGs can be created as needed, though...and you can add and remove
> hosts/volumes from them as need be.
>
> On Sat, Sep 28, 2013 at 12:16 AM, Marcus Sorensen <shadowsor@gmail.com>
>  wrote:
>
>> On Sat, Sep 28, 2013 at 12:09 AM, Mike Tutkowski
>> <mike.tutkowski@solidfire.com> wrote:
>> > Yes, you are correct that our SAN requires CHAP or for the host and
>> volume
>> > to be in a Volume Access Group.
>> >
>> > If CHAP is provided, it is used. If it fails for whatever reason, the
>> > Volume Access Group is NOT leveraged to grant permissions.
>> >
>> > If CHAP is not provided, the host and volume must be in a common Volume
>> > Access Group.
>> >
>> > As you say, CHAP only grants access...it will not save us from a rouge
>> > compute node that has access to the volume.
>>
>> Ok, I figured the CHAP credentials were predetermined, but it sounds
>> like they're per-lun.
>>
>> >
>> > If we can't get grantAccess and revokeAccess working in the storage
>> > plug-ins for 4.3, I can just use CHAP. I'd prefer to have no SAN calls
>> > coming in from the compute nodes.
>>
>> Yes, we only do it because we have to, but now with the new framework
>> I'm trying to refactor things as they add support for doing things via
>> the plugin.
>>
>> >
>> > Also, I don't think we can grant all hosts in the KVM cluster access to
>> the
>> > volume ahead of time because the volume won't exist until the first time
>> we
>> > try to attach it. We have to grant access programmatically.
>> >
>> > Plus you might want to disconnect the volume from a KVM host in one
>> cluster
>> > and connect it up in another KVM cluster (zone-wide storage).
>>
>> I was thinking more along the lines of some group that you'd add your
>> hosts to, regardless of which cluster they're in, as you deploy them.
>> But it sounds like those would need to be done dynamically? i.e. I
>> can't create a group, add a host, and then later add a lun and have
>> access to it?

Mime
View raw message