Re: [libvirt-users] Libvirtd freezes
2017-05-01 7:32 GMT+02:00 Michal Privoznik <mpriv...@redhat.com>: > On 04/30/2017 07:12 PM, Stefano Ricci wrote: > >> >> The version used for backtrace is 3.2.0, now I have also tried the >> current downloaded with git but the problem is always present. >> This is the current version log file, set as shown on the DebugLogs page: >> >> https://drive.google.com/open?id=0By9lwQyveHENdEt4aEtZcUV3ZEU > > Couple of my findings: > > 2017-04-30 16:19:34.894+: 870: debug : virDriverLoadModuleFile:49 : Load > module file '/usr/lib/libvirt/storage-backend/libvirt_storage_backend_rbd.so' > 2017-04-30 16:19:35.324+: 870: debug : virDriverLoadModuleFunc:71 : > Lookup function 'virStorageBackendRBDRegister' > > it takes nearly .5s to load libvirt_storage_backend_rbd.so > > But apart from that there is nothing unusual in the logs. So how do you > observe the hang? How long it is anyway - assuming it goes away after some > time. Or does it hang indefinitely? > > BTW: is this all the debug messages you have? Because in there, the last line > is how libvirtd starts qemu-system-x86_64 in order to fetch its capabilities. > I'd expect libvirt setting qmp_capabilities on the monitor at least. > > Michal Virtlib logs end in the way you see, only when i kill the qemu process then it starts logging and it is possible to connect remotely with virsh. Until the qemu process is active you can not use libvirt. In the following libvirt log file find all that happens when killing the qemu process, after the line 2017-05-01 07:40:47.772+: 892: debug : virCommandRunAsync:2451 : Command result 0, with PID 970 https://drive.google.com/open?id=0By9lwQyveHENNVBaczFxNHBCYU0 Stefano ___ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
Re: [libvirt-users] Libvirtd freezes
2017-04-29 7:24 GMT+02:00 Michal Privoznik <mpriv...@redhat.com>:
> On 04/29/2017 04:38 AM, Stefano Ricci wrote:
>> 2017-04-28 14:33 GMT+02:00 Michal Privoznik <mpriv...@redhat.com>:
>>> On 04/27/2017 04:31 PM, Stefano Ricci wrote:
>>>> Here is the backtrace of the libvirt process just started
>>>
>>> [Just a side note, you shouldn't top post on technical lists. Gmail
>>> sucks at this.]
>>>
>>>>
>>>> https://pastebin.com/R66myzFp
>>>
>>> Looks like libvirtd is trying to spawn /usr/bin/qemu-system-x86_64 but
>>> it takes ages to init. In the debug logs you might see the actual
>>> command line that libvirt tries to execute. You can try running it by
>>> hand and see if it takes about the same time. If so, then it's a qemu bug.
>>>
>>> http://wiki.libvirt.org/page/DebugLogs
>>>
>>> Michal
>>
>> The line that comes from the libvirt log is as follows:
>> LC_ALL=C PATH=/bin:/usr/bin:/sbin:/usr/sbin HOME=/ USER=root
>> /usr/bin/qemu-system-x86_64 -S -no-user-config -nodefaults -nographic
>> -M none -qmp
>> unix:/var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait
>> -pidfile /var/lib/libvirt/qemu/capabilities.pidfile -daemonize
>> Before I run the command manually I added the -D parameter to write
>> the qemu process stderr in a log file.
>> Once the command is executed, the log file is blank then error-free
>> and the process seems to respond correctly.
>> I have connected with the following command: nc -U
>> /var/lib/libvirt/qemu/capabilities.monitor.sock
>> and this is an extract of qemu output to my requests:
>> {"QMP": {"version": {"qemu": {"micro": 1, "minor": 8, "major": 2},
>> "package": ""}, "capabilities": []}}
>> { "execute": "qmp_capabilities" }
>> {"return": {}}
>> { "execute": "query-commands" }
>> {"return": [{"name": "xen-set-global-dirty-log"}, {"name":
>> "xen-save-devices-state"}, {"name": "xen-load-devices-state"},
>> {"name": "x-colo-lost-heartbeat"}, {"name":
>> "x-blockdev-remove-medium"}, {"name": "x-blockdev-insert-medium"},
>> {"name": "x-blockdev-del"}, {"name": "x-blockdev-change"}, {"name":
>> "transaction"}, {"name": "trace-event-set-state"}, {"name":
>> "trace-event-get-state"}, {"name": "system_wakeup"}, {"name":
>> "system_reset"}, {"name": "system_powerdown"}, {"name": "stop"},
>> {"name": "set_password"}, {"name": "set_link"}, {"name": "send-key"},
>> {"name": "screendump"}, {"name": "rtc-reset-reinjection"}, {"name":
>> "ringbuf-write"}, {"name": "ringbuf-read"}, {"name": "remove-fd"},
>> {"name": "quit"}, {"name": "query-vnc-servers"}, {"name":
>> "query-vnc"}, {"name": "query-version"}, {"name": "query-uuid"},
>> {"name": "query-tpm-types"}, {"name": "query-tpm-models"}, {"name":
>> "query-tpm"}, {"name": "query-target"}, {"name": "query-status"},
>> {"name": "query-spice"}, {"name": "query-rx-filter"}, {"name":
>> "query-rocker-ports"}, {"name": "query-rocker-of-dpa-groups"},
>> {"name": "query-rocker-of-dpa-flows"}, {"name": "query-rocker"},
>> {"name": "query-pci"}, {"name": "query-named-block-nodes"}, {"name":
>> "query-name"}, {"name": "query-migrate-parameters"}, {"name":
>> "query-migrate-capabilities"}, {"name": "query-migrate-cache-size"},
>> {"name": "query-migrate"}, {"name": "query-mice"}, {"name":
>> "query-memory-devices"}, {"name": "query-memdev"}, {"name":
>> "query-machines"}, {"name": "query-kvm"}, {"name": "query-iothreads"},
>> {"name": "query-hotpluggable-cpus"}, {"name": "query-fdsets"},
>> {"name": "query-events"}, {"name":
>> "query-dump-guest-memory-capability"}, {"name": "query-dump"},
>> {"name": "query-cpus"}, {"name": "query-cpu-definitions"}, {"name":
>> "query-commands"}, {"name": "query-command-line-options"}, {"name":
>> "query-chardev-backends"}, {"name": "query-chardev"}, {"name":
>> "query-blockstats"}, {"name": "query-block-jobs"}, {"name":
>> "query-block"}, {"name": "query-balloon"}, {"name":
>> "query-acpi-ospm-status"}, {"name": "qom-set"}, {"name":
>> "qom-list-types"}, {"name": "qom-list"}, {"name": "qom-get"}, {"name":
>> "qmp_capabilities"}, {"name": "pmemsave"}, {"name": "object-del"},
>> {"name": "object-add"}, {"name": "netdev_del"} ...
>> So it would not look like a qemu bug.
>
> Well, this does not prove that qemu replies to all commands issued by
> libvirt. For that we would need debug logs as referred to above.
>
> BTW: The stack trace looks a bit old (the line number do not match with
> the current git HEAD) - what's the release you're running and does the
> problem occur with the current git HEAD too?
>
> Michal
The version used for backtrace is 3.2.0, now I have also tried the
current downloaded with git but the problem is always present.
This is the current version log file, set as shown on the DebugLogs page:
https://drive.google.com/open?id=0By9lwQyveHENdEt4aEtZcUV3ZEU
Stefano
___
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users
Re: [libvirt-users] Libvirtd freezes
2017-04-28 14:33 GMT+02:00 Michal Privoznik <mpriv...@redhat.com>:
> On 04/27/2017 04:31 PM, Stefano Ricci wrote:
>> Here is the backtrace of the libvirt process just started
>
> [Just a side note, you shouldn't top post on technical lists. Gmail
> sucks at this.]
>
>>
>> https://pastebin.com/R66myzFp
>
> Looks like libvirtd is trying to spawn /usr/bin/qemu-system-x86_64 but
> it takes ages to init. In the debug logs you might see the actual
> command line that libvirt tries to execute. You can try running it by
> hand and see if it takes about the same time. If so, then it's a qemu bug.
>
> http://wiki.libvirt.org/page/DebugLogs
>
> Michal
The line that comes from the libvirt log is as follows:
LC_ALL=C PATH=/bin:/usr/bin:/sbin:/usr/sbin HOME=/ USER=root
/usr/bin/qemu-system-x86_64 -S -no-user-config -nodefaults -nographic
-M none -qmp unix:/var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait
-pidfile /var/lib/libvirt/qemu/capabilities.pidfile -daemonize
Before I run the command manually I added the -D parameter to write
the qemu process stderr in a log file.
Once the command is executed, the log file is blank then error-free
and the process seems to respond correctly.
I have connected with the following command: nc -U
/var/lib/libvirt/qemu/capabilities.monitor.sock
and this is an extract of qemu output to my requests:
{"QMP": {"version": {"qemu": {"micro": 1, "minor": 8, "major": 2},
"package": ""}, "capabilities": []}}
{ "execute": "qmp_capabilities" }
{"return": {}}
{ "execute": "query-commands" }
{"return": [{"name": "xen-set-global-dirty-log"}, {"name":
"xen-save-devices-state"}, {"name": "xen-load-devices-state"},
{"name": "x-colo-lost-heartbeat"}, {"name":
"x-blockdev-remove-medium"}, {"name": "x-blockdev-insert-medium"},
{"name": "x-blockdev-del"}, {"name": "x-blockdev-change"}, {"name":
"transaction"}, {"name": "trace-event-set-state"}, {"name":
"trace-event-get-state"}, {"name": "system_wakeup"}, {"name":
"system_reset"}, {"name": "system_powerdown"}, {"name": "stop"},
{"name": "set_password"}, {"name": "set_link"}, {"name": "send-key"},
{"name": "screendump"}, {"name": "rtc-reset-reinjection"}, {"name":
"ringbuf-write"}, {"name": "ringbuf-read"}, {"name": "remove-fd"},
{"name": "quit"}, {"name": "query-vnc-servers"}, {"name":
"query-vnc"}, {"name": "query-version"}, {"name": "query-uuid"},
{"name": "query-tpm-types"}, {"name": "query-tpm-models"}, {"name":
"query-tpm"}, {"name": "query-target"}, {"name": "query-status"},
{"name": "query-spice"}, {"name": "query-rx-filter"}, {"name":
"query-rocker-ports"}, {"name": "query-rocker-of-dpa-groups"},
{"name": "query-rocker-of-dpa-flows"}, {"name": "query-rocker"},
{"name": "query-pci"}, {"name": "query-named-block-nodes"}, {"name":
"query-name"}, {"name": "query-migrate-parameters"}, {"name":
"query-migrate-capabilities"}, {"name": "query-migrate-cache-size"},
{"name": "query-migrate"}, {"name": "query-mice"}, {"name":
"query-memory-devices"}, {"name": "query-memdev"}, {"name":
"query-machines"}, {"name": "query-kvm"}, {"name": "query-iothreads"},
{"name": "query-hotpluggable-cpus"}, {"name": "query-fdsets"},
{"name": "query-events"}, {"name":
"query-dump-guest-memory-capability"}, {"name": "query-dump"},
{"name": "query-cpus"}, {"name": "query-cpu-definitions"}, {"name":
"query-commands"}, {"name": "query-command-line-options"}, {"name":
"query-chardev-backends"}, {"name": "query-chardev"}, {"name":
"query-blockstats"}, {"name": "query-block-jobs"}, {"name":
"query-block"}, {"name": "query-balloon"}, {"name":
"query-acpi-ospm-status"}, {"name": "qom-set"}, {"name":
"qom-list-types"}, {"name": "qom-list"}, {"name": "qom-get"}, {"name":
"qmp_capabilities"}, {"name": "pmemsave"}, {"name": "object-del"},
{"name": "object-add"}, {"name": "netdev_del"} ...
So it would not look like a qemu bug.
Stefano
___
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users
Re: [libvirt-users] Libvirtd freezes
Here is the backtrace of the libvirt process just started https://pastebin.com/R66myzFp Stefano 2017-04-27 15:12 GMT+02:00 Michal Privoznik <mpriv...@redhat.com>: > On 04/27/2017 03:11 PM, Michal Privoznik wrote: >> On 04/27/2017 02:02 PM, Stefano Ricci wrote: >>> Hello everyone >>> I come back to ask for a hand to solve a problem that has affected me >>> since October 2016 and I have not yet solved using libvirt. >>> I thought I would solve it by going to a 4.9.x kernel with qemu >>> 2.8.1.1 and with libvirt 3.2.0. >>> Compile it all in a stable LFS environment version 7.9 and that all >>> checks pass without errors. >>> The strange thing is that the libvirtd process starts without errors >>> but has arrived at the qemu process launch to understand the system's >>> capabilities freezes until the following process is killed >>> /usr/bin/qemu-system-x86_64 -S -none-user-config -nodefaults >>> -nographic -machine none, accel = kvm: tcg -qmp unix: >>> /var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait-pidfile/var/lib/libvirt/qemu/capabilities.Pidfile >>> -daemonize, since that time libvirtd resumes running and can be used >>> with virsh. >>> Performing qemu independently of libvirt works regularly, creates and >>> runs virtual machines smoothly. >>> >>> Thanks in advance >>> Stefano Ricci >>> >> >> >> I think I've read this somewhere else, but I don't remember where. >> Anyway, my rough guess is that libvirtd is stuck on refreshing the qemu >> capabilities. This is done on the daemon startup and until it finishes, >> no API can be practically executed. Well, for the driver in question (in >> this case qemu). Other driver should work just fine. >> >> Can you please attach debugger and get the backtrace for us? >> >> gdb -p $(pgrep libvirtd) >> >> ... >> ... >> (gdb) bt > > I mean more 't a a bt' which stands for 'thread apply all backtrace' => > get backtrace for all the threads. Thanks. > > Michal ___ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
[libvirt-users] Libvirtd freezes
Hello everyone I come back to ask for a hand to solve a problem that has affected me since October 2016 and I have not yet solved using libvirt. I thought I would solve it by going to a 4.9.x kernel with qemu 2.8.1.1 and with libvirt 3.2.0. Compile it all in a stable LFS environment version 7.9 and that all checks pass without errors. The strange thing is that the libvirtd process starts without errors but has arrived at the qemu process launch to understand the system's capabilities freezes until the following process is killed /usr/bin/qemu-system-x86_64 -S -none-user-config -nodefaults -nographic -machine none, accel = kvm: tcg -qmp unix: /var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait-pidfile/var/lib/libvirt/qemu/capabilities.Pidfile -daemonize, since that time libvirtd resumes running and can be used with virsh. Performing qemu independently of libvirt works regularly, creates and runs virtual machines smoothly. Thanks in advance Stefano Ricci ___ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
Re: [libvirt-users] Fwd: Problems connecting to the libvirtd server
I did more tests and if kill the qemu process without stopping libvirtd and relaunching it with the following command /usr/bin/qemu-system-x86_64 -S --no-user-config -nodefaults -nographic -M none -qmp unix: /var /lib /libvirt /qemu /capabilities.monitor.sock,server, nowait -pidfile /var/lib/libvirt/qemu/capabilities.pidfile -daemonize, then virsh working correctly and connects. The command used to launch qemu is used by libvirtd automatically taken by the ps -a | grep qemu. However checking the status of qemu process with qmp is always in prelaunch and running is false, even when it works. When restart libvirtd back does it still hangs. 2016-10-13 18:08 GMT+02:00 Stefano Ricci <sfn@gmail.com>: > it does still hang. > The strange thing is that I launched qemu, without libvirtd, > independently creating a linux virtual machine, functions regularly > and reading the state with qmp is regularly running. > > Stefano > > 2016-10-13 2:57 GMT+02:00 Michal Privoznik <mpriv...@redhat.com>: >> On 12.10.2016 19:16, Stefano Ricci wrote: >>> I checked with qmp and your consideration was correct, the status of >>> qemu process is in prelaunch and running equals false. >>> But I do not understand why >> >> [Please don't top post on technical lists] >> >> Well, I don't have any idea either. I mean, the daemon logs you provided >> are from the second run of libvirtd. Maybe this is qemu or kernel bug? >> If you kill the stalled process and then start libvirtd again, can you >> connect then or does it still hang? >> >> Michal ___ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
Re: [libvirt-users] Fwd: Problems connecting to the libvirtd server
it does still hang. The strange thing is that I launched qemu, without libvirtd, independently creating a linux virtual machine, functions regularly and reading the state with qmp is regularly running. Stefano 2016-10-13 2:57 GMT+02:00 Michal Privoznik <mpriv...@redhat.com>: > On 12.10.2016 19:16, Stefano Ricci wrote: >> I checked with qmp and your consideration was correct, the status of >> qemu process is in prelaunch and running equals false. >> But I do not understand why > > [Please don't top post on technical lists] > > Well, I don't have any idea either. I mean, the daemon logs you provided > are from the second run of libvirtd. Maybe this is qemu or kernel bug? > If you kill the stalled process and then start libvirtd again, can you > connect then or does it still hang? > > Michal ___ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
Re: [libvirt-users] Fwd: Problems connecting to the libvirtd server
I checked with qmp and your consideration was correct, the status of qemu process is in prelaunch and running equals false. But I do not understand why Stefano 2016-10-12 10:43 GMT+02:00 Michal Privoznik <mpriv...@redhat.com>: > On 12.10.2016 16:06, Stefano Ricci wrote: >>>> -- Forwarded message ------ >>>> From: Stefano Ricci <sfn@gmail.com> >>>> Date: 2016-10-11 12:35 GMT+02:00 >>>> Subject: Re: [libvirt-users] Problems connecting to the libvirtd server >>>> To: Michal Privoznik <mpriv...@redhat.com> >>>> >>> >>> [Please don't top post on technical lists] >> Sorry I was wrong >> >>>> >>>> There is not AppArmor and SElinux is disabled. >>>> The permits of the sock are as follows: >>>> libvirt-sock-admin 0700 (rwx) root: root >>>> libvirt-sock 0700 (rwx) root: root >>>> libvirt-sock-ro 0777 (rwxrwxrwx) root: root >>>> The libvirtd process runs with the root user. >>> >>> Okay, the permissions look okay. >> Good >> >>>> >>>> Below you will find the link to the requested log: >>>> http://pastebin.com/0jtpWU0h (libvirt_client.log command LIBVIRT_DEBUG >>>> = 1 virsh -c qemu: /// system list --all) >>> >>> And from the client logs it looks like client is trying to connect but >>> the daemon is not replying. So client just hangs waiting for server >>> reply. So I've looked into daemon logs and found this: >>> >>> 2016-10-10 12:10:39.138+: 1383: error : virPidFileAcquirePath:422 : >>> Failed to acquire pid file '/var/lib/libvirt/qemu/capabilities.pidfile': >>> Risorsa temporaneamente non disponibile >>> >>> (with my little Italian knowledge, this is Resource temporary unavailable) >>> >>> This suggests that there might be a different libvirt daemon running. >>> Can you confirm that? >> If I do a ps I am one libvirtd daemon and one of qemu and >> /var/lib/libvirt/qemu/capabilities.pidfile file exists >> The file contains the correct PID of the process qemu. > > Okay, so what's the status of the qemu process? Because what might be > happening here is that qemu driver is still starting up, so it is not > accepting connections just yet. And because qemu process it was talking > to (whilst fetching the caps) hung up, the driver basically failed to > start (and is still in startup phase). > > Michal ___ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
Re: [libvirt-users] Fwd: Problems connecting to the libvirtd server
>> -- Forwarded message -- >> From: Stefano Ricci <sfn@gmail.com> >> Date: 2016-10-11 12:35 GMT+02:00 >> Subject: Re: [libvirt-users] Problems connecting to the libvirtd server >> To: Michal Privoznik <mpriv...@redhat.com> >> > >[Please don't top post on technical lists] Sorry I was wrong >> >> There is not AppArmor and SElinux is disabled. >> The permits of the sock are as follows: >> libvirt-sock-admin 0700 (rwx) root: root >> libvirt-sock 0700 (rwx) root: root >> libvirt-sock-ro 0777 (rwxrwxrwx) root: root >> The libvirtd process runs with the root user. > >Okay, the permissions look okay. Good >> >> Below you will find the link to the requested log: >> http://pastebin.com/0jtpWU0h (libvirt_client.log command LIBVIRT_DEBUG >> = 1 virsh -c qemu: /// system list --all) > >And from the client logs it looks like client is trying to connect but >the daemon is not replying. So client just hangs waiting for server >reply. So I've looked into daemon logs and found this: > >2016-10-10 12:10:39.138+: 1383: error : virPidFileAcquirePath:422 : >Failed to acquire pid file '/var/lib/libvirt/qemu/capabilities.pidfile': >Risorsa temporaneamente non disponibile > >(with my little Italian knowledge, this is Resource temporary unavailable) > >This suggests that there might be a different libvirt daemon running. >Can you confirm that? If I do a ps I am one libvirtd daemon and one of qemu and /var/lib/libvirt/qemu/capabilities.pidfile file exists The file contains the correct PID of the process qemu. Stefano 2016-10-12 7:06 GMT+02:00 Michal Privoznik <mpriv...@redhat.com>: > On 11.10.2016 18:39, Stefano Ricci wrote: >> -- Forwarded message -- >> From: Stefano Ricci <sfn@gmail.com> >> Date: 2016-10-11 12:35 GMT+02:00 >> Subject: Re: [libvirt-users] Problems connecting to the libvirtd server >> To: Michal Privoznik <mpriv...@redhat.com> >> > > [Please don't top post on technical lists] > >> >> There is not AppArmor and SElinux is disabled. >> The permits of the sock are as follows: >> libvirt-sock-admin 0700 (rwx) root: root >> libvirt-sock 0700 (rwx) root: root >> libvirt-sock-ro 0777 (rwxrwxrwx) root: root >> The libvirtd process runs with the root user. > > Okay, the permissions look okay. > >> >> Below you will find the link to the requested log: >> http://pastebin.com/0jtpWU0h (libvirt_client.log command LIBVIRT_DEBUG >> = 1 virsh -c qemu: /// system list --all) > > And from the client logs it looks like client is trying to connect but > the daemon is not replying. So client just hangs waiting for server > reply. So I've looked into daemon logs and found this: > > 2016-10-10 12:10:39.138+: 1383: error : virPidFileAcquirePath:422 : > Failed to acquire pid file '/var/lib/libvirt/qemu/capabilities.pidfile': > Risorsa temporaneamente non disponibile > > (with my little Italian knowledge, this is Resource temporary unavailable) > > This suggests that there might be a different libvirt daemon running. > Can you confirm that? > > Michal ___ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
[libvirt-users] Fwd: Problems connecting to the libvirtd server
-- Forwarded message -- From: Stefano Ricci <sfn@gmail.com> Date: 2016-10-11 12:35 GMT+02:00 Subject: Re: [libvirt-users] Problems connecting to the libvirtd server To: Michal Privoznik <mpriv...@redhat.com> There is not AppArmor and SElinux is disabled. The permits of the sock are as follows: libvirt-sock-admin 0700 (rwx) root: root libvirt-sock 0700 (rwx) root: root libvirt-sock-ro 0777 (rwxrwxrwx) root: root The libvirtd process runs with the root user. Below you will find the link to the requested log: http://pastebin.com/0jtpWU0h (libvirt_client.log command LIBVIRT_DEBUG = 1 virsh -c qemu: /// system list --all) Stefano 2016-10-11 11:04 GMT+02:00 Michal Privoznik <mpriv...@redhat.com>: > > On 10.10.2016 18:36, Stefano Ricci wrote: > > Hello everyone > > I do not know if it is correct address this mailing lists but I can > > not use libvirt. > > I run compile libvirt version 2.2.0 into environment lfs stable with > > qemu 2.7.0 and have not had any problems. > > The program when it starts not report any errors in the log, with > > activated debug level file. > > Only when you try to connect with the following command virsh -c > > qemu:///system remains hung without reporting any error either in the > > logs that screen. > > The command virsh -c test:///default list instead concludes on a regular > > basis. > > I attach the file libvirt.log and libvirt.conf > > Interesting. Maybe something else is causing the problem? Is there an > AppArmor running? What are the socket perms? Can you attach client debug > logs? (well, maybe paste them somewhere to pastebin-like service) > > http://wiki.libvirt.org/page/DebugLogs > > Michal ___ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
[libvirt-users] Fwd: Running the test fails virnetmessagetest with libvirt 1.2.8
hello To better define the problem I launched the test that fails virnetmessagetest with the option VIR_TEST_DEBUG = 1 and attach the result: # VIR_TEST_DEBUG=1 ./virnetmessagetest TEST: virnetmessagetest 1) Message Header Encode ... libvirt: XML-RPC error : Unable to encode message header FAILED 2) Message Header Decode ... libvirt: XML-RPC error : Unable to decode message length FAILED 3) Message Payload Encode... libvirt: XML-RPC error : Unable to encode message header FAILED 4) Message Payload Decode... libvirt: XML-RPC error : Unable to decode message length FAILED 5) Message Payload Stream Encode ... libvirt: XML-RPC error : Unable to encode message header FAILED Is there anyone who can give me a hand to solve the problem? thanks Stefano -- Forwarded message -- From: Stefano Ricci sfn@gmail.com Date: 2014-09-23 19:58 GMT+02:00 Subject: Running the test fails virnetmessagetest with libvirt 1.2.8 To: libvirt-users@redhat.com Hello I apologize in advance for my English. I compiled the new version of libvirt 1.2.8 on an environment Development Linux from Scratch with the following configure: configure: Configuration summary configure: = configure: configure: Drivers configure: configure: Xen: no configure: QEMU: yes configure: UML: yes configure:OpenVZ: no configure:VMware: no configure: VBox: yes configure:XenAPI: no configure: xenlight: no configure: LXC: no configure: PHYP: yes configure: ESX: no configure: Hyper-V: no configure: Parallels: no configure: Bhyve: no configure: Test: yes configure:Remote: yes configure: Network: yes configure: Libvirtd: yes configure: Interface: yes configure: macvtap: yes configure: virtport: yes configure: configure: Storage Drivers configure: configure: Dir: yes configure: FS: no configure:NetFS: no configure: LVM: yes configure:iSCSI: yes configure: SCSI: yes configure:mpath: yes configure: Disk: no configure: RBD: no configure: Sheepdog: no configure: Gluster: no configure: ZFS: no configure: configure: Security Drivers configure: configure: SELinux: yes (/sys/fs/selinux) configure: AppArmor: no (install profiles: no) configure: configure: Driver Loadable Modules configure: configure: dlopen: -ldl configure: configure: Libraries configure: configure: apparmor: no configure: attr: yes (CFLAGS='' LIBS='-lattr') configure: audit: no configure: avahi: no configure: blkid: yes (CFLAGS='-I/install/include/blkid -I/install/include/uuid ' LIBS='-L/install/lib -lblkid ') configure: capng: no configure: curl: no configure: dbus: yes (CFLAGS='-I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include ' LIBS='-ldbus-1 ') configure: fuse: yes (CFLAGS='-D_FILE_OFFSET_BITS=64 -I/usr/include/fuse ' LIBS='-lfuse -pthread ') configure: glusterfs: no configure:hal: no configure: netcf: no configure:numactl: no configure: openwsman: no configure: pciaccess: yes (CFLAGS='' LIBS='-lpciaccess ') configure: readline: yes (CFLAGS='' LIBS='-lreadline') configure:sanlock: no configure: sasl: yes (CFLAGS='' LIBS='-lsasl2') configure:selinux: yes (CFLAGS='' LIBS='-lselinux') configure: ssh2: yes (CFLAGS='' LIBS='-lssh2 ') configure: systemd_daemon: no configure: udev: yes (CFLAGS='' LIBS='-ludev ') configure: yajl: yes (CFLAGS='' LIBS='-lyajl') configure: libxml: -I/usr/include/libxml2 -lxml2 configure: dlopen: -ldl configure: openwsman: no configure: gnutls: -lgnutls configure: firewalld: no configure: polkit: no configure: xen: no configure: xenapi: no configure: xenlight: no configure: pcap: -I/usr/include -L/usr/lib -lpcap configure: nl: -I/usr/include/libnl3 -I/usr/include/libnl3 -lnl-3 -lnl-route-3 -lnl-3 configure:mscom: no configure: xdr: configure: rbd: no configure: pm-utils: yes configure: configure: Test suite configure: configure:Coverage: no configure: Alloc OOM: no configure: configure: Miscellaneous configure: configure: Debug: yes configure: Use -Werror: no configure: Warning Flags: -W -Waddress -Waggressive-loop-optimizations -Wall -Warray-bounds -Wattributes -Wbad-function-cast -Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts -Wclobbered -Wcomment -Wcomments -Wcoverage-mismatch -Wcpp -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wdouble-promotion -Wempty-body -Wendif-labels -Wextra -Wformat-contains-nul -Wformat-extra-args -Wformat-security -Wformat-y2k -Wformat-zero-length -Wfree-nonheap-object -Wignored-qualifiers -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Winit-self -Winline -Wint
[libvirt-users] Running the test fails virnetmessagetest with libvirt 1.2.8
Hello I apologize in advance for my English. I compiled the new version of libvirt 1.2.8 on an environment Development Linux from Scratch with the following configure: configure: Configuration summary configure: = configure: configure: Drivers configure: configure: Xen: no configure: QEMU: yes configure: UML: yes configure:OpenVZ: no configure:VMware: no configure: VBox: yes configure:XenAPI: no configure: xenlight: no configure: LXC: no configure: PHYP: yes configure: ESX: no configure: Hyper-V: no configure: Parallels: no configure: Bhyve: no configure: Test: yes configure:Remote: yes configure: Network: yes configure: Libvirtd: yes configure: Interface: yes configure: macvtap: yes configure: virtport: yes configure: configure: Storage Drivers configure: configure: Dir: yes configure: FS: no configure:NetFS: no configure: LVM: yes configure:iSCSI: yes configure: SCSI: yes configure:mpath: yes configure: Disk: no configure: RBD: no configure: Sheepdog: no configure: Gluster: no configure: ZFS: no configure: configure: Security Drivers configure: configure: SELinux: yes (/sys/fs/selinux) configure: AppArmor: no (install profiles: no) configure: configure: Driver Loadable Modules configure: configure: dlopen: -ldl configure: configure: Libraries configure: configure: apparmor: no configure: attr: yes (CFLAGS='' LIBS='-lattr') configure: audit: no configure: avahi: no configure: blkid: yes (CFLAGS='-I/install/include/blkid -I/install/include/uuid ' LIBS='-L/install/lib -lblkid ') configure: capng: no configure: curl: no configure: dbus: yes (CFLAGS='-I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include ' LIBS='-ldbus-1 ') configure: fuse: yes (CFLAGS='-D_FILE_OFFSET_BITS=64 -I/usr/include/fuse ' LIBS='-lfuse -pthread ') configure: glusterfs: no configure:hal: no configure: netcf: no configure:numactl: no configure: openwsman: no configure: pciaccess: yes (CFLAGS='' LIBS='-lpciaccess ') configure: readline: yes (CFLAGS='' LIBS='-lreadline') configure:sanlock: no configure: sasl: yes (CFLAGS='' LIBS='-lsasl2') configure:selinux: yes (CFLAGS='' LIBS='-lselinux') configure: ssh2: yes (CFLAGS='' LIBS='-lssh2 ') configure: systemd_daemon: no configure: udev: yes (CFLAGS='' LIBS='-ludev ') configure: yajl: yes (CFLAGS='' LIBS='-lyajl') configure: libxml: -I/usr/include/libxml2 -lxml2 configure: dlopen: -ldl configure: openwsman: no configure: gnutls: -lgnutls configure: firewalld: no configure: polkit: no configure: xen: no configure: xenapi: no configure: xenlight: no configure: pcap: -I/usr/include -L/usr/lib -lpcap configure: nl: -I/usr/include/libnl3 -I/usr/include/libnl3 -lnl-3 -lnl-route-3 -lnl-3 configure:mscom: no configure: xdr: configure: rbd: no configure: pm-utils: yes configure: configure: Test suite configure: configure:Coverage: no configure: Alloc OOM: no configure: configure: Miscellaneous configure: configure: Debug: yes configure: Use -Werror: no configure: Warning Flags: -W -Waddress -Waggressive-loop-optimizations -Wall -Warray-bounds -Wattributes -Wbad-function-cast -Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts -Wclobbered -Wcomment -Wcomments -Wcoverage-mismatch -Wcpp -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wdouble-promotion -Wempty-body -Wendif-labels -Wextra -Wformat-contains-nul -Wformat-extra-args -Wformat-security -Wformat-y2k -Wformat-zero-length -Wfree-nonheap-object -Wignored-qualifiers -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Winit-self -Winline -Wint-to-pointer-cast -Winvalid-memory-model -Winvalid-pch -Wjump-misses-init -Wlogical-op -Wmain -Wmaybe-uninitialized -Wmissing-braces -Wmissing-declarations -Wmissing-field-initializers -Wmissing-include-dirs -Wmissing-parameter-type -Wmissing-prototypes -Wmultichar -Wnarrowing -Wnested-externs -Wnonnull -Wnormalized=nfc -Wold-style-declaration -Wold-style-definition -Woverflow -Woverride-init -Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-sign -Wpointer-to-int-cast -Wpragmas -Wreturn-local-addr -Wreturn-type -Wsequence-point -Wshadow -Wsizeof-pointer-memaccess -Wstrict-aliasing -Wstrict-prototypes -Wsuggest-attribute=const -Wsuggest-attribute=format -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure -Wswitch -Wsync-nand -Wtrampolines -Wtrigraphs -Wtype-limits -Wuninitialized -Wunknown-pragmas -Wunused -Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-function -Wunused-label -Wunused-local-typedefs -Wunused-parameter -Wunused-result -Wunused-value -Wunused-variable -Wvarargs -Wvariadic-macros -Wvector-operation-performance -Wvolatile-register-var -Wwrite-strings -fdiagnostics-show-option -funit-at-a-time -Wno-sign-compare -Wjump-misses-init
