Cinder volumes not always attached to instance in order presented
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Expired
|
Undecided
|
Unassigned |
Bug Description
Description
===========
Our application require a number of Cinder volumes to be attached to the Nova instance. They always need to be attached in the same order, the order matter to the software defined storage application. How they are presented in our application determines what "disk" the Cinder volume becomes in the application (our software defined storage VM has boot, root, coredump, data disks, etc.)
We use the OpenStack API to create the resources (Cinder, Neutron, Nova, etc.) and attach them with a Nova server create call.
Most of the time the volumes are attached in the correct order, but about 1 out of 10 times, the order of the volumes as they are presented in the nova API call (Python list) is not preserved. This causes our SDS VM to fail booting because it does not get the disks it expects in the correct order.
Most VMs do not care about the order in which the cinder volumes are presented in the VM, in our case it is significant.
Steps to reproduce
==================
This has been done using the OpenStack API, which is the best way to programmatically reproduce the problem, but could likely be done with OS CLI as well.
1. Create a number of Cinder volumes in a way which they can be uniquely identified in the VM instance (different sizes, etc.
2. Attach volumes to Nova instance and boot.
3. repeat steps 1 & 2 enough times, and the cinder volumes will be attached to the nova instance in a different order than what was specified. This can be verified by checking the libvirt XML file that is generated by nova (virsh dumpxml <domain name>).
Expected result
===============
Given an ordered list of Cinder volumes to be attached to a nova instance, the expected result is that they are attached in the specified order every time.
Actual result
=============
Most times the expected result is true, about 1 out of 10 times, the order the volumes are attached to the nova instance is not what is expected.
Environment
===========
RedHat RDO - Liberty
openstack-
1. Exact version of OpenStack you are running. See the following
list for all releases: http://
2. Which hypervisor did you use?
Libvirt + KVM
libvirt-
libvirt-
qemu-kvm-
qemu-kvm-
libvirt-
2. Which storage type did you use?
Cinder NFS driver for Netapp FAS; Cinder iSCSI driver for SolidFire
3. Which networking type did you use?
Neutron with openvswitch.
Logs & Configs
==============
N/A
Changed in nova: | |
status: | New → Incomplete |
Are you waiting for each volume to show up as "in-use" before attaching another one?
Are you passing in the device_name field and expecting that to be honored when attaching the volume? Because with the libvirt driver it won't be:
https:/ /developer. openstack. org/api- ref/compute/ ?expanded= attach- a-volume- to-an-instance- detail# attach- a-volume- to-an-instance
"Name of the device such as, /dev/vdb. Omit or set this parameter to null for auto-assignment, if supported. If you specify this parameter, the device must not exist in the guest operating system. Note that as of the 12.0.0 Liberty release, the Nova libvirt driver no longer honors a user-supplied device name. This is the same behavior as if the device name parameter is not supplied on the request."
Also see: https:/ /review. openstack. org/#/c/ 452546/