@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).
** Changed in: nova
Status: Invalid => New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1489442
Title:
Invalid order of volumes with adding a volume in boot operation
Status in OpenStack Compute (nova):
New
Bug description:
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
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1489442/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
