yahoo-eng-team team mailing list archive

["eblock@xxxxxx" <eblock@xxxxxx>]

Public bug reported:

Referring to Liberty, Compute runs with xen hypervisor:

When trying to boot an instance from volume via Horizon, the VM fails to spawn because of an invalid block device mapping. I found a cause for that in a default initial "device_name=vda" in the file /srv/www/openstack-dashboard/openstack_dashboard/dashboards/project/instances/workflows/create_instance.py.
Log file nova-compute.log reports 
"Ignoring supplied device name: /dev/vda"

, but in the next step it uses it anyway and says

"Booting with blank volume at /dev/vda".

To test my assumption, I blanked the device_name and edited the array dev_mapping_2 to only append device_name if it's not empty. That works perfectly for Booting from Horizon and could be one way to fix this.
But if you use nova boot command, you can still provide (multiple) device names, for example if you launch an instance and attach a blank volume.

It seems that libvirt is indeed ignoring the supplied device name, but
only if it's not the root device. If I understand correctly, a user-
supplied device_name should also be nulled out for root_device_name and
picked by libvirt, if it's not valid. And also the default value for
device_name in Horizon dashboard should be None. If there is one
supplied, it should be processed and probably validated by libvirt.

Steps to reproduce from Horizon:
Use Xen as hypervisor

1. Go to the Horizon dashboard and launch an instance
2. Select "Boot from image (creates a new volume)" as Instance Boot Source

Expected result:
Instance starts with /dev/xvda as root device.

Actual result:
Build of instance fails, nova-compute.log reports 
"BuildAbortException: Build of instance c15f3344-f9e3-4853-9c18-ea8741563205 aborted: Block Device Mapping is Invalid"

Steps to reproduce from nova cli:

1. Launch an instance from command line via
nova boot --flavor 1 --block-device source=image,id=IMAGE_ID,dest=volume,size=1,shutdown=remove,bootindex=0,device=vda  --block-device source=blank,dest=volume,size=1,shutdown=remove,device=vdb VM

Expected result:
Instance starts with /dev/xvda as root device.

Actual result:
Build of instance fails, device name for vdb is ignored and replaced correctly, but the root device is not.

** 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/1560965

Title:
  libvirt selects wrong root device name

Status in OpenStack Compute (nova):
  New

Bug description:
  Referring to Liberty, Compute runs with xen hypervisor:

  When trying to boot an instance from volume via Horizon, the VM fails to spawn because of an invalid block device mapping. I found a cause for that in a default initial "device_name=vda" in the file /srv/www/openstack-dashboard/openstack_dashboard/dashboards/project/instances/workflows/create_instance.py.
  Log file nova-compute.log reports 
  "Ignoring supplied device name: /dev/vda"

  , but in the next step it uses it anyway and says

  "Booting with blank volume at /dev/vda".

  To test my assumption, I blanked the device_name and edited the array dev_mapping_2 to only append device_name if it's not empty. That works perfectly for Booting from Horizon and could be one way to fix this.
  But if you use nova boot command, you can still provide (multiple) device names, for example if you launch an instance and attach a blank volume.

  It seems that libvirt is indeed ignoring the supplied device name, but
  only if it's not the root device. If I understand correctly, a user-
  supplied device_name should also be nulled out for root_device_name
  and picked by libvirt, if it's not valid. And also the default value
  for device_name in Horizon dashboard should be None. If there is one
  supplied, it should be processed and probably validated by libvirt.

  Steps to reproduce from Horizon:
  Use Xen as hypervisor

  1. Go to the Horizon dashboard and launch an instance
  2. Select "Boot from image (creates a new volume)" as Instance Boot Source

  Expected result:
  Instance starts with /dev/xvda as root device.

  Actual result:
  Build of instance fails, nova-compute.log reports 
  "BuildAbortException: Build of instance c15f3344-f9e3-4853-9c18-ea8741563205 aborted: Block Device Mapping is Invalid"

  Steps to reproduce from nova cli:

  1. Launch an instance from command line via
  nova boot --flavor 1 --block-device source=image,id=IMAGE_ID,dest=volume,size=1,shutdown=remove,bootindex=0,device=vda  --block-device source=blank,dest=volume,size=1,shutdown=remove,device=vdb VM

  Expected result:
  Instance starts with /dev/xvda as root device.

  Actual result:
  Build of instance fails, device name for vdb is ignored and replaced correctly, but the root device is not.

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