yahoo-eng-team team mailing list archive

[sean mooney <sean.k.mooney@xxxxxxxxx>]

Public bug reported:

Description
===========
The hw_disk_bus image metadata key
https://github.com/openstack/glance/blob/master/etc/metadefs/compute-libvirt-image.json#L13-L27
allows users to specify the bus to which guest hard disk images are attched for libvirt instances.

The valid values of hw_disk_bus are
["scsi","virtio","uml","xen","ide","usb","fdc","sata"]

The libvirt driver also defieds the list of valid buses per virt_type
here https://github.com/openstack/nova/blob/ef0ce4d692d28a7f5a0079e24acdbfe7d2767e8b/nova/virt/libvirt/blockinfo.py#L199-L206

   valid_bus = {
        'qemu': ['virtio', 'scsi', 'ide', 'usb', 'fdc', 'sata'],
        'kvm': ['virtio', 'scsi', 'ide', 'usb', 'fdc', 'sata'],
        'xen': ['xen', 'ide'],
        'uml': ['uml'],
        'lxc': ['lxc'],
        'parallels': ['ide', 'scsi']
        }


when setting this key to sata or usb instead of having the disk attached to the requested bus
the disk is attached to the scsi bus instead.

this is because in nova/virt/libvirt/blockinfo.py we map form the disk bus to a prefix
in get_dev_prefix_for_disk_bus
https://github.com/openstack/nova/blob/ef0ce4d692d28a7f5a0079e24acdbfe7d2767e8b/nova/virt/libvirt/blockinfo.py#L124-L143

then later we guess what the correct bus is from the prefix in get_disk_bus_for_disk_dev
https://github.com/openstack/nova/blob/ef0ce4d692d28a7f5a0079e24acdbfe7d2767e8b/nova/virt/libvirt/blockinfo.py#L297-L304

this mapping form disk bus to prefix is lossy as as sata/scsi and usb
are all mapped to the sd prefix. so when we guess in
get_disk_bus_for_disk_dev for kvm that resutin the incorrect value for
images with hw_disk_bus=sata or hw_disk_bus=usb.


Steps to reproduce
==================
run devstack with default setting
source openrc

set hw_disk_bus=sata on image
e.g. openstack image set --property hw_disk_bus=sata my-image

boot a vm with that image
run virsh dumpxml on instance and check the disk bus.


Expected result
===============
instance boots and disk bus used matches hw_disk_bus image metadata value.
e.g. sata

Actual result
=============
instnace boots and disk bus used is sata

Environment
===========
1. Exact version of OpenStack you are running. See the following
  stable/pike but this is present in master and has been an issue for 5 years
  since https://github.com/openstack/nova/commit/7be531fe9462f2b07d4a1abf6687f649d1dfbb89#diff-2701504299cd384f46791e08f1849defR293
incorrectly called get_disk_bus_for_disk_dev instead of useing the disk_bus varible.

2. Which hypervisor did you use?
   Libvirt + KVM
   

2. Which storage type did you use?
   default local image backend for nova.
   
3. Which networking type did you use?
   Neutron with OpenVSwitch.
   not related to this issue.

** Affects: nova
     Importance: Undecided
         Status: 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/1759420

Title:
  nova does not correctly support HW_DISK_BUS=sata or usb for kvm/qemu

Status in OpenStack Compute (nova):
  New

Bug description:
  Description
  ===========
  The hw_disk_bus image metadata key
  https://github.com/openstack/glance/blob/master/etc/metadefs/compute-libvirt-image.json#L13-L27
  allows users to specify the bus to which guest hard disk images are attched for libvirt instances.

  The valid values of hw_disk_bus are
  ["scsi","virtio","uml","xen","ide","usb","fdc","sata"]

  The libvirt driver also defieds the list of valid buses per virt_type
  here https://github.com/openstack/nova/blob/ef0ce4d692d28a7f5a0079e24acdbfe7d2767e8b/nova/virt/libvirt/blockinfo.py#L199-L206

     valid_bus = {
          'qemu': ['virtio', 'scsi', 'ide', 'usb', 'fdc', 'sata'],
          'kvm': ['virtio', 'scsi', 'ide', 'usb', 'fdc', 'sata'],
          'xen': ['xen', 'ide'],
          'uml': ['uml'],
          'lxc': ['lxc'],
          'parallels': ['ide', 'scsi']
          }

  
  when setting this key to sata or usb instead of having the disk attached to the requested bus
  the disk is attached to the scsi bus instead.

  this is because in nova/virt/libvirt/blockinfo.py we map form the disk bus to a prefix
  in get_dev_prefix_for_disk_bus
  https://github.com/openstack/nova/blob/ef0ce4d692d28a7f5a0079e24acdbfe7d2767e8b/nova/virt/libvirt/blockinfo.py#L124-L143

  then later we guess what the correct bus is from the prefix in get_disk_bus_for_disk_dev
  https://github.com/openstack/nova/blob/ef0ce4d692d28a7f5a0079e24acdbfe7d2767e8b/nova/virt/libvirt/blockinfo.py#L297-L304

  this mapping form disk bus to prefix is lossy as as sata/scsi and usb
  are all mapped to the sd prefix. so when we guess in
  get_disk_bus_for_disk_dev for kvm that resutin the incorrect value for
  images with hw_disk_bus=sata or hw_disk_bus=usb.

  
  Steps to reproduce
  ==================
  run devstack with default setting
  source openrc

  set hw_disk_bus=sata on image
  e.g. openstack image set --property hw_disk_bus=sata my-image

  boot a vm with that image
  run virsh dumpxml on instance and check the disk bus.

  
  Expected result
  ===============
  instance boots and disk bus used matches hw_disk_bus image metadata value.
  e.g. sata

  Actual result
  =============
  instnace boots and disk bus used is sata

  Environment
  ===========
  1. Exact version of OpenStack you are running. See the following
    stable/pike but this is present in master and has been an issue for 5 years
    since https://github.com/openstack/nova/commit/7be531fe9462f2b07d4a1abf6687f649d1dfbb89#diff-2701504299cd384f46791e08f1849defR293
  incorrectly called get_disk_bus_for_disk_dev instead of useing the disk_bus varible.

  2. Which hypervisor did you use?
     Libvirt + KVM
     

  2. Which storage type did you use?
     default local image backend for nova.
     
  3. Which networking type did you use?
     Neutron with OpenVSwitch.
     not related to this issue.

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