Bug 1784040

Summary: Misleading error message after successful completion of live migration with secure data transfer(tls )
Product: Red Hat Enterprise Linux Advanced Virtualization Reporter: Paras Babbar <pbabbar>
Component: libvirtAssignee: Peter Krempa <pkrempa>
Status: CLOSED ERRATA QA Contact: Fangge Jin <fjin>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 8.0CC: chhu, dasmith, dyuan, eglynn, fjin, jdenemar, jhakimra, jsuchane, kchamart, lmen, lyarwood, mschuppe, rbalakri, sbauza, sgordon, vromanso, xuzhang
Target Milestone: rcKeywords: Triaged
Target Release: 8.0Flags: pm-rhel: mirror+
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: libvirt-6.2.0-1.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-17 17:46:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Live migration on tls everywhere envornment with misleading error for both the compute nodes none

Description Paras Babbar 2019-12-16 14:51:25 UTC 
Created attachment 1645613 [details]
Live migration on tls everywhere envornment with misleading error for both the compute nodes

Description of problem:
There is an error appeared in libvirtd.log on tls everywhere job which mislead the user if he tries to dig deeper and look at the libvirtd.logs and may get confused.

I would recommend fixing this and don't show it at the 'error' level if it's not actually an error.

Version-Release number of selected component (if applicable):
RHOS 16 TLS everywhere environment.

How reproducible:
Every-time when you do a live migration using secure data tx(tls) and check the libvirtd.logs

Steps to Reproduce:
1.Deploy tls everywhere job
2.Do live migration
3.validate the logs despite of successful message in nova log , you will see error in libvirtd logs showing something like this "'libvirt_migrate-secret0' not found"

Actual results:
> 2019-12-09 10:13:23.079+0000: 1046555: info : qemuMonitorSend:1072 : QEMU_MONITOR_SEND_MSG: mon=0x7fb78c031230 msg={"execute":"object-del","arguments":{"id":"libvirt_migrate-secret0"},"id":"libvirt-287"}
> 2019-12-09 10:13:23.080+0000: 1046489: info : qemuMonitorJSONIOProcessLine:242 : QEMU_MONITOR_RECV_REPLY: mon=0x7fb78c031230 reply={"id": "libvirt-287", "error": {"class": "GenericError", "desc": "object 'libvirt_migrate-secret0' not found"}}

Expected results:
No error

Additional info:
Comment 2 Peter Krempa 2020-03-19 09:22:16 UTC 
Fixed upstream:
    
commit 64ed4d00c4c04c462aa19426797f2c949ca1cbc8
Author: Peter Krempa <pkrempa>
Date:   Wed Mar 18 12:24:40 2020 +0100

    qemu: Suppress error reporting from qemuMonitorDelObject in cleanup paths
    
    Many calls of qemuMonitorDelObject don't actually check the return value
    or report the error from the object deletion itself since they are on
    cleanup paths. In some cases this can lead to reporting of spurious
    errors e.g. when qemuMonitorDelObject is used to clean up a possibly
    pre-existing objects.
    
    Add a new argument for qemuMonitorDelObject which controls whether
    the internals report errors from qemu and fix all callers accordingly.
    
    Note that some of the cases on device unplug which check the error code
    don't in fact propagate the error to the user, but in this case it is
    important to add the log entry anyways for tracing that the device
    deletion failed.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1784040
    
    Signed-off-by: Peter Krempa <pkrempa>
    Reviewed-by: Michal Privoznik <mprivozn>

commit 103bfbfd74c91de2e31711b8444b89b5834718e2
Author: Peter Krempa <pkrempa>
Date:   Wed Mar 18 11:08:58 2020 +0100

    qemuMonitorJSONCheckError: Allow suppressing of error reporting
    
    In some cases we'll need to check whether there was an error but avoid
    reporting an actual libvirt error. Rename qemuMonitorJSONCheckError to
    qemuMonitorJSONCheckErrorFull with a new flag to suppress the error
    reporting and add a wrapper with the original name so that callers don't
    need to be fixed.
    
    Signed-off-by: Peter Krempa <pkrempa>
    Reviewed-by: Michal Privoznik <mprivozn>

commit cda31f3dba6264922451cd799063652aca444f4e
Author: Peter Krempa <pkrempa>
Date:   Wed Mar 18 10:34:32 2020 +0100

    qemuMonitorJSONCheckError: Use g_autofree
    
    Eliminate cleanup code by using g_autofree.
    
    Signed-off-by: Peter Krempa <pkrempa>
    Reviewed-by: Michal Privoznik <mprivozn>

commit 9633dfbcfc8b16d411b52bfab7e743ce466b175a
Author: Peter Krempa <pkrempa>
Date:   Wed Mar 18 10:29:41 2020 +0100

    qemuMonitorJSON(Add|Del)Object: Refactor cleanup
    
    Use 'g_autoptr' and remove the cleanup label and ret variable.
    
    Signed-off-by: Peter Krempa <pkrempa>
    Reviewed-by: Michal Privoznik <mprivozn>
Comment 5 Fangge Jin 2020-06-16 02:56:28 UTC 
Try to verify with libvirt-6.4.0-1.module+el8.3.0+6881+88468c00.x86_64, got below error:

# virsh migrate rhel7-min qemu+ssh://10.0.138.168/system --live --verbose --p2p --tls
error: internal error: unable to execute QEMU command 'object-add': Unable to access credentials /etcpki/qemu/ca-cert.pem: No such file or directory
Comment 6 Fangge Jin 2020-06-16 07:34:06 UTC 
Verify with libvirt-6.4.0-1.module+el8.3.0+6881+88468c00.x86_64, do encrypted migration, there is no such error log.

error : qemuMonitorJSONCheckError:412 : internal error: unable to execute QEMU command 'object-del': object 'objlibvirt_migrate_tls0' not found
Comment 9 errata-xmlrpc 2020-11-17 17:46:15 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 (virt:8.3 bug fix and enhancement update), 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://access.redhat.com/errata/RHBA-2020:5137