Nova raise a confusing error when attaching a volume fail

Bug #1168011 reported by mouadino on 2013-04-11
This bug affects 8 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)

Bug Description

Here is my story:

While i was trying to create a new volume driver for a new network file system, i stumble upon this error each time i try to attach a volume to my instance, DeviceIsBusy("The supplied device (/dev/vdc) is busy.") and while this error was suggeting me to try to use another device /dev/vdc, /dev/vdb and so on, but still all devices was raising the same error, and so to understand more about how and why this error is raised, i took a pick on the relevant part of the code that handle volume attachement, which is this:

    def attach_volume(self, connection_info, instance, mountpoint):
                virt_dom.attachDeviceFlags(conf.to_xml(), flags)
          except Exception, ex:
               if isinstance(ex, libvirt.libvirtError):
                    errcode = ex.get_error_code()
                    if errcode == libvirt.VIR_ERR_OPERATION_FAILED:
                         raise exception.DeviceIsBusy(device=disk_dev)

As everyone can see, the code above basically catch all operation error that libvirt can raise and assume that all of them are the source of a device being busy which is not correct at all.

And as i understood from the git blame, this part of code was added to fix the bug , but didn't take in consideration other bugs that may appear in the future.

So my suggestion is to raise a more general Exception by setting the error message to the same as libvirt.libvirtError which is good enough from what i see:

Messages will be:

 - For bug #914974: operation failed: target vdb already exists
 - For me it's : operation failed: open disk image file failed

If this is a concern for anyone i would like to supply a patch to fix this.


mouadino (mouadino) on 2013-04-11
Changed in nova:
assignee: nobody → mouadino (mouadino)

Fix proposed to branch: master

Changed in nova:
status: New → In Progress
Matt Riedemann (mriedem) on 2013-12-10
Changed in nova:
status: In Progress → New
assignee: mouadino (mouadino) → nobody
tags: added: libvirt
Changed in nova:
importance: Undecided → Low
status: New → Confirmed
Shweta Patil (89shweta) on 2014-05-19
Changed in nova:
assignee: nobody → Shweta Patil (89shweta)
Changed in nova:
assignee: Shweta Patil (89shweta) → tcs_openstack_group (tcs-openstack-group)
assignee: tcs_openstack_group (tcs-openstack-group) → Abhishek Talwar (abhishek-talwar)
Changed in nova:
assignee: Abhishek Talwar (abhishek-talwar) → nobody
Sailaja (sailajap) on 2015-02-18
Changed in nova:
assignee: nobody → Sailaja (sailajap)
Sailaja (sailajap) on 2015-03-24
Changed in nova:
status: Confirmed → In Progress
Sailaja (sailajap) wrote :

Is anyone able to reproduce the bug ?

Dr. Jens Harbott (j-harbott) wrote :

Well, the code in question is still the same, so if you have some kind of error situation where attaching the volume fails, the exception will still get masked as DeviceIsBusy, whatever the original error may be.

Sailaja (sailajap) wrote :

On a Openstack deployed virtual machine,there are only three volumes available,


When I attach a volume to a provisioned instance, e.g
stack@Controller:~$ nova volume-attach e25a8867-ad27-49c0-af2b-207936515a7d b75729c6-fb09-49dc-a0c7-d45e4cc139fe /dev/sda3
ERROR (Conflict): The supplied device path (/dev/sda3) is in use. (HTTP 409) (Request-ID: req-5012d41b-f9fc-49ba-8b88-2d8f3193c621)

Is this a bug to consider,as the device /dev/sda3 does not exist and still the error is , '/dev/sda3 is in use'.

I am not able to reproduce the error 'Device is Busy'.Can anyone let me know how to reproduce the same..

Thanks in advance.

Dr. Jens Harbott (j-harbott) wrote :

/dev/sda3 is not a volume, it is a partion on the block device /dev/sda. You should only use /dev/sda etc. for attaching. And in your example /dev/sda should be in use, /dev/sdb should work.


There are no open reviews for this bug report since more than 2 weeks.
To signal that to other contributors which might provide patches for
this bug, I switch the status from "In Progress" to "Confirmed" and
remove the assignee.
Feel free to add yourself as assignee and to push a review for it.

Changed in nova:
status: In Progress → Confirmed
assignee: Sailaja (sailajap) → nobody
Changed in nova:
assignee: nobody → Sivasathurappan Radhakrishnan (siva-radhakrishnan)

should I use VIR_ERR_RESOURCE_BUSY for DeviceIsBusy exception and create general exception like "Failed to attach volume at mountpoint: %s')" (as it is logged in code) for libvirt.VIR_ERR_OPERATION_FAILED. If somebody can provide a suggestion it would be really useful

Matt Riedemann (mriedem) wrote :

Keep in mind the code in the description is in the compute manager, and the virt driver that's raising the exception may not be the libvirt driver, so you can't bake libvirt-specific things into the error that's being handled in the compute manager code, it will have to be generic enough for other virt drivers to raise the same type of error.

Matt Riedemann (mriedem) wrote :

Sorry, the code in the description is in the libvirt driver, I missed that, it's not the compute manager. Just keep in mind that anything new raised from the virt driver would need to be handled in the compute manager.

Fix proposed to branch: master

Changed in nova:
status: Confirmed → In Progress

Change abandoned by Sean Dague (<email address hidden>) on branch: master
Reason: This review is > 4 weeks without comment, and is not mergable in it's current state. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

Sean Dague (sdague) wrote :

There are no currently open reviews on this bug, changing the status back to the previous state and unassigning. If there are active reviews related to this bug, please include links in comments.

Changed in nova:
status: In Progress → Confirmed
assignee: Sivasathurappan Radhakrishnan (siva-radhakrishnan) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers