boot from wrong volume

[David Medberry]

In Kilo (and possibly others) there are times when an instance with an attached volume is rebooted (or stopped/started) it will boot from vdb (the attached volume) instead of vda (the ephemeral boot volume.)

It doesn't appear to matter whether cinder has the attached volume marked bootable or not. Moreover, it doesn't matter if the partition is marked bootable or not.

Details:
KiloNove, Kilo Cinder, CEPH based ephemeral, Ceph based Cinder.

Repro:
1. Create an instance.
2. Create a volume from an existing instance (snapshot and then volume create).
3. Attach that volume. It will attach as vdb by default (and that remains consistent, the volume order doesnt' change).
4. Reboot the instance
SOMETIMES or more accurately SOME INSTANCES now boot from vdb1 as /. It seems consistent once it happens. The only way I've been able to force booting back to vda is to detach the volume (which I can safely re-attach once the instance is booted.)

I've found no other work around.

Real details:
nova-compute 1:2015.1.0-0ubuntu1.1~c all OpenStack Compute - compute node base
cinder-common 1:2015.1.0-0ubuntu1~clo all Cinder storage service - common files
python-cinder 1:2015.1.0-0ubuntu1~clo all Cinder Python libraries
python-cinderclient 1:1.1.1-0ubuntu1~cloud0 all python bindings to the OpenStack Volume API
qemu 1:2.2+dfsg-5expubuntu9. amd64 fast processor emulator
qemu-system 1:2.2+dfsg-5expubuntu9. amd64 QEMU full system emulation binaries
libvirt-bin 1.2.12-0ubuntu13~cloud0 amd64 programs for the libvirt library
libvirt-dev 1.2.12-0ubuntu13~cloud0 amd64 development files for the libvirt library
libvirt0 1.2.12-0ubuntu13~cloud0 amd64 library for interfacing with different virtualization systems

Have not tried to repro in DevStack or with Kilo.2

[Markus Zoeller (markus_z) (mzoeller)]

There could be a relationship to bug 1440762 which solved a bug in Kilo (2015.1.2).

[Sean Dague (sdague)]

David, does this look like 1440762? Or do you believe this is still an open and active bug that's different.

[Lee Yarwood (lyarwood)]

@markus_z I don't see any relation to bug 1440762,could you elaborate why you think there is?

I think this is more of an issue with the libvirt ordering of devices within the domain. We don't currently use per disk boot ordering AFAIK so it might be that the attached volume is just the first device we find to boot from.

@med could you provide some example domain XML to confirm the layout of the devices?

[Augustina Ragwitz (auggy)]

Requested information was not provided and bug was marked for expiration, so marking as invalid. If this is still an issue for you, please provide the requested information and reopen it.