Open Stack

The inconsistency in device naming is documented in
https://docs.openstack.org/nova/pike/user/block-device-mapping.html#intermezzo-problem-with-device-names
.

Similar to Tim's suggested approach, you can also mount the device by its
UUID. A while back I wrote a small, relatively untested, Python script to
which modifies fstab & replaces the device names with UUID=<device UUID>
(see attached). It depends on Augeas (python-augeas) to modify fstab.

This script can be downloaded into the Instance using cloud-init, and then
executed on initial boot with runcmd.

—
Blake Covarrubias
Product Manager
Platform9 Systems, Inc

On Thu, Jan 25, 2018 at 11:13 PM, Tim Bell <Tim.Bell at cern.ch> wrote:

> Labels can be one approach where you mount by disk label rather than device
>
>
>
> Creating the volume with the label
>
>
>
> # mkfs -t ext4 -L testvol /dev/vdb
>
>
>
> /etc/fstab then contains
>
>
>
> LABEL=testvol /mnt ext4 noatime,nodiratime,user_xattr    0       0
>
>
>
> You still need to be careful to not attach data disks at install time
> though but it addresses booting order problems.
>
>
>
> Tim
>
>
>
> *From: *Jean-Philippe Méthot <jp.methot at planethoster.info>
> *Date: *Friday, 26 January 2018 at 07:28
> *To: *"Logan V." <logan at protiumit.com>
> *Cc: *openstack-operators <openstack-operators at lists.openstack.org>
> *Subject: *Re: [Openstack-operators] Inverted drive letters on block
> devices that use virtio-scsi
>
>
>
> Yea, the configdrive is a non-issue for us since we don’t use those. The
> multi-drive issue is the only one really affecting us. While removing the
> second drive and reattaching it after boot is probably a good solution, I
> think it’s likely the issue will come back after a hard reboot or
> migration. Probably better to wait before I start converting my multi-disk
> instances to virtio-scsi. If I am not mistaken, this should also be an
> issue in Pike and master, right?
>
>
>
> Jean-Philippe Méthot
>
> Openstack system administrator
>
> Administrateur système Openstack
>
> PlanetHoster inc.
>
>
>
>
>
>
>
>
>
> Le 26 janv. 2018 à 14:23, Logan V. <logan at protiumit.com> a écrit :
>
>
>
> There is a small patch in the bug which resolves the config drive
> ordering. Without that patch I don't know of any workaround. The
> config drive will always end up first in the boot order and the
> instance will always fail to boot in that situation.
>
> For the multi-volume instances where the boot volume is out of order,
> I don't know of any patch for that. One workaround is to detach any
> secondary data volumes from the instance, and then reattach them after
> booting from the one and only attached boot volume.
>
> Logan
>
> On Thu, Jan 25, 2018 at 10:21 PM, Jean-Philippe Méthot
> <jp.methot at planethoster.info> wrote:
>
> Thank you, it indeed seems to be the same issue. I will be following this
> bug report. A shame too, because we were waiting for the patch to allow us
> to setup 2 drives on virtio-scsi before starting to make the change. In the
> meantime, have you found a way to circumvent the issue? Could it be as easy
> as changing the drive order in the database?
>
>
> Jean-Philippe Méthot
> Openstack system administrator
> Administrateur système Openstack
> PlanetHoster inc.
>
>
>
>
> Le 26 janv. 2018 à 13:06, Logan V. <logan at protiumit.com> a écrit :
>
> https://bugs.launchpad.net/nova/+bug/1729584
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20180126/9cd8c3f8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fstab_dev_to_uuid.py
Type: text/x-python-script
Size: 1848 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20180126/9cd8c3f8/attachment.bin>