[openstack-dev] [cinder] Missing feature in create_server_volume (parameter device) with KVM

Steven Dake sdake at redhat.com
Fri Sep 7 19:32:19 UTC 2012


On 09/06/2012 09:20 PM, Vishvananda Ishaya wrote:
> This is done and merged recently. The serial number is set to the volume
> uuid. It is also valid to pass no device parameter on attach and the
> next available device will be used. The device name will be correct as
> long ad the guest kernel is 3.2 or greater.
> 

Cool thanks

I'll have a look at an updated devstack

Regards
-steve

> On Sep 6, 2012 10:30 AM, "Steven Dake" <sdake at redhat.com
> <mailto:sdake at redhat.com>> wrote:
> 
>     Hi,
> 
>     In KVM, the device parameter for the create_server_volume API has no
>     impact on the device seen in the operating system.  Speaking to the KVM
>     devs, they don't see a future where the OS will ever be able to assign a
>     device name as specified in this API.  The OpenStack compute docs
>     describe this limitation:
>     http://docs.openstack.org/trunk/openstack-compute/admin/content/configure-nova-volume.html
> 
>     The reason this functionality is important is for many apps that use the
>     volume server (heat in my case - http://www.heat-api.org), there must be
>     a way to map an external device into a "known" location inside the VM.
> 
>     Consider the example where a user attaches 5 volumes to a server at
>     about the same time - the internal VM will have no reasonable way of
>     determining which attached disk maps to the internal /dev/vdx.
> 
>     A fairly simple solution to this problem is to specify the serial number
>     during KVM volume attachment.  Then the volume would be available in the
>     VM via:
> 
>     mount /dev/disk/by_id/my_disk_a
> 
>     and could be attached to the instance by:
> 
>     create_server_volume(x, y, 'my_disk_a')
> 
>     Another approach would be to add another parameter that defines the
>     serial number (ie: create_server_volume(x, y, z, 'my_disk_a')
> 
>     If there is a preference to approaches, I'll work up the appropriate
>     patches.
> 
>     Regards
>     -steve
> 
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 




More information about the OpenStack-dev mailing list