Invalid order of volumes with adding a volume in boot operation

[Feodor Tersin]

If an image has several volume in bdm, and a user adds one more volume for boot operation, then the new volume is not just added to a volume list, but becomes the second device. This can lead to problems if the image root device has various soft which settings point to other volumes.

For example:
1 the image is a snapshot of a volume backed instance which had vda and vdb volumes
2 the instance had an sql server, which used both vda and vdb for its database
3 if a user runs a new instance from the image, either device names are restored (with xen), or they're reassigned (libvirt) to the same names, because the order of devices, which are passed in libvirt, is the same as it was for the original instance
4 if a user runs a new instance, adding a new volume, the volume list becomes vda, new, vdb
5 in this case libvirt reassings device names to vda=vda, new=vdb, vdb=vdc
6 as a result the sql server will not find its data on vdb

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/217743

[Nikola Đipanov (ndipanov)]

So I am not sure we actually want to fix this. We really don't want to guarantee the stability of device names in any way. We'll want to use something like fs labels in the instance for this.

[Nikola Đipanov (ndipanov)]

Moving this to Invalid - but please feel free to move back if you disagree.

[Feodor Tersin (ftersin)]

@Nikola, the problem is not about device names, but about consistency and workability of volume backed instance snapshots.

Should we support a use case:
1 A user snapshots his volume backed instance which has more than one volume.
2 A user creates a new instance from the snapshot.
3 All services of guest OS work fine.

I think we should, otherwise snapshots of volume backed instances are useless for such instances. But this leads us to need to guarantee the stability of device names in the custom case.
Now we support this use case.

We support a use case:
1 A user creates an instance from volume backed image, adding a new volume.
2 The instance has the additional volume attached.

What about a combined use case:
1 A user snapshots his volume backed instance which has more than one volume.
2 A user creates a new instance from the snapshot, adding a new volume.
3 The instance has the additional volume attached.
4 All services of guest OS work fine.

To have Nova consistent we should support this use case as well. Any objections?

As for fs labels, as i understand they could be usefull from outside only, not from inside an instance (guest OS).

[Daniel Berrange (berrange)]

I agree with Nikola, even in bare metal it has long been considered bad practice to rely on device names when accessing disks. Instead users should rely on disk serial strings, filesystem uuids, or filesystem labels which are persistent no matter what device letter the volume appears at.

[Feodor Tersin (ftersin)]

Well, if all you guys say this is not a bug, it's not a bug. But it's sadly that Nova cannot guarantee device names even in this simple case.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Feodor Tersin (<email address hidden>) on branch: master
Review: https://review.openstack.org/217743
Reason: ndipanov and danpb argued in the bug that this is not a feature which Nova has to support