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 instances where 1) boot from volume instances with a secondary volume attached, or 2) boot from image volumes where config drive is enabled. Logan On Thu, Jan 25, 2018 at 6:58 PM, Jean-Philippe Méthot <jp.met...@planethoster.info> wrote: > 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 > address <address type='drive' controller='0' bus='0' target='0' unit='1’/> > while the second device has address <address type='drive' controller='0' > bus='0' target='0' unit='0’/> . I believe this results in the root drive > getting called sdb in the vm while the second drive gets called sda. > > If my assumption is right, what exactly controls which drive gets address > unit=0 and which drive gets address unit=1 in the vm configuration? > > > Jean-Philippe Méthot > Openstack system administrator > Administrateur système Openstack > PlanetHoster inc. > > > > > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
