[openstack-dev] [nova][cinder] How will nova advertise that volume multi-attach is supported?

Matt Riedemann mriedem at linux.vnet.ibm.com
Thu Jan 14 16:11:28 UTC 2016

On 1/14/2016 9:42 AM, Dan Smith wrote:
>> It is however not ideal when a deployment is set up such that
>> multiattach will always fail because a hypervisor is in use which
>> doesn't support it.  An immediate solution would be to add a policy so a
>> deployer could disallow it that way which would provide immediate
>> feedback to a user that they can't do it.  A longer term solution would
>> be to add capabilities to flavors and have flavors act as a proxy
>> between the user and various hypervisor capabilities available in the
>> deployment.  Or we can focus on providing better async feedback through
>> instance-actions, and other discussed async api changes.
> Presumably a deployer doesn't enable volumes to be set as multi-attach
> on the cinder side if their nova doesn't support it at all, right? I
> would expect that is the gating policy element for something global.

There is no policy in cinder to disallow creating multiattach-able 
volumes [1]. It's just a property on the volume and somewhere in cinder 
the volume drivers support the capability or not.

 From a very quick look at the cinder code, the scheduler has a 
capabilities filter for multiattach so if you try to create a 
multiattach volume and don't have any hosts (volume backends) that 
support that, you'd fail to create the volume with NoValidHost.

But lvm supports it, so if you have an lvm backend you can create the 
multiattach volume, that doesn't mean you can use it in nova. So it 
seems like you'd also need the same kind of capabilities filter in the 
nova scheduler for this and that capability from the compute host would 
come from the virt driver, of which only libvirt is going to support it 
at first.

> Now, if multiple novas share a common cinder, then I guess it gets a
> little more confusing...
> --Dan
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




Matt Riedemann

More information about the OpenStack-dev mailing list