Verified on rhevm-3.6.6-0.1.el6.noarch. Host RHEL 7.2 with vdsm-4.17.27-0.el7ev.noarch. Verified according to steps mentioned in comment by gwatson on February 18 at 22:48:14, 2016 on the original bug with gdb. The output after adding debug messages like gwatson did, from tailf /var/log/vdsm/vdsm.log|egrep 'estroy|ailed to' --color: jsonrpc.Executor/4::DEBUG::2016-05-01 18:31:11,955::__init__::503::jsonrpc.JsonRpcServer::(_serveRequest) Calling 'VM.destroy' in bridge with {u'vmID': u'5b1d76a5-d320-4825-8f98-47e0c1ab1586'} jsonrpc.Executor/4::INFO::2016-05-01 18:31:11,955::API::342::vds::(destroy) vmContainerLock acquired by vm 5b1d76a5-d320-4825-8f98-47e0c1ab1586 jsonrpc.Executor/4::DEBUG::2016-05-01 18:31:11,955::vm::3958::virt.vm::(destroy) vmId=`5b1d76a5-d320-4825-8f98-47e0c1ab1586`::destroy Called jsonrpc.Executor/4::DEBUG::2016-05-01 18:31:11,964::vm::3913::root::(_destroyVmGraceful) GFW: In _destroyVmGraceful jsonrpc.Executor/4::DEBUG::2016-05-01 18:32:03,078::vm::3922::root::(_destroyVmGraceful) GFW: In _destroyVmGracfeul else jsonrpc.Executor/4::WARNING::2016-05-01 18:32:03,078::vm::3925::virt.vm::(_destroyVmGraceful) vmId=`5b1d76a5-d320-4825-8f98-47e0c1ab1586`::Failed to destroy VM '5b1d76a5-d320-4825-8f98-47e0c1ab1586' gracefully (error=38) jsonrpc.Executor/4::DEBUG::2016-05-01 18:32:03,078::vm::3926::root::(_destroyVmGraceful) GFW: libvirt error code = 38 jsonrpc.Executor/4::DEBUG::2016-05-01 18:32:03,079::vm::3935::root::(_destroyVmForceful) GFW: In _destroyVmForceful jsonrpc.Executor/4::DEBUG::2016-05-01 18:32:28,609::vm::3955::virt.vm::(deleteVm) vmId=`5b1d76a5-d320-4825-8f98-47e0c1ab1586`::Total desktops after destroy of 5b1d76a5-d320-4825-8f98-47e0c1ab1586 is 0 jsonrpc.Executor/4::DEBUG::2016-05-01 18:32:28,609::__init__::533::jsonrpc.JsonRpcServer::(_serveRequest) Return 'VM.destroy' in bridge with True libvirtEventLoop::DEBUG::2016-05-01 18:32:28,616::vm::829::virt.vm::(saveState) vmId=`5b1d76a5-d320-4825-8f98-47e0c1ab1586`::saveState after cleanup for status=Powering down destroyed=True libvirtEventLoop::DEBUG::2016-05-01 18:32:28,616::vm::829::virt.vm::(saveState) vmId=`5b1d76a5-d320-4825-8f98-47e0c1ab1586`::saveState after cleanup for status=Down destroyed=True jsonrpc.Executor/2::DEBUG::2016-05-01 18:32:30,632::__init__::503::jsonrpc.JsonRpcServer::(_serveRequest) Calling 'VM.destroy' in bridge with {u'vmID': u'5b1d76a5-d320-4825-8f98-47e0c1ab1586'} jsonrpc.Executor/2::INFO::2016-05-01 18:32:30,632::API::342::vds::(destroy) vmContainerLock acquired by vm 5b1d76a5-d320-4825-8f98-47e0c1ab1586
I don't think this issue deserves a doc fix: it is supposed to just work.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-1112.html