similar to: deadlock on connection loosing

В письме от Вторник, 25-июн-2013 11:47:10 пользователь Michal Privoznik написал: > On 24.06.2013 11:36, Александр wrote: > > libvirtd will lock if for example kill programm which established > > connection,> > > only sigkill + restart helps., to reproduce: > > virConnectPtr libvirt_connection = virConnectOpen("qemu:///system"); > >

В письме от Воскресенье, 30-июн-2013 03:41:37 пользователь Александр написал: > В письме от Вторник, 25-июн-2013 11:47:10 пользователь Michal Privoznik > > написал: > > On 24.06.2013 11:36, Александр wrote: > > > libvirtd will lock if for example kill programm which established > > > connection,> > > > > > > only sigkill + restart helps., to

Ján Tomko wrote 2018-01-18 14:27: > On Thu, Jan 18, 2018 at 11:30:16AM +0700, Artem Likhachev wrote: >> # strace -p 5786 >> read(53, "\0\0\0\34", 4) = 4 >> read(53, "keep\0\0\0\1\0\0\0\2\0\0\0\2\0\0\0\0\0\0\0\0", 24) = 24 >> poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}, {fd=12, >> events=POLLIN}, {fd=13, events=POLLIN},

On 20.06.2013 12:56, Alexandr wrote: > On 20.06.2013 10:44, Michal Privoznik wrote: >> On 20.06.2013 09:40, Александр wrote: >>> В письме от Четверг, 20-июн-2013 09:15:14 Вы написали: >>>> On 19.06.2013 21:24, Александр wrote: >>>>> В письме от Среда, 19-июн-2013 09:35:27 пользователь Michal Privoznik >>> написал: >>>>>> On

В письме от Среда, 19-июн-2013 09:35:27 пользователь Michal Privoznik написал: > On 18.06.2013 22:21, Александр wrote: > > В письме от Вторник, 18-июн-2013 12:10:41 пользователь Michal Privoznik > > > > написал: > >> On 18.06.2013 07:14, Александр wrote: > >>> good day, i am trying to create domain via virDomainDefineXML. and my > >>> program

Hello, In the .xml file I use a media which is no longer available. In the past, I got the information media not available and the creation of the VM was stopped - O.k. behavior. Since 3.10 the libvirtd stopped promptly and all open consoles windows and the virt-manager closed promptly. For diagnose: etcsvms1:/kvm/CS8200/M5 # coredumpctl TIME PID UID GID SIG

I am newbie to this gdb debugging. now i did the bt in the debugging. In my side still it showing the error. Following are the stacktrace which i got. Kindly refer the following logs for full information: **** [New Thread 0x7f8503695700 (LWP 20012)] Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00007f84f671281e in

I'm trying the following command on the source machine: virsh migrate --live --copy-storage-all --verbose TEST qemu+ssh:// 10.30.76.66/system If I ssh into the destination machine when this command is running, I can see NBD copying data as expected, and if I wait long enough it completes and succeeds. However if I ctrl+c this command above before it completes, it causes virsh commands

i did the debugging as you said. Kindly refer the following logs: (gdb) c Continuing. thread apply all bt [New Thread 0x7fc337c6b700 (LWP 29520)] Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) thread apply all bt Thread 12 (Thread 0x7fc337c6b700 (LWP 29520)): #0 0x00007fc33509f18d in read () from /lib/x86_64-linux-gnu/libpthread.so.0 #1

Hello everybody! We have a cluster of servers managed by VMmanager 5 KVM (by ispsystem). A typical node: # cat /etc/redhat-release CentOS Linux release 7.3.1611 (Core) # uname -r 3.10.0-693.11.6.el7.x86_64 # rpm -qa |grep libvirt libvirt-daemon-driver-qemu-3.7.0-1.el7.centos.x86_64 libvirt-daemon-driver-storage-disk-3.7.0-1.el7.centos.x86_64 libvirt-3.7.0-1.el7.centos.x86_64

Hello libvirt-users list, We're catching the same bug since 3.4.0 version (3.3.0 works OK). So, we have process that is permanently connected to libvirtd via socket and it is collecting stats, listening to events and control the VPSes. When we try to 'shutdown' a number of VPSes we often catch the bug. One of VPSes sticks in 'in shutdown' state, no related 'qemu'

Hi,I am having an issue on several KVM hosts which run CentOs7 and libvirt-daemon-1.2.17-13.el7_2.3.x86_64 .About once a week the libvirtd hangs forever and becomes unresponsive, the only help is to restart it. I attached gdb to it and the output of it can be seen at the end of the mail. Laine from the irc channel suggests it has to do with dbus/policykit. If anybody got an idea what it could be

Hello, I installed libvirt from package manager(debian apt) and want to modify feture in it, so i git clone from https://libvirt.org/git/?p=libvirt.git;a=summary But now i have trouble to start virsh. I have traced the email: https://www.redhat.com/archives/libvirt-users/2017-February/msg00074.html Here is output of command below: strace -o libvirt.log -f -s 1000 /usr/sbin/libvirtd

Hi Daniel, sorry. Here the requested stack trace. Best regards Holger ===================================================================================== Thread 18 (Thread 0x7f0d495e0700 (LWP 10742)): #0  0x00007f0d55e690bf in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1  0x00007f0d5892176a in virCondWait (c=c@entry=0x5557f238db28,

On 20.06.2013 10:44, Michal Privoznik wrote: > On 20.06.2013 09:40, Александр wrote: >> В письме от Четверг, 20-июн-2013 09:15:14 Вы написали: >>> On 19.06.2013 21:24, Александр wrote: >>>> В письме от Среда, 19-июн-2013 09:35:27 пользователь Michal Privoznik >> написал: >>>>> On 18.06.2013 22:21, Александр wrote: >>>>>> В письме

В письме от Четверг, 20-июн-2013 13:25:06 пользователь Michal Privoznik написал: > On 20.06.2013 12:56, Alexandr wrote: > > On 20.06.2013 10:44, Michal Privoznik wrote: > >> On 20.06.2013 09:40, Александр wrote: > >>> В письме от Четверг, 20-июн-2013 09:15:14 Вы написали: > >>>> On 19.06.2013 21:24, Александр wrote: > >>>>> В письме

❦ 4 avril 2018 11:17 +0200, Michal Privoznik <mprivozn@redhat.com> : > Dunno, this is the first time I hear about this issue. Maybe you can try > to set a break point on virHashIterationError() and when it's hit get > stacktrace of all threads 't a a bt'. That might shed more light into > the issue. Smells like we are not locking somewhere properly. So, we have two

On Thu, Jan 18, 2018 at 11:30:16AM +0700, Artem Likhachev wrote: >Hello everybody! > >We have a cluster of servers managed by VMmanager 5 KVM (by ispsystem). > >A typical node: > ># cat /etc/redhat-release >CentOS Linux release 7.3.1611 (Core) ># uname -r >3.10.0-693.11.6.el7.x86_64 > ># rpm -qa |grep libvirt

Hey! On many of our servers, we often have the following error: error : virHashForEach:597 : Hash operation not allowed during iteration When querying the list of domains, this means libvirt will silently return 0 domain (most uses of virHashForEach don't handle the return code). We are using a hook, but the hook doesn't query libvirt back, so it should be safe from this point of view.

On 11/15/2017 06:54 AM, Holger Schranz wrote: > Thread 1 (Thread 0x7f4a069cc700 (LWP 10178)): > #0 0x00007f49ff969170 in qemuDomainChangeEjectableMedia ( > driver=driver@entry=0x7f49f841b700, vm=vm@entry=0x7f49ec02fbd0, > disk=disk@entry=0x7f49ec0375d0, newsrc=0x7f49e8014d10, force=force@entry=false) > at qemu/qemu_hotplug.c:303 This is fixed in current upstream by