> On Jan 25, 2018, at 21:23, Logan V. wrote:
>
> 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 situa
to:lo...@protiumit.com>>
*Cc: *openstack-operators mailto:openstack-operators@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.
T
n-Philippe Méthot
> *Date: *Friday, 26 January 2018 at 07:28
> *To: *"Logan V."
> *Cc: *openstack-operators
> *Subject: *Re: [Openstack-operators] Inverted drive letters on block
> devices that use virtio-scsi
>
>
>
> Yea, the configdrive is a non-issue for us
at install time though
but it addresses booting order problems.
Tim
From: Jean-Philippe Méthot
Date: Friday, 26 January 2018 at 07:28
To: "Logan V."
Cc: openstack-operators
Subject: Re: [Openstack-operators] Inverted drive letters on block devices that
use virtio-scsi
Yea, the c
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
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 volu
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
If you are running Ocata or later, please see
https://bugs.launchpad.net/nova/+bug/1729584
There seems to be a broken series of patches related to virtio-scsi
that were backported to Ocata resulting in some unresolved virtio-scsi
drive ordering bugs. I see it primarily on virtio-scsi based instanc
Hi,
Lately, we’ve been converting our VMs block devices (cinder block devices) to
use the virtio-scsi driver instead of virtio-blk by modifying the database.
This works great, however, we’ve run into an issue with an instance that has
more than one drive. Essentially, the root device has addres
