[libvirt-users] libvirtd not accepting connections
Martin Kletzander
mkletzan at redhat.com
Tue Jun 6 14:08:31 UTC 2017
On Tue, Jun 06, 2017 at 08:17:07AM -0400, Michael C. Cambria wrote:
>
>
>On 06/06/2017 04:43 AM, Martin Kletzander wrote:
>> On Mon, Jun 05, 2017 at 07:52:58PM -0400, Michael C Cambria wrote:
>>>
>>>
>>> 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
>>>
>>
>> So this is now only with the qemu from source installed on the system?
>
>Correct.
>>
>>> $ 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.
>>>
>>
>> And that is with the QEMU installed form the package, right?
>
>Correct
>
>>
>>>> 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
>>
>> Well, at least QEMU_MONITOR_ messages are showing, finally. The non-x86
>> machines might be missing lot of commands that libvirt needs. Like
>> 'query-commands' which we need to know which commands we can run (bit of
>> a catch 22 right there). But these should not happen with x86, x86_64,
>> arm, arm64 (or aarch64), and few others. Those are being maintained
>> continuously.
>
>The messages only show when qemu is "sudo make install" from sources.
>
And what are they related to? Can you post the full log somewhere and
send a link to it? I'll see if there's something usable.
>In case it matters, all my existing VM's are x86_64.
>
>>> 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!
>>>
>>>
>>> _______________________________________________
>>> libvirt-users mailing list
>>> libvirt-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/libvirt-users
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20170606/6b6b8740/attachment.sig>
More information about the libvirt-users
mailing list