← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1729584] Re: boot from volume + configdrive with virtio-scsi broken (regression)

 

Reviewed:  https://review.openstack.org/538310
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=2616b384e642b6eb58eef7da87b6e893f25a949e
Submitter: Zuul
Branch:    master

commit 2616b384e642b6eb58eef7da87b6e893f25a949e
Author: Jay Pipes <jaypipes@xxxxxxxxx>
Date:   Fri Jan 26 12:20:35 2018 -0500

    only increment disk address unit for scsi devices
    
    We were erroneously incrementing the disk address unit attribute for
    non-scsi devices, which resulted in inconsistent disk device naming and
    addresses when SCSI devices were used along with non-SCSI devices (like
    configdrive devices).
    
    Also, we ensure that we assign unit number 0 for the boot volume of a
    boot-from-volume instance.
    
    Change-Id: Ia91e2f9c316e25394a0f41dc341d903dfcff6921
    Co-authored-by: Mehdi Abaakouk <sileht@xxxxxxxxxx>
    Closes-bug: #1729584
    Closes-bug: #1753394


** Changed in: nova
       Status: In Progress => Fix Released

-- 
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/1729584

Title:
  boot from volume + configdrive with virtio-scsi broken (regression)

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) ocata series:
  New
Status in OpenStack Compute (nova) pike series:
  New
Status in OpenStack Compute (nova) queens series:
  New

Bug description:
  Hi,

  Since last ocata update (2:15.0.7-0ubuntu1~cloud0) "boot from
  volume"+configdrive is broken.

  The libvirt xml generated looks wrong, on the first scsi disk the
  "unit" is wrong, it's 1 while it must be 0. The VM can't boot, kvm
  start but the boot screen show the "No boot disk found" message.

  
  The wrong xml generated: 

      <disk type='network' device='cdrom'>
        <driver name='qemu' type='raw' cache='none' io='native'/>
        <auth username='openstack-service'>
          <secret type='ceph' uuid='XXXXXXXXXXXXXXXXX'/>
        </auth>
        <source protocol='rbd' name='disks/9029e91c-2c6e-4a83-b71f-4ee1055e51ca_disk.config'>
          <host name='XXX.XXX.XXX.XXX' port='6789'/>
          <host name='XXX.XXX.XXX.XXX' port='6789'/>
          <host name='XXX.XXX.XXX.XXX' port='6789'/>
        </source>
        <target dev='hda' bus='ide'/>
        <readonly/>
        <address type='drive' controller='0' bus='0' target='0' unit='0'/>
      </disk>
      <disk type='network' device='disk'>
        <driver name='qemu' type='raw' cache='none' io='native' discard='unmap'/>
        <auth username='openstack-service'>
          <secret type='ceph' uuid='XXXXXXXXXXXXXXXXX'/>
        </auth>
        <source protocol='rbd' name='ssds/volume-cb74e7c1-bcfc-4b52-b92a-f2750232734d'>
          <host name='XXX.XXX.XXX.XXX' port='6789'/>
          <host name='XXX.XXX.XXX.XXX' port='6789'/>
          <host name='XXX.XXX.XXX.XXX' port='6789'/>
        </source>
        <target dev='sda' bus='scsi'/>
        <serial>cb74e7c1-bcfc-4b52-b92a-f2750232734d</serial>
        <address type='drive' controller='0' bus='0' target='0' unit='1'/>
      </disk>

  As workaround, I have fixed the issue here:

  --- a/nova/virt/libvirt/driver.py       2016-03-21 00:08:47.702778684 +0100
  +++ b/nova/virt/libvirt/driver.py       2016-03-21 00:21:19.877080690 +0100
  @@ -3576,7 +3576,7 @@
                   LOG.debug('Config drive not found in RBD, falling back to the '
                             'instance directory', instance=instance)
           disk_info = disk_mapping[name]
  -        if 'unit' in disk_mapping:
  +        if 'unit' in disk_mapping and disk_info["bus"] == "scsi":
               disk_unit = disk_mapping['unit']
               disk_mapping['unit'] += 1  # Increments for the next disk added
           conf = disk.libvirt_info(disk_info['bus'],

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1729584/+subscriptions


References