Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 626334 - [vdsm] [libvirt] vdsm should produce an error in case libvirt fails to eject\change 'cd'
[vdsm] [libvirt] vdsm should produce an error in case libvirt fails to eject\...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: vdsm (Show other bugs)
6.1
All Linux
high Severity medium
: rc
: ---
Assigned To: Dan Kenigsberg
Haim
:
Depends On: 626305
Blocks: 632984
  Show dependency treegraph
 
Reported: 2010-08-23 04:33 EDT by Haim
Modified: 2014-01-12 19:47 EST (History)
7 users (show)

See Also:
Fixed In Version: vdsm-4.9-15.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-19 11:07:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Haim 2010-08-23 04:33:32 EDT
Description of problem:

we just found a bug (behaviour - described in 626324) in libvirt which do not use force eject, that results a regression from our side, as in case image was mounted on guest machine, it will fail in the change\eject operation, and would produce an exception in GUI. 

This bug should be solved on all layers, meaning, libvirt should expose a way in their API to ask for force eject, which is an RFE, thus, vdsm should produce valid error message to GUI in case it fails. 

I assume backend has work here as well, though lets start with vdsm 

repro steps: see BZ 626324.
Comment 1 Haim 2010-08-23 04:34:59 EDT
2.6.32-63.el6.x86_64
libvirt-0.8.1-25.el6.x86_64
vdsm-4.9-13.el6.x86_64
device-mapper-multipath-0.4.9-25.el6.x86_64
lvm2-2.02.72-7.el6.x86_64
qemu-kvm-0.12.1.2-2.109.el6.x86_6
Comment 3 Haim 2010-09-27 07:44:58 EDT
Dan, it looks like behavior is now correct from vdsm perspective; however, I don't get any message from backend\frontend. 
do you think we should open a different bug for it ? 


Thread-3763::DEBUG::2010-09-27 14:10:29,985::clientIF::39::vds::(wrapper) [10.35.70.2]::call changeCD with ('75741acb-ad1c-4082-b80e-1aea87dbbcb4', '/rhev/data-center/6d511a8e-4cc5-49bc-b39d-28ceac510996/d7b8cd6e-
7e11-425b-b03f-83f5e721ea87/images/11111111-1111-1111-1111-111111111111/Fedora-10-x86_64-DVD.iso') {}
Dummy-147::DEBUG::2010-09-27 14:10:30,137::misc::123::Storage.Misc.excCmd::(execCmd) SUCCESS: <err> = '8000+0 records in\n8000+0 records out\n4096000 bytes (4.1 MB) copied, 4.99035 s, 821 kB/s\n'; <rc> = 0
Thread-3763::DEBUG::2010-09-27 14:10:30,777::clientIF::44::vds::(wrapper) return changeCD with {'status': {'message': 'Failed to change disk image', 'code': 41}}
Comment 4 Dan Kenigsberg 2010-09-27 08:04:43 EDT
No need - that's what bug 632984 is for.
Comment 5 Haim 2010-10-25 09:33:03 EDT
verified on vdsm 4.9-20 (there is still an issue with rhevm).
vdsm reports the following error:

Thread-4375::DEBUG::2010-10-25 15:46:12,346::clientIF::45::vds::(wrapper) return changeCD with {'status': {'message': 'Failed to change disk image', 'code': 41
}}


repro steps:

1) run guest in run level 5 
2) change CD and mount any iso 
3) try to change CD

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