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:
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>
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
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
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