Created attachment 366594 [details] Proposed patch Description of problem: When using "xen+ssh://" to connect to a el53 host from a el54, dominfo will raise an error "error: unknown procedure: 122". Version-Release number of selected component (if applicable): libvirt-0.6.3 How reproducible: Always Steps to Reproduce: Query a domain on a el53 host from el54 host: [root@rhel54 ~]# virsh --connect xen+ssh://rhel53 dominfo guest_dom Actual results: [root@rhel54 ~]# virsh --connect xen+ssh://rhel53 dominfo guest_dom root@rhel53's password: Id: 1 Name: guest_dom UUID: 111111111-1111-1111-1111-111111111111 OS Type: linux State: idle CPU(s): 1 CPU time: 6.8s Max memory: 1024000 kB Used memory: 1023888 kB error: unknown procedure: 122 <---- error message Expected results: [root@rhel54 ~]# virsh --connect xen+ssh://rhel53 dominfo guest_dom root@rhel53's password: Id: 1 Name: guest_dom UUID: 111111111-1111-1111-1111-111111111111 OS Type: linux State: idle CPU(s): 1 CPU time: 6.8s Max memory: 1024000 kB Used memory: 1023888 kB error: unknown procedure: 122 <---- error message Additional info: The error comes from the security model that is not supported in previous versions. It appears that the code in virsh does check for the error VIR_ERR_NO_SUPPORT and would quietly ignore the error: /* Security model and label information */ memset(&secmodel, 0, sizeof secmodel); if (virNodeGetSecurityModel(ctl->conn, &secmodel) == -1) { if (last_error->code != VIR_ERR_NO_SUPPORT) { virDomainFree(dom); return FALSE; } But virNodeGetSecurityModel() does not set the VIR_ERR_NO_SUPPORT error in that case. call() is able to report that the procedure is not supported, but the flag REMOTE_CALL_QUIET_MISSING_RPC has to be set, which is not the case in remoteNodeGetSecurityModel() from src/remote_internal.c The proposed patch attached does 2 things: 1) Use the REMOTE_CALL_QUIET_MISSING_RPC in remoteNodeGetSecurityModel() 2) Check for the return value of call() and set the VIR_ERR_NO_SUPPORT error if call() returned -2 (which is the value returned if the remote procedure is missing) This way, virsh correctly detects that the remote system does not support the security model and ignores the error.
Hmm, I'm not sure that the REMOTE_CALL_QUIET_MISSING_RPC flag is the right way to approach this here. That flag was intended for the case where we don't want to raise an error at all. I wonder if instead we should simply turn all cases of 'unknown procedure' into VIR_ERR_NO_SUPPORT automatically. That would make all the existing checks 'just work'.
Created attachment 379786 [details] A more generic and simpler patch This patch does the automatic change of turning unknown procedure RPC errors into VIR_ERR_NO_SUPPORT ones, it modifies the routine for server error catching that condition and just modifying the error code, works well for me: [root@test2 ~]# /u/veillard/rpms/BUILD/libvirt-0.6.3/src/virsh --connect xen+ssh://test3 dominfo test5 Id: 1 Name: test5 UUID: 62cd4e2e-5117-e4ba-2dbf-68a37031c3e4 OS Type: linux State: idle CPU(s): 1 CPU time: 253.5s Max memory: 524288 kB Used memory: 524144 kB [root@test2 ~]#
Posted the equivalent patch upstream https://www.redhat.com/archives/libvir-list/2009-December/msg00674.html also include a fix to avoid a potential NULL pointer dereference Daniel
libvirt-0.6.3-26.el5 has been built into dist-5E-qu-candidate with the fix Daniel
The bug has been fixed in libvirt-0.6.3-28.el5 I tried to connect to remote hyervisor on RHEL5.3 released using "virsh --connect xen+ssh://RHEL5.3 dominfo Domain-0" with libvirt-0.6.3-25.el5, it reported: Id: 0 Name: Domain-0 UUID: 00000000-0000-0000-0000-000000000000 OS Type: linux State: running CPU(s): 4 CPU time: 245.9s Max memory: no limit Used memory: 3577856 kB error: unknown procedure: 122 then, updated libvirt version to libvirt-0.6.3-28.el5, tried it again, the output is: Id: 0 Name: Domain-0 UUID: 00000000-0000-0000-0000-000000000000 OS Type: linux State: running CPU(s): 4 CPU time: 246.5s Max memory: no limit Used memory: 3577856 kB
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0205.html