[libvirt-users] libvirtd not accepting connections

[Michael C Cambria]

On 06/05/2017 10:46 AM, Martin Kletzander wrote:
> On Sun, Jun 04, 2017 at 06:42:39PM -0400, Michael C Cambria wrote:
>> I've upgraded from Fedora 20; probably missed a merge of rpmnew with
>> existing .conf; permission problem, some other mistake along the way to
>> Fedora 25.
>>
>
> Yeah, probably some 'rpm -qV' (or whatever the command to verify all
> packages is) could help as well.

"rpm -aV" didn't turn up anything obvious:

S.5....T.  c /etc/libvirt/libvirtd.conf was modified for logging:
# diff libvirtd.conf libvirtd.conf.rpmnew
1,4d0
< log_level = 1
< log_filters="1:remote 1:event 1:json 1:rpc 1:qemu"
< log_outputs="1:file:/var/log/libvirt/libvirtd.log"
< #
#

>> Is there a "how to" similar to [1] that lets one qemu to log that it was
>> invoked and how far it got?
>>
>> I removed qemu (dnf remote qemu; sudo dnf remove qemu-common)
>> build qemu 2.2-maint (assuming this relates to 2:2.7.1-6.fc25) from
>> github sources
>> installed qemu from sources (into /usr/local/bin)
>>
>> Things are a bit better.  Where something like "sudo virsh pool-list"
>> would just hang before, now my storage pools actually are listed.  No
>> luck listing my VM's, but "virsh list" and "virsh list --all" do not
>> hang like before:
>>
>> # virsh list
>
> Are you sure you didn't miss the --all?
>
Yes I'm sure.  I wish that was all it was <g>

>>  Id    Name State
>> ----------------------------------------------------
>>
>> # virsh pool-list
>>  Name                 State      Autostart
>> -------------------------------------------
>>  default              active     yes
>>  Downloads            active     yes
>>  guest_images_lvm     active     yes
>>
>> #
>>
>> VM xml is /etc/libvirt/qemu.  The network, virbr0 is in
>> /etc/libvirt/qemu/networks, and that gets created just fine. All have
>> root:root owner:group:
>>
>
> The VMs are not visible because the XML cannot be parsed if the binaries
> are not on the system (the XML contains the whole path).  Also, I think
> this works because libvirt doesn't look into /usr/local/bin, but I might
> be wrong.  Check whether 'virsh capabilities' tells you something about
> any emulator.
>
> You can try installing from source, but putting it in /usr/bin, 


I put qemu-system-x86_64 and qemu-x86_64 in /usr/bin as requested. No 
luck.  It seems /usr/local/bin/qemu-xxx is found (see CGroup: output)

$ sudo systemctl status libvirtd.service
● libvirtd.service - Virtualization daemon
    Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; 
vendor preset: enabled)
    Active: active (running) since Mon 2017-06-05 18:21:20 EDT; 3s ago
      Docs: man:libvirtd(8)
            http://libvirt.org
  Main PID: 7076 (libvirtd)
     Tasks: 19 (limit: 4915)
    Memory: 124.7M
       CPU: 3.649s
    CGroup: /system.slice/libvirtd.service
            ├─7076 /usr/sbin/libvirtd
            └─7208 /usr/local/bin/qemu-system-sh4eb -S -no-user-config 
-nodefaults -nographic -M none -qmp 
unix:/var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait 
-pidfile /var/lib/libvirt/qemu/capabi

$ sudo virsh list --all
  Id    Name                           State
----------------------------------------------------

$ sudo virsh pool-list
  Name                 State      Autostart
-------------------------------------------
  default              active     yes
  Downloads            active     yes
  guest_images_lvm     active     yes

$

> you can
> also remove that installation, put back the one from the package and try
> running:
>
>  { for i in qmp_capabilities query-commands quit; do echo
>  "{'execute':'$i'}"; done } | qemu-system-x86_64 -nographic -nodefaults
>  -no-user-config -M none -qmp stdio
>
> And see whether the QEMU process quits, what it outputs and if it gets
> stuck, you can attach gdb and see what it's waiting for.  Or maybe try
> running it with strace.

This completed almost instantly.

> You can also do a thing I used to do a lot.  You can rename
> /usr/bin/qemu-system-x86_64 (for example) and create a script with that
> filename that for example execs as qemu in strace with the output of
> strace put in some file, or similar.  I can't think of anything else for
> now, sorry.

I'll try this ASAP.   First I'll look at all the QEMU_MONITOR_* log 
entries that contain "error" that I *am* getting with qemu installed 
from source (in /usr/local/bin/qemu-*)

2017-06-05 23:06:39.884+0000: 15559: info : 
virEventPollDispatchHandles:506 : EVENT_POLL_DISPATCH_HANDLE: watch=11 
events=1
2017-06-05 23:06:39.884+0000: 15559: info : virObjectRef:296 : 
OBJECT_REF: obj=0x7f0a603d33b0
2017-06-05 23:06:39.884+0000: 15559: info : qemuMonitorIOProcess:429 : 
QEMU_MONITOR_IO_PROCESS: mon=0x7f0a603d33b0 buf={"id": "libvirt-41", 
"error": {"class": "GenericError", "desc": "this feature or command is 
not currently supported"}}^M
  len=120
2017-06-05 23:06:39.884+0000: 15559: debug : 
qemuMonitorJSONIOProcessLine:191 : Line [{"id": "libvirt-41", "error": 
{"class": "GenericError", "desc": "this feature or command is not 
currently supported"}}]
2017-06-05 23:06:39.884+0000: 15559: debug : virJSONValueFromString:1604 
: string={"id": "libvirt-41", "error": {"class": "GenericError", "desc": 
"this feature or command is not currently supported"}}
2017-06-05 23:06:39.884+0000: 15559: debug : 
virJSONParserHandleStartMap:1478 : parser=0x7ffe4440afd0


> Have a nice day,
> Martin
>
Thank you, you too!