cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <>
Subject Re: add connect method on KVM storage code
Date Sat, 28 Sep 2013 06:28:32 GMT
If grantAccess/revokeAccess worked in the storage plug-in, though, I could
create a VAG per KVM host and give it access to whatever volumes it needs
access to.

When we revoke access, I could remove the IQN of the volume from the
appropriate VAG. If the VAG is empty, I could delete it.

If you had, say, 10,000 KVM hosts each using at least one SolidFire volume,
you'd have 10,000 VAGs. That would be OK, though.

On Sat, Sep 28, 2013 at 12:25 AM, Mike Tutkowski <> 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 <>
>  wrote:
> On Sat, Sep 28, 2013 at 12:09 AM, Mike Tutkowski
>> <> 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 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?

*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
o: 303.746.7302
Advancing the way the world uses the

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message