Bug 1330557 - [z-stream clone - 3.6.6] In RHEL7, VDSM is no longer calling _destroyVmForceful() if SIGTERM fails
Summary: [z-stream clone - 3.6.6] In RHEL7, VDSM is no longer calling _destroyVmForcef...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 3.5.7
Hardware: Unspecified
OS: Linux
high
high
Target Milestone: ovirt-3.6.6
: 3.6.6
Assignee: Francesco Romani
QA Contact: sefi litmanovich
URL:
Whiteboard:
Depends On: 1309884
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-26 13:02 UTC by rhev-integ
Modified: 2019-12-01 09:20 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1309884
Environment:
Last Closed: 2016-09-28 04:52:20 UTC
oVirt Team: Virt
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:1112 normal SHIPPED_LIVE vdsm 3.6.6 bug fix and enhancement update 2016-06-27 14:01:55 UTC
oVirt gerrit 53747 master MERGED vm: destroy: try harder destroying a Vm 2016-04-26 13:03:01 UTC
oVirt gerrit 53931 master MERGED virt: clean and modernize the destroy() path 2016-04-26 13:03:01 UTC
oVirt gerrit 53932 master MERGED virt: extract destroyVm helper 2016-04-26 13:03:01 UTC
oVirt gerrit 55224 master MERGED vm: destroy: retry to gracefully destroy 2016-04-26 13:03:01 UTC
oVirt gerrit 55533 ovirt-3.6 MERGED vm: use response module in the destroy path 2016-04-26 13:03:01 UTC
oVirt gerrit 55534 ovirt-3.6 MERGED virt: clean and modernize the destroy() path 2016-04-26 13:03:01 UTC
oVirt gerrit 55535 ovirt-3.6 MERGED virt: extract destroyVm helper 2016-04-26 13:03:01 UTC
oVirt gerrit 55536 ovirt-3.6 MERGED vm: destroy: try harder destroying a Vm 2016-04-26 13:03:01 UTC
oVirt gerrit 55537 ovirt-3.6 ABANDONED vm: destroy: retry to gracefully destroy 2016-04-26 13:03:01 UTC

Comment 2 sefi litmanovich 2016-05-01 15:39:07 UTC
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@redhat.com 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

Comment 3 Francesco Romani 2016-05-04 09:09:07 UTC
I don't think this issue deserves a doc fix: it is supposed to just work.

Comment 5 errata-xmlrpc 2016-05-25 12:02:53 UTC
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


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