Bug 1474837 - Raise DeviceNotFound detaching volume from persistent domain
Raise DeviceNotFound detaching volume from persistent domain
Status: CLOSED DUPLICATE of bug 1424656
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova (Show other bugs)
9.0 (Mitaka)
x86_64 Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Eoghan Glynn
Joe H. Rahme
Depends On:
  Show dependency treegraph
Reported: 2017-07-25 09:29 EDT by fiezzi
Modified: 2017-09-07 15:01 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-07-27 14:16:15 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1633236 None None None 2017-07-25 09:33 EDT
OpenStack gerrit 425114 None None None 2017-07-25 09:32 EDT

  None (edit)
Description fiezzi 2017-07-25 09:29:33 EDT
Description of problem:
Currently, a volume detach at the libvirt driver level happens in two

  1. Detach from persistent domain (affect instance upon next reboot)
  2. Detach from live domain (affect running instance)

A detach from a live domain is a request from the host to the guest,
which the guest can choose to ignore. For example, if the guest
has a file open on the volume by some process, it might ignore the
request to detach that volume because the file is in use.

If this scenario occurs, when a user tries a later request to detach
the volume, it will fail with this error when the attempt to detach
from the persistent domain is made:

  libvirtError: invalid argument: no target device <device>

because the volume was detached from the persistent domain the first
time. Because of this, the volume can only be detached by rebooting
the instance.

Version-Release number of selected component (if applicable):
RH-OSP9 with latest available updates

How reproducible:
 - Create a VM and attach a volume
 - Format the volume and mount it
 - Create any sort of I/O and at the same time try to detach the volume 
Of course, the 3rd point is not a best practice but unfortunately, if you create a Heat Stack with a VM and an attachment procedure, Heat will first detach the volume and then delete the VM. In this situation, the Stack delete operation might fail because the guest refuses to detach the volume.

Actual results:
Sometimes the volume detach fails and a then it is impossible to detach the volume unless a hard reboot is done.

Expected results:
It's fine the guest refuses to detach the Volume but Nova should allow the user to retry the detach operation.

Additional info:
Comment 1 melanie witt 2017-07-27 14:16:15 EDT

*** This bug has been marked as a duplicate of bug 1424656 ***
Comment 2 awaugama 2017-09-07 15:01:32 EDT
Dup -- QE will decide about automating the original

Note You need to log in before you can comment on or make changes to this bug.