October 2018 - Users - libvirt List Archives

[libvirt-users] [virtual interface] detach interface during boot succeed with no changes
by Yalan Zhang 08 Sep '22

08 Sep '22

Hi guys, when I detach an interface from vm during boot (vm boot not finished), it always fail. I'm not sure if there is an existing bug. I have confirmed with someone that for disk, there is similar behavior, if this is also acceptable? # virsh destroy rhel7.2; virsh start rhel7.2 ;sleep 2; virsh detach-interface rhel7.2 network 52:54:00:98:c4:a0; sleep 2; virsh dumpxml rhel7.2 |grep /interface -B9 Domain rhel7.2 destroyed Domain rhel7.2 started Interface detached successfully <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </controller> <interface type='network'> <mac address='52:54:00:98:c4:a0'/> <source network='default' bridge='virbr0'/> <target dev='vnet0'/> <model type='rtl8139'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> When I detach after the vm boot, expand the sleep time to 10, it will succeed. # virsh destroy rhel7.2; virsh start rhel7.2 ;sleep 10; virsh detach-interface rhel7.2 network 52:54:00:98:c4:a0; sleep 2; virsh dumpxml rhel7.2 |grep /interface -B9 Domain rhel7.2 destroyed Domain rhel7.2 started Interface detached successfully ------- Best Regards, Yalan Zhang IRC: yalzhang Internal phone: 8389413

3 4

[libvirt-users] Add Virtlyst to the list of libvirt users
by Daniel Nicoletti 23 Sep '20

23 Sep '20

Hi, I've just released v1.0.0 of Virtlyst[1] a web tool to manage VMs using Qt/C++/Cutelyst https://dantti.wordpress.com/2018/04/19/announcing-virtlyst-a-web-interface… Thanks. 1 - https://github.com/cutelyst/Virtlyst -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com

4 5

[libvirt-users] Question about disabling UFO on guest
by Bao Nguyen 05 Aug '20

05 Aug '20

Hello everyone, I would like to ask a question regarding to disable UFO of virtio vNIC in my guest. I have read the document at https://libvirt.org/formatdomain.html *host* The csum, gso, tso4, tso6, ecn and ufo attributes with possible values on and off can be used to turn off host offloading options. By default, the supported offloads are enabled by QEMU. *Since 1.2.9 (QEMU only)* The mrg_rxbuf attribute can be used to control mergeable rx buffers on the host side. Possible values are on (default) and off. *Since 1.2.13 (QEMU only)* *guest* The csum, tso4, tso6, ecn and ufo attributes with possible values on and off can be used to turn off guest offloading options. By default, the supported offloads are enabl ed by QEMU. *Since 1.2.9 (QEMU only)* Then I disabled UFO on my vNIC on guest as the following configuration <devices> <interface type='network'> <source network='default'/> <target dev='vnet1'/> <model type='virtio'/> <driver name='vhost' txmode='iothread' ioeventfd='on' event_idx='off' queues='5' rx_queue_size='256' tx_queue_size='256'> *<host gso='off' ufo='off' />* *<guest ufo='off'/>* </driver> </interface> </devices> Then I reboot my node to get the change effect and it works. However, can I disable the UFO without touching the host OS? or it always has to disable on both host and guest like that? Thanks, Brs, Natsu

2 1

[libvirt-users] lvm vs qcow (on NVMe)
by lejeczek 26 Nov '18

26 Nov '18

hi guys, anybody observed, maybe has measured performance difference between the two with qemu quests(windows OS)? Any conclusions, recommendations? many thanks, L.

3 2

[libvirt-users] Libvirt access control drivers
by Anastasiya Ruzhanskaya 21 Nov '18

21 Nov '18

Hello! According to the documentation access control drivers are not in really "good condition". There is a polkit, but it can distinguish users only according the pid. However, I have met some articles about more fine-grained control and about selinux drivers for libvirt? So, what is the status now? Should I implement something by myself if I want access based on login, are their instructions how to write these drivers or there is smth already?

3 18

[libvirt-users] libvirt with persistent device names
by Jan Marquardt 07 Nov '18

07 Nov '18

Hi, I am trying to create a logical volume storage pool with persistent device names for the block devices, because I can't/don't want to ensure that /dev/sd* names are persistent through reboots. virsh # pool-define-as web2067 logical - - /dev/disk/by-path/pci-0000:18:00.0-scsi-0:2:2:0 web2067 /dev/web2067 virsh # pool-build web2067 These two steps work as expected and the pv and the vg get created, but when I try to start the pool I get the following error: virsh # pool-start web2067 error: Failed to start pool web2067 error: unsupported configuration: cannot find any matching source devices for logical volume group 'web2067' If I do the same steps just with /dev/sdX instead of /dev/disk/by-path/..., the pool gets created correctly. This looks like a bug for me or am I wrong? If this is the case, is this and known issue and fixed in later versions? I am running Ubuntu 18.04 with libvirt in version 4.0.0. Best Regards Jan

2 2

[libvirt-users] Questions regarding migration from QEMU to libvirt
by Rodrigo Siqueira 06 Nov '18

06 Nov '18

Hi, My colleagues and I have a set of scripts that we use to automate our daily tasks related to the Linux Kernel. As a result, most of our code relies on the QEMU features; and recently we decided use libvirt instead of QEMU. However, we have some questions, and I would like to know if someone could help us. Follows: 1) Import our QEMU images with virsh Currently, we import the QEMU VMs with virt-install. Is it possible to automatically discover the distro variant of a QEMU image in order to use it in the “--os-variant” option? Here is how we register a VM: https://github.com/rodrigosiqueira/kworkflow/pull/23/files#diff-70617d452b0… 2) The requirement of sudo to create a network When we register our VM, we want to keep the ssh working well. However, every time we register a VM we create a new network bridge as a result it requires sudo. Is it possible to avoid this? Or at least make this a single action? Here is how we handled this: * The code for register: https://github.com/rodrigosiqueira/kworkflow/pull/23/files#diff-70617d452b0… * The configuration file that we adopted as a default: https://github.com/rodrigosiqueira/kworkflow/pull/23/files#diff-d8c16482496… 3) When using libvirt it changes the owner of our image If we try to use libvirt, it changes the ownership of our QEMU images (root). We fixed it by changing the file “/etc/libvirt/qemu.conf”, and switch the option dynamic_ownership to “0”. What is the impact of that change? Is it dangerous? There is a way to avoid this change? Finally, here is the full code of the libvirt part: https://github.com/rodrigosiqueira/kworkflow/pull/23/files Thanks Best Regards -- Rodrigo Siqueira http://siqueira.tech Graduate Student Department of Computer Science University of São Paulo

2 3

[libvirt-users] Windows guest skipping chkdsk if using Spice display
by Gionatan Danti 05 Nov '18

05 Nov '18

Hi all, as per subject, when a Windows guest using a Spice display is rebooted with a planned chkdsk, the consistency check is always skipped. It seems that the Spice display issues some "phantom" keystrokes, which are then intended by Windows as the "skip chkdsk at boot" signal. I tried to use a Spice display with no additional features (ie: USB redirection), but to no avail. To workaround the problem I must use a VNC display, which is less featureful than the Spice one. My system and package versions are: CentOS 7.5 x86-64 spice-gtk3-0.34-3.el7_5.1.x86_64 spice-server-0.14.0-2.el7_5.4.x86_64 spice-glib-0.34-3.el7_5.1.x86_64 libvirt-3.9.0-14.el7_5.7.x86_64 qemu-kvm-ev-2.10.0-21.el7_5.4.1.x86_64 It seems I am not the only one experiencing this problem: http://seifesrants.blogspot.com/2016/07/ghost-keystrokes-with-libvirt-kvm-s… Any suggestion? Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti(a)assyoma.it - info(a)assyoma.it GPG public key ID: FF5F32A8

2 3

[libvirt-users] How to change the default connection of 'virsh' tool from 'qemu' to 'xen' ?
by Minjun Hong 02 Nov '18

02 Nov '18

Hi. Thanks to help of this mailing list (especially Jim Fehlig), I have finished setup of libvirt. However, there is something weird. It is that I installed libvirt on 5 servers but the default connection of one of them is 'qemu:///' even if those of the others are all 'xen:///'. I searched how to change it but, I only found a bypass adding " LIBVIRT_DEFAULT_URI='xen:///' " in my .bashrc file. Currently, value of the variable (LIBVIRT_DEFAULT_URI) is set to 'qemu:///'. Since the bypass makes the virtualization type of the server visible 'qemu' to the open stack, I have to change libvirt configuration. I also checked some configure files under '/etc/libvirt', such as libvirt.conf, libvirtd.conf and libxl.conf. But I have no idea, how and what to change. Please give me some advise. It will be a big help for me. Thanks.

4 5

[libvirt-users] Xen via libvirt
by Minjun Hong 30 Oct '18

30 Oct '18

Hello. I want to use libvirt for toolstack of Xen (not XenServer) to set up Openstack system but, I'm new to libvirt so, I had some troubles on installing libvirt. I downloaded the source code, build and installed it, following here ( https://libvirt.org/compiling.html) However, when I type a command (# virsh 'xen:///system' list) to check if libvirt has been installed successfully, I can see an error message: error: failed to connect to the hypervisor > error: internal error: libxenlight state driver is not active Of course, I confirmed that Xen was working well: root@node1:/home/nickeys# xl list > Name ID Mem VCPUs State > Time(s) > Domain-0 0 95656 32 r----- > 5888.0 And I'm wondering why 'Using API' below is QEMU. How can I change that to Xen ? root@node1: /home/nickeys# virsh version > Compiled against library: libvirt 4.9.0 > Using library: libvirt 4.9.0 > Using API: QEMU 4.9.0 > Running hypervisor: QEMU 2.11.1 I'm using libvirt 4.9, Xen 4.12 (the current latest) and Linux kernel 4.16.1. I want to know how to make the 'libxenlight state driver' active. Please let me know where I should check first to fix this wrong state, or any tip is also okay. Thanks.

2 4

[libvirt-users] how to use LV(container) created by lxc-create?
by lejeczek 20 Oct '18

20 Oct '18

hi everyone, how can I use a LV created by lxc in libvirt guest domain? You know, you lxc-create with LV as backstore for a container(ubuntu in my case) and now you want to give to libvit. That, I thought would be a very common case but I failed to find a good howto on how one: lxc-create(lvm) => let libvirt take control over it. Or it's not how you would do it at all? many thanks, L.

2 1

[libvirt-users] LXC with --filesystem - control/impose filesystem(/ in container) size limits - how?
by lejeczek 19 Oct '18

19 Oct '18

hi guys container was created off a template with --dir. Is it even possible? I mean, as it is with filesystem, without moving/migrating to LVM, ZFS, etc? The very brute solution which comes to my mind - xfs project quotas - if it even could work. But that outside of libvirt/lxc. many thanks, L.

1 0

[libvirt-users] KVM + libvirt + nftables without iptables?
by Roman Vesely 19 Oct '18

19 Oct '18

Hi everyone, I use Debian 9.5 Stretch and NFTABLES as a firewall. Using NFTABLES together with IPTABLES is not recommended, but libvirt depends on IPTABLES. Is it safe to run libvirt + kvm + virsh without IPTABLES? By the doc https://libvirt.org/firewall.html, IPTABLES are used for settingup filtering which I do not need. Thanks, Roman

3 4

[libvirt-users] pcie-expander-bus doesn't support pcie-pci-bridge and pcie-switch-upstream-port
by Han Han 18 Oct '18

18 Oct '18

In libvirt, I found pcie-expander-bus controller doesn't support pcie-to-pci-bridge and pcie-switch-upstream-port. Version: libvirt-4.9 # cat /tmp/c.xml ... <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='pcie-expander-bus'> <model name='pxb-pcie'/> <target busNr='3'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </controller> <controller type='pci' index='2' model='pcie-to-pci-bridge'> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </controller> ... # virsh -k0 -K0 define /tmp/c.xml error: Failed to define domain from /tmp/c.xml error: XML error: The device at PCI address 0000:01:00.0 cannot be plugged into the PCI controller with index='1'. It requires a controller that accepts a pcie-to-pci-bridge. # cat /tmp/b.xml ... <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='pcie-expander-bus'> <model name='pxb-pcie'/> <target busNr='3'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </controller> <controller type='pci' index='2' model='pcie-switch-upstream-port'> <model name='x3130-upstream'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </controller> ... # virsh -k0 -K0 define /tmp/b.xml error: Failed to define domain from /tmp/b.xml error: XML error: The device at PCI address 0000:01:00.0 cannot be plugged into the PCI controller with index='1'. It requires a controller that accepts a pci-switch-upstream-port. In function virDomainPCIAddressBusSetModel, I find pcie-expander-bus only supports pcie-root-port and dmi-to-pci-bridge 353 case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_EXPANDER_BUS: 354 ┆ /* 32 slots, no hotplug, only accepts pcie-root-port or 355 ┆ ┆* dmi-to-pci-bridge 356 ┆ ┆*/ 357 ┆ bus->flags = (VIR_PCI_CONNECT_TYPE_PCIE_ROOT_PORT | 358 ┆ ┆ ┆ ┆ ┆ VIR_PCI_CONNECT_TYPE_DMI_TO_PCI_BRIDGE); 359 ┆ bus->minSlot = 0; 360 ┆ bus->maxSlot = VIR_PCI_ADDRESS_SLOT_LAST; 361 ┆ break; But it works in qemu: # /usr/libexec/qemu-kvm -machine q35 -m 1024 -device pxb-pcie,bus_nr=250,id=pci.1,bus=pcie.0,addr=0x4 -device pcie-pci-bridge,id=pci.250,bus=pci.1,addr=0x0 -device pcie-pci-bridge,id=pci.251,bus=pci.1,addr=0x1 -spice port=5902,addr=0.0.0.0,disable-ticketing /var/lib/libvirt/images/q35.qcow2 So why pcie-expander-bus doesn't these two controllers? For any concerns in libvirt? Thank you~ -- Best regards, ----------------------------------- Han Han Quality Engineer Redhat. Email: hhan(a)redhat.com Phone: +861065339333

4 4

[libvirt-users] Serial ports: vm vs bare metal
by Lars Kellogg-Stedman 16 Oct '18

16 Oct '18

I'm running libvirt under Fedora 28. I would like to attach a USB device to a VM, but when I select "Redirect USB Device" from the "Virtual Machine" menu in virt-manager and then select the device, I get the error: USB redirection error spice-client-error-quark: Could not redirect [device name] at 1-11: Error setting USB device node ACL: 'Not authorized' (0) There are no additional log messages acccompanying this in either the journal or in audit.log. It's not a selinux issue. The "Details" dropdown in the error dialog helpfully adds "USB redirection error". What do I do with this error message? I'm not even sure what it's trying to tell me. Thanks, -- Lars Kellogg-Stedman <lars(a)redhat.com> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ |

3 4

[libvirt-users] snapshots with virsh in a pacemaker cluster
by Lentes, Bernd 15 Oct '18

15 Oct '18

Hi, i have a two node cluster with virtual guests as resources. I'd like to snapshot the guests once in the night and thought i had a procedure. But i realize that things in a cluster are a bit more complicated than expected :-)) I will shutdown the guests to have a clean snapshot. I can shutdown the guests via pacemaker. But then arises the first problem: When i issue a "virsh snapshot-create-as" libvirt needs the domain name as a parameter. but libvirt does not know the domains any longer. When the guests are shutdown a "virsh list --all" on both nodes does not show any domain. A look in the respective resource agent VirtualDomain explains why: The domain is started with virsh create: "# The 'create' command guarantees that the domain will be # undefined on shutdown, ... OK: Now i could of course define all domains with a virsh define. But then i have immediately the next problem. Now i'd create the snapshots with "virsh snapshot-create-as" and starts the domains afterwards via cluster. But let's assume i issue that on node 1 and some guests are started afterwards via pacemaker on node 2. I can't predict on which node the guests are starting. Then i don't get a snapshot, right ? What to do ? Bernd -- Bernd Lentes Systemadministration Institut für Entwicklungsgenetik Gebäude 35.34 - Raum 208 HelmholtzZentrum münchen [ mailto:bernd.lentes@helmholtz-muenchen.de | bernd.lentes(a)helmholtz-muenchen.de ] phone: +49 89 3187 1241 fax: +49 89 3187 2294 [ http://www.helmholtz-muenchen.de/idg | http://www.helmholtz-muenchen.de/idg ] wer Fehler macht kann etwas lernen wer nichts macht kann auch nichts lernen Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: NN Stellv.Aufsichtsratsvorsitzender: MinDirig. Dr. Manfred Wolter Geschaeftsfuehrer: Prof. Dr. med. Dr. h.c. Matthias Tschoep, Heinrich Bassler, Dr. rer. nat. Alfons Enhsen Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671

3 3

[libvirt-users] Device lease hot unplug and events
by Milan Zamazal 15 Oct '18

15 Oct '18

Hi, when working on hot unplugs of various devices, I've found out that hot unplugging <lease> device doesn't generate VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED event. <lease> also doesn't have an alias, so it wouldn't be identifiable in the corresponding callback. Is this difference from other hotpluggable devices intentional? If yes, is there any better way of checking that <lease> removal is completed than querying and examining the domain XML? From user's point of view, it would be best if I could simply handle the device removal event the same way as with other devices. Thanks, Milan

2 4

[libvirt-users] How to explain this libvirt oddity w.r.t machine types?
by Kashyap Chamarthy 15 Oct '18

15 Oct '18

Context: The baremetal host previously had QEMU 2.11. But I manually downgraded the QEMU version (via `dnf downgrade qemu-system-x86`); now it is at 2.10: $ rpm -q qemu-system-x86 qemu-system-x86-2.10.2-1.fc27.x86_64 The guest is offline. Let's see (in a couple of ways) what machine type it has while it is dormant: # virsh dumpxml cirros | grep -i machine= <type arch='x86_64' machine='pc-i440fx-2.10'>hvm</type> # grep machine= /etc/libvirt/qemu/cirros.xml <type arch='x86_64' machine='pc-i440fx-2.10'>hvm</type> Okay, now edit the guest XML and carefully remove the "machine='pc-i440fx-2.10'" bit---to see what machine type will libvirt (libvirt-daemon-kvm-4.0.0-2.fc27.x86_64) default to: # virsh edit cirros Domain cirros XML configuration edited. Now check the machine type again. Bizarrely enough, libvirt "helpfully" auto-adds QEMU *2.11* machine type, which is obviously no longer on the system! # grep machine= /etc/libvirt/qemu/cirros.xml <type arch='x86_64' machine='pc-i440fx-2.11'>hvm</type> # virsh dumpxml cirros | grep -i machine= <type arch='x86_64' machine='pc-i440fx-2.11'>hvm</type> How to explain this? Is this even a "valid test"? (To undo the nuisance, obviously, I had to `virsh edit cirros` again and change it to 2.10.) Note, I *don't* have 2.11 QEMU on the system: # rpm -qa | grep -E 'qemu.*2.11' # echo $? 1 * * * It's getting late, and I should stop staring at screens. -- /kashyap

2 5

[libvirt-users] live migration via unix socket
by David Vossel 12 Oct '18

12 Oct '18

Hey, Over in KubeVirt we're investigating a use case where we'd like to perform a live migration within a network namespace that does not provide libvirtd with network access. In this scenario we would like to perform a live migration by proxying the migration through a unix socket to a process in another network namespace that does have network access. That external process would live on every node in the cluster and know how to correctly route connections between libvirtds. virsh example of an attempted migration via unix socket. virsh migrate --copy-storage-all --p2p --live --xml domain.xml my-vm qemu+unix:///system?socket=destination-host-proxy-sock In this example, the src libvirtd is able to establish a connection to the destination libvirtd via the unix socket proxy. However, the migration-uri appears to require either tcp or rdma network connection. If I force the migration-uri to be a unix socket, I receive an error [1] indicating that qemu+unix is not a valid transport. Technically with qemu+kvm I believe what we're attempting should be possible (even though it is inefficient). Please correct me if I'm wrong. Is there a way to achieve this migration via unix socket functionality this using Libvirt? Also, is there a reason why the migration uri is limited to tcp/rdma Thanks! - David [1] https://github.com/libvirt/libvirt/blob/master/src/qemu/qemu_migration.c#L2…

4 7

[libvirt-users] how "safe" is blockcommit ?
by Lentes, Bernd 12 Oct '18

12 Oct '18

Hi, currently i'm following https://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit. I 'm playing around with it and it seems to be quite nice. What i want is a daily consistent backup of my image file of the guest. I have the idea of the following procedure: - Shutdown the guest (i can live with a downtime of a few minutes, it will happen in the night). And i think it's the only way to have a real clean snapshot - create a snapshot with snapshot-create-as: snapshot-create-as guest testsn --disk-only - start the guest again. Changes will now go into the overlay, as e.g. inserts in a database - rsync the base file to a cifs server. With rsync not the complete, likely big file is transferred but just the delta - blockcommit the overlay: blockcommit guest /path/to/testsn --active --wait --verbose --pivot - delete the snapshot: snapshot-delete guest --snapshotname testsn --metadata - remove the overlay Is that ok ? How "safe" is blockcommit on a running guest ? It's possible that during the rsync, when the guest is running, some inserts are done in a database. Is it safe to copy the new sectors (i assume that's what blockcommit does) under a running database ? Or is it only safe doing blockcommit on a stopped guest ? Thanks for any answer. Bernd P.S. Is the same procedure possible when the guest disk(s) reside directly in a plain logical volume, without a file system in-between ? -- Bernd Lentes Systemadministration Institut für Entwicklungsgenetik Gebäude 35.34 - Raum 208 HelmholtzZentrum münchen [ mailto:bernd.lentes@helmholtz-muenchen.de | bernd.lentes(a)helmholtz-muenchen.de ] phone: +49 89 3187 1241 fax: +49 89 3187 2294 [ http://www.helmholtz-muenchen.de/idg | http://www.helmholtz-muenchen.de/idg ] wer Fehler macht kann etwas lernen wer nichts macht kann auch nichts lernen Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrer: Prof. Dr. med. Dr. h.c. Matthias H. Tschoep, Heinrich Bassler, Dr. rer. nat. Alfons Enhsen Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671

4 5

[libvirt-users] SR-IOV Trust Setting
by ]σ§έ Λιαςάη 10 Oct '18

10 Oct '18

Is there a setting to allow/disable spoof checking and trust on VF from SR-IOV device? Lookin at https://www.libvirt.org/formatdomain.html#elementsDriverBackendOptions can this be done through the driver element? *<driver name='vhost' txmode='iothread' ioeventfd='on' event_idx='off' queues='5' rx_queue_size='256' tx_queue_size='256'> <host csum='off' gso='off' tso4='off' tso6='off' ecn='off' ufo='off' mrg_rxbuf='off'/> <guest csum='off' tso4='off' tso6='off' ecn='off' ufo='off'/> </driver>* At the moment i have to manually run: ip link set $_dev vf $vf spoofchk off ip link set $_dev vf $vf trust on Is it possible to set this values from the xml file on a per interface basis?

2 1

[libvirt-users] [OCaml] Reset of the libvirt-ocaml repository
by Pino Toscano 10 Oct '18

10 Oct '18

Hi libvirt developers and users, TL;DR: you need to clone again the libvirt-ocaml repository, if you had one already Due to the way the repository was converted from another SCM in the past, some of the metadata of older commits was broken, and this made the repository unusable with more strict git configurations (e.g. as used on GitHub). You can read more details about this in https://www.redhat.com/archives/libvir-list/2018-September/msg00214.html The ocaml-libvirt repository from Rich Jones' website was fixed, and replaced the existing libvirt-ocaml on libvirt.org. The libvirt-ocaml repository is the official home now (or again) for the OCaml bindings of libvirt. This means that you need to clone again the libvirt-ocaml repository, in case you had already a clone of this repository. In case you had pending work on it, make sure to carry it over from an old clone to a newer clone. As usual, if you have patches for libvirt-ocaml, feel free to send them to libvir-list, tagging them as [ocaml]. -- Pino Toscano

1 0

[libvirt-users] how libvirt check qemu domain status?
by Dmitry Melekhov 09 Oct '18

09 Oct '18

Hello! Could you tell me how libvirtd check qemu domain status? Looks like this is something more then just looking for pid. Because we have VMs running over gluster storage using gfapi and if something goes wrong, then libvirtd became unresponsive often enough.. Thank you!

1 1

[libvirt-users] live migration and config
by Dmitry Melekhov 04 Oct '18

04 Oct '18

Hello! After some mistakes yesterday we ( me and my colleague ) think that it will be wise for libvirt to check config file existence on remote side and through error if not, before migrating, otherwise migration will fail and VM fs can be damaged, because it is sort of remove of power plug... We missed twice yesterday :-( Could you tell me is there already such option or any plans to implement this? Thank you!

2 9

[libvirt-users] Libvirt 4.2.0 hang on destination on live migration cancel
by Scott Sullivan 02 Oct '18

02 Oct '18

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 (like virsh list) to just hang seemingly forever on the destination machine. Here's the libvirt debug entries when I run virsh list in this state: [root@host ~]# export LIBVIRT_DEBUG=1 [root@host ~]# virsh list 2018-10-02 05:14:05.053+0000: 16207: debug : virGlobalInit:359 : register drivers 2018-10-02 05:14:05.054+0000: 16207: debug : virRegisterConnectDriver:657 : driver=0x7f70c1ddbb60 name=Test 2018-10-02 05:14:05.054+0000: 16207: debug : virRegisterConnectDriver:668 : registering Test as driver 0 2018-10-02 05:14:05.054+0000: 16207: debug : virRegisterConnectDriver:657 : driver=0x7f70c1ddc660 name=ESX 2018-10-02 05:14:05.054+0000: 16207: debug : virRegisterConnectDriver:668 : registering ESX as driver 12018-10-02 05:14:05.054+0000: 16207: debug : virRegisterConnectDriver:657 : driver=0x7f70c1ddd560 name=remote 2018-10-02 05:14:05.054+0000: 16207: debug : virRegisterConnectDriver:668 : registering remote as driver 2 2018-10-02 05:14:05.054+0000: 16207: debug : virEventRegisterDefaultImpl:280 : registering default event implementation 2018-10-02 05:14:05.054+0000: 16207: debug : virEventPollAddHandle:115 : Used 0 handle slots, adding at least 10 more 2018-10-02 05:14:05.054+0000: 16207: debug : virEventPollInterruptLocked:722 : Skip interrupt, 0 0 2018-10-02 05:14:05.054+0000: 16207: info : virEventPollAddHandle:140 : EVENT_POLL_ADD_HANDLE: watch=1 fd=4 events=1 cb=0x7f70c18791c0 opaque=(nil) ff=(nil) 2018-10-02 05:14:05.054+0000: 16207: debug : virEventRegisterImpl:241 : addHandle=0x7f70c187a8a0 updateHandle=0x7f70c1879500 removeHandle=0x7f70c1879360 addTimeout=0x7f70c187a660 updateTimeout=0x7f70c1879690 removeTimeout=0x7f70c1879220 2018-10-02 05:14:05.054+0000: 16207: debug : virEventPollAddTimeout:230 : Used 0 timeout slots, adding at least 10 more2018-10-02 05:14:05.054+0000: 16207: debug : virEventPollInterruptLocked:722 : Skip interrupt, 0 0 2018-10-02 05:14:05.054+0000: 16207: info : virEventPollAddTimeout:253 : EVENT_POLL_ADD_TIMEOUT: timer=1 frequency=-1 cb=0x5559f8dba380 opaque=0x7ffe5b15e700 ff=(nil) 2018-10-02 05:14:05.054+0000: 16207: debug : virConnectOpenAuth:1218 : name=<null>, auth=0x7f70c1ddea00, flags=0x0 2018-10-02 05:14:05.054+0000: 16207: info : virObjectNew:254 : OBJECT_NEW: obj=0x5559fa83a3f0 classname=virConnect 2018-10-02 05:14:05.054+0000: 16208: debug : virThreadJobSet:99 : Thread 16208 is now running job vshEventLoop 2018-10-02 05:14:05.054+0000: 16208: debug : virEventRunDefaultImpl:324 : running default event implementation 2018-10-02 05:14:05.054+0000: 16207: debug : virConfLoadConfig:1576 : Loading config file '/etc/libvirt/libvirt.conf' 2018-10-02 05:14:05.054+0000: 16208: debug : virEventPollCleanupTimeouts:525 : Cleanup 1 2018-10-02 05:14:05.054+0000: 16208: debug : virEventPollCleanupHandles:574 : Cleanup 1 2018-10-02 05:14:05.054+0000: 16207: debug : virConfReadFile:752 : filename=/etc/libvirt/libvirt.conf 2018-10-02 05:14:05.054+0000: 16208: debug : virEventPollMakePollFDs:401 : Prepare n=0 w=1, f=4 e=1 d=0 2018-10-02 05:14:05.054+0000: 16208: debug : virEventPollCalculateTimeout:338 : Calculate expiry of 1 timers 2018-10-02 05:14:05.054+0000: 16208: debug : virEventPollCalculateTimeout:371 : No timeout is pending 2018-10-02 05:14:05.054+0000: 16208: info : virEventPollRunOnce:640 : EVENT_POLL_RUN: nhandles=1 timeout=-1 2018-10-02 05:14:05.054+0000: 16207: debug : virFileClose:110 : Closed fd 6 2018-10-02 05:14:05.054+0000: 16207: debug : virConfGetValueString:897 : Get value string (nil) 0 2018-10-02 05:14:05.054+0000: 16207: debug : virConnectOpenInternal:1013 : no name, allowing driver auto-select 2018-10-02 05:14:05.054+0000: 16207: debug : virConnectOpenInternal:1056 : trying driver 0 (Test) ... 2018-10-02 05:14:05.054+0000: 16207: debug : virConnectOpenInternal:1071 : driver 0 Test returned DECLINED 2018-10-02 05:14:05.054+0000: 16207: debug : virConnectOpenInternal:1056 : trying driver 1 (ESX) ... 2018-10-02 05:14:05.054+0000: 16207: debug : virConnectOpenInternal:1071 : driver 1 ESX returned DECLINED 2018-10-02 05:14:05.054+0000: 16207: debug : virConnectOpenInternal:1056 : trying driver 2 (remote) ... 2018-10-02 05:14:05.054+0000: 16207: debug : remoteConnectOpen:1350 : Auto-probe remote URI 2018-10-02 05:14:05.054+0000: 16207: debug : doRemoteOpen:916 : proceeding with name = 2018-10-02 05:14:05.054+0000: 16207: debug : doRemoteOpen:925 : Connecting with transport 1 2018-10-02 05:14:05.054+0000: 16207: debug : doRemoteOpen:1060 : Proceeding with sockname /var/run/libvirt/libvirt-sock 2018-10-02 05:14:05.054+0000: 16207: debug : virNetSocketNewConnectUNIX:641 : path=/var/run/libvirt/libvirt-sock spawnDaemon=0 binary=<null> 2018-10-02 05:14:05.054+0000: 16207: debug : virNetSocketNewConnectUNIX:705 : connect() succeeded 2018-10-02 05:14:05.054+0000: 16207: debug : virNetSocketNew:237 : localAddr=0x7ffe5b15dd80 remoteAddr=0x7ffe5b15dcf0 fd=6 errfd=-1 pid=0 2018-10-02 05:14:05.054+0000: 16207: info : virObjectNew:254 : OBJECT_NEW: obj=0x5559fa83aa20 classname=virNetSocket 2018-10-02 05:14:05.054+0000: 16207: info : virNetSocketNew:293 : RPC_SOCKET_NEW: sock=0x5559fa83aa20 fd=6 errfd=-1 pid=0 localAddr=127.0.0.1;0, remoteAddr=127.0.0.1;0 2018-10-02 05:14:05.054+0000: 16207: info : virObjectNew:254 : OBJECT_NEW: obj=0x5559fa83ae20 classname=virNetClient 2018-10-02 05:14:05.055+0000: 16207: info : virNetClientNew:328 : RPC_CLIENT_NEW: client=0x5559fa83ae20 sock=0x5559fa83aa20 2018-10-02 05:14:05.055+0000: 16207: info : virObjectRef:388 : OBJECT_REF: obj=0x5559fa83ae20 2018-10-02 05:14:05.055+0000: 16207: info : virObjectRef:388 : OBJECT_REF: obj=0x5559fa83aa20 2018-10-02 05:14:05.055+0000: 16207: debug : virEventPollInterruptLocked:726 : Interrupting 2018-10-02 05:14:05.055+0000: 16207: info : virEventPollAddHandle:140 : EVENT_POLL_ADD_HANDLE: watch=2 fd=6 events=1 cb=0x7f70c19b4df0 opaque=0x5559fa83aa20 ff=0x7f70c19b5320 2018-10-02 05:14:05.055+0000: 16207: debug : virKeepAliveNew:196 : client=0x5559fa83ae20, interval=-1, count=0 2018-10-02 05:14:05.055+0000: 16207: info : virObjectNew:254 : OBJECT_NEW: obj=0x5559fa83b120 classname=virKeepAlive 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollRunOnce:650 : Poll got 1 event(s) 2018-10-02 05:14:05.055+0000: 16207: info : virKeepAliveNew:215 : RPC_KEEPALIVE_NEW: ka=0x5559fa83b120 client=0x5559fa83ae20 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollDispatchTimeouts:432 : Dispatch 1 2018-10-02 05:14:05.055+0000: 16207: info : virObjectRef:388 : OBJECT_REF: obj=0x5559fa83ae20 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollDispatchHandles:478 : Dispatch 1 2018-10-02 05:14:05.055+0000: 16207: info : virObjectNew:254 : OBJECT_NEW: obj=0x5559fa83b340 classname=virConnectCloseCallbackData 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollDispatchHandles:492 : i=0 w=1 2018-10-02 05:14:05.055+0000: 16207: info : virObjectRef:388 : OBJECT_REF: obj=0x5559fa83b340 2018-10-02 05:14:05.055+0000: 16208: info : virEventPollDispatchHandles:506 : EVENT_POLL_DISPATCH_HANDLE: watch=1 events=1 2018-10-02 05:14:05.055+0000: 16207: info : virObjectNew:254 : OBJECT_NEW: obj=0x5559fa83b040 classname=virNetClientProgram 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollCleanupTimeouts:525 : Cleanup 1 2018-10-02 05:14:05.055+0000: 16207: info : virObjectNew:254 : OBJECT_NEW: obj=0x5559fa83ac00 classname=virNetClientProgram 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollCleanupHandles:574 : Cleanup 2 2018-10-02 05:14:05.055+0000: 16207: info : virObjectNew:254 : OBJECT_NEW: obj=0x5559fa83a9b0 classname=virNetClientProgram 2018-10-02 05:14:05.055+0000: 16208: debug : virEventRunDefaultImpl:324 : running default event implementation 2018-10-02 05:14:05.055+0000: 16207: info : virObjectRef:388 : OBJECT_REF: obj=0x5559fa83b040 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollCleanupTimeouts:525 : Cleanup 1 2018-10-02 05:14:05.055+0000: 16207: info : virObjectRef:388 : OBJECT_REF: obj=0x5559fa83ac00 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollCleanupHandles:574 : Cleanup 2 2018-10-02 05:14:05.055+0000: 16207: info : virObjectRef:388 : OBJECT_REF: obj=0x5559fa83a9b0 2018-10-02 05:14:05.055+0000: 16207: debug : doRemoteOpen:1179 : Trying authentication 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollMakePollFDs:401 : Prepare n=0 w=1, f=4 e=1 d=0 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollMakePollFDs:401 : Prepare n=1 w=2, f=6 e=1 d=0 2018-10-02 05:14:05.055+0000: 16207: debug : virNetMessageNew:46 : msg=0x5559fa83b720 tracked=0 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollCalculateTimeout:338 : Calculate expiry of 1 timers 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollCalculateTimeout:371 : No timeout is pending 2018-10-02 05:14:05.055+0000: 16207: debug : virNetMessageEncodePayload:389 : Encode length as 28 2018-10-02 05:14:05.055+0000: 16208: info : virEventPollRunOnce:640 : EVENT_POLL_RUN: nhandles=2 timeout=-1 2018-10-02 05:14:05.055+0000: 16207: info : virNetClientSendInternal:2121 : RPC_CLIENT_MSG_TX_QUEUE: client=0x5559fa83ae20 len=28 prog=536903814 vers=1 proc=66 type=0 status=0 serial=0 2018-10-02 05:14:05.055+0000: 16207: debug : virNetClientCallNew:2074 : New call 0x5559fa83b6a0: msg=0x5559fa83b720, expectReply=1, nonBlock=0 2018-10-02 05:14:05.055+0000: 16207: debug : virNetClientIO:1880 : Outgoing message prog=536903814 version=1 serial=0 proc=66 type=0 length=28 dispatch=(nil) 2018-10-02 05:14:05.055+0000: 16207: debug : virNetClientIO:1939 : We have the buck head=0x5559fa83b6a0 call=0x5559fa83b6a0 2018-10-02 05:14:05.055+0000: 16207: info : virEventPollUpdateHandle:152 : EVENT_POLL_UPDATE_HANDLE: watch=2 events=0 2018-10-02 05:14:05.055+0000: 16207: debug : virEventPollInterruptLocked:726 : Interrupting 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollRunOnce:650 : Poll got 1 event(s) 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollDispatchTimeouts:432 : Dispatch 1 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollDispatchHandles:478 : Dispatch 2 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollDispatchHandles:492 : i=0 w=1 2018-10-02 05:14:05.055+0000: 16208: info : virEventPollDispatchHandles:506 : EVENT_POLL_DISPATCH_HANDLE: watch=1 events=1 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollCleanupTimeouts:525 : Cleanup 1 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollCleanupHandles:574 : Cleanup 2 2018-10-02 05:14:05.055+0000: 16208: debug : virEventRunDefaultImpl:324 : running default event implementation 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollCleanupTimeouts:525 : Cleanup 1 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollCleanupHandles:574 : Cleanup 2 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollMakePollFDs:401 : Prepare n=0 w=1, f=4 e=1 d=0 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollMakePollFDs:401 : Prepare n=1 w=2, f=6 e=0 d=0 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollCalculateTimeout:338 : Calculate expiry of 1 timers 2018-10-02 05:14:05.055+0000: 16208: debug : virEventPollCalculateTimeout:371 : No timeout is pending 2018-10-02 05:14:05.055+0000: 16208: info : virEventPollRunOnce:640 : EVENT_POLL_RUN: nhandles=1 timeout=-1 And here's some information from gbd when its in this state: [root@host ~]# ps axf | grep libvirtd 17010 pts/2 S+ 0:00 \_ grep libvirtd 15555 ? Sl 0:00 libvirtd --daemon [root@host ~]# gdb -p $(pgrep libvirtd) (gdb) t a a bt Thread 17 (Thread 0x2ae648a10700 (LWP 15559)): #0 0x00002ae63d97b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae63b2c01ba in virCondWait (c=<value optimized out>, m=<value optimized out>) at util/virthread.c:154 #2 0x00002ae63b2c13fb in virThreadPoolWorker (opaque=<value optimized out>) at util/virthreadpool.c:124 #3 0x00002ae63b2c0036 in virThreadHelper (data=<value optimized out>) at util/virthread.c:206 #4 0x00002ae63d977aa1 in start_thread () from /lib64/libpthread.so.0 #5 0x00002ae63e4d893d in clone () from /lib64/libc.so.6 Thread 16 (Thread 0x2ae648c11700 (LWP 15560)): #0 0x00002ae63d97b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae63b2c01ba in virCondWait (c=<value optimized out>, m=<value optimized out>) at util/virthread.c:154 #2 0x00002ae63b2c13fb in virThreadPoolWorker (opaque=<value optimized out>) at util/virthreadpool.c:124 #3 0x00002ae63b2c0036 in virThreadHelper (data=<value optimized out>) at util/virthread.c:206 ---Type <return> to continue, or q <return> to quit--- #4 0x00002ae63d977aa1 in start_thread () from /lib64/libpthread.so.0 #5 0x00002ae63e4d893d in clone () from /lib64/libc.so.6 Thread 15 (Thread 0x2ae648e12700 (LWP 15561)): #0 0x00002ae63d97b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae63b2c01ba in virCondWait (c=<value optimized out>, m=<value optimized out>) at util/virthread.c:154 #2 0x00002ae63b2c13fb in virThreadPoolWorker (opaque=<value optimized out>) at util/virthreadpool.c:124 #3 0x00002ae63b2c0036 in virThreadHelper (data=<value optimized out>) at util/virthread.c:206 #4 0x00002ae63d977aa1 in start_thread () from /lib64/libpthread.so.0 #5 0x00002ae63e4d893d in clone () from /lib64/libc.so.6 Thread 14 (Thread 0x2ae649013700 (LWP 15562)): #0 0x00002ae63d97b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae63b2c01ba in virCondWait (c=<value optimized out>, m=<value optimized out>) at util/virthread.c:154 ---Type <return> to continue, or q <return> to quit--- #2 0x00002ae63b2c13fb in virThreadPoolWorker (opaque=<value optimized out>) at util/virthreadpool.c:124 #3 0x00002ae63b2c0036 in virThreadHelper (data=<value optimized out>) at util/virthread.c:206 #4 0x00002ae63d977aa1 in start_thread () from /lib64/libpthread.so.0 #5 0x00002ae63e4d893d in clone () from /lib64/libc.so.6 Thread 13 (Thread 0x2ae649214700 (LWP 15563)): #0 0x00002ae63d97b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae63b2c01ba in virCondWait (c=<value optimized out>, m=<value optimized out>) at util/virthread.c:154 #2 0x00002ae63b2c13fb in virThreadPoolWorker (opaque=<value optimized out>) at util/virthreadpool.c:124 #3 0x00002ae63b2c0036 in virThreadHelper (data=<value optimized out>) at util/virthread.c:206 #4 0x00002ae63d977aa1 in start_thread () from /lib64/libpthread.so.0 #5 0x00002ae63e4d893d in clone () from /lib64/libc.so.6 Thread 12 (Thread 0x2ae649415700 (LWP 15564)): ---Type <return> to continue, or q <return> to quit--- #0 0x00002ae63d97b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae63b2c01ba in virCondWait (c=<value optimized out>, m=<value optimized out>) at util/virthread.c:154 #2 0x00002ae63b2c13a8 in virThreadPoolWorker (opaque=<value optimized out>) at util/virthreadpool.c:124 #3 0x00002ae63b2c0036 in virThreadHelper (data=<value optimized out>) at util/virthread.c:206 #4 0x00002ae63d977aa1 in start_thread () from /lib64/libpthread.so.0 #5 0x00002ae63e4d893d in clone () from /lib64/libc.so.6 Thread 11 (Thread 0x2ae649616700 (LWP 15565)): #0 0x00002ae63d97b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae63b2c01ba in virCondWait (c=<value optimized out>, m=<value optimized out>) at util/virthread.c:154 #2 0x00002ae63b2c13a8 in virThreadPoolWorker (opaque=<value optimized out>) at util/virthreadpool.c:124 #3 0x00002ae63b2c0036 in virThreadHelper (data=<value optimized out>) at util/virthread.c:206 #4 0x00002ae63d977aa1 in start_thread () from /lib64/libpthread.so.0 #5 0x00002ae63e4d893d in clone () from /lib64/libc.so.6 ---Type <return> to continue, or q <return> to quit--- Thread 10 (Thread 0x2ae649817700 (LWP 15566)): #0 0x00002ae63d97b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae63b2c01ba in virCondWait (c=<value optimized out>, m=<value optimized out>) at util/virthread.c:154 #2 0x00002ae63b2c13a8 in virThreadPoolWorker (opaque=<value optimized out>) at util/virthreadpool.c:124 #3 0x00002ae63b2c0036 in virThreadHelper (data=<value optimized out>) at util/virthread.c:206 #4 0x00002ae63d977aa1 in start_thread () from /lib64/libpthread.so.0 #5 0x00002ae63e4d893d in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x2ae649a18700 (LWP 15567)): #0 0x00002ae63d97b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae63b2c01ba in virCondWait (c=<value optimized out>, m=<value optimized out>) at util/virthread.c:154 #2 0x00002ae63b2c13a8 in virThreadPoolWorker (opaque=<value optimized out>) at util/virthreadpool.c:124 #3 0x00002ae63b2c0036 in virThreadHelper (data=<value optimized out>) at util/virthread.c:206 ---Type <return> to continue, or q <return> to quit--- #4 0x00002ae63d977aa1 in start_thread () from /lib64/libpthread.so.0 #5 0x00002ae63e4d893d in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x2ae649c19700 (LWP 15568)): #0 0x00002ae63d97b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae63b2c01ba in virCondWait (c=<value optimized out>, m=<value optimized out>) at util/virthread.c:154 #2 0x00002ae63b2c13a8 in virThreadPoolWorker (opaque=<value optimized out>) at util/virthreadpool.c:124 #3 0x00002ae63b2c0036 in virThreadHelper (data=<value optimized out>) at util/virthread.c:206 #4 0x00002ae63d977aa1 in start_thread () from /lib64/libpthread.so.0 #5 0x00002ae63e4d893d in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x2ae64d0aa700 (LWP 15588)): #0 0x00002ae63d97b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae63b2c01ba in virCondWait (c=<value optimized out>, m=<value optimized out>) at util/virthread.c:154 ---Type <return> to continue, or q <return> to quit--- #2 0x00002ae63b2c13fb in virThreadPoolWorker (opaque=<value optimized out>) at util/virthreadpool.c:124 #3 0x00002ae63b2c0036 in virThreadHelper (data=<value optimized out>) at util/virthread.c:206 #4 0x00002ae63d977aa1 in start_thread () from /lib64/libpthread.so.0 #5 0x00002ae63e4d893d in clone () from /lib64/libc.so.6 Thread 6 (Thread 0x2ae64d2ab700 (LWP 15589)): #0 0x00002ae63d97b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae63b2c01ba in virCondWait (c=<value optimized out>, m=<value optimized out>) at util/virthread.c:154 #2 0x00002ae63b2c13fb in virThreadPoolWorker (opaque=<value optimized out>) at util/virthreadpool.c:124 #3 0x00002ae63b2c0036 in virThreadHelper (data=<value optimized out>) at util/virthread.c:206 #4 0x00002ae63d977aa1 in start_thread () from /lib64/libpthread.so.0 #5 0x00002ae63e4d893d in clone () from /lib64/libc.so.6 Thread 5 (Thread 0x2ae64d4ac700 (LWP 15590)): ---Type <return> to continue, or q <return> to quit--- #0 0x00002ae63d97b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae63b2c01ba in virCondWait (c=<value optimized out>, m=<value optimized out>) at util/virthread.c:154 #2 0x00002ae63b2c13fb in virThreadPoolWorker (opaque=<value optimized out>) at util/virthreadpool.c:124 #3 0x00002ae63b2c0036 in virThreadHelper (data=<value optimized out>) at util/virthread.c:206 #4 0x00002ae63d977aa1 in start_thread () from /lib64/libpthread.so.0 #5 0x00002ae63e4d893d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x2ae64d6ad700 (LWP 15591)): #0 0x00002ae63d97b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae63b2c01ba in virCondWait (c=<value optimized out>, m=<value optimized out>) at util/virthread.c:154 #2 0x00002ae63b2c13fb in virThreadPoolWorker (opaque=<value optimized out>) at util/virthreadpool.c:124 #3 0x00002ae63b2c0036 in virThreadHelper (data=<value optimized out>) at util/virthread.c:206 #4 0x00002ae63d977aa1 in start_thread () from /lib64/libpthread.so.0 #5 0x00002ae63e4d893d in clone () from /lib64/libc.so.6 ---Type <return> to continue, or q <return> to quit--- Thread 3 (Thread 0x2ae64d8ae700 (LWP 15592)): #0 0x00002ae63d97b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae63b2c01ba in virCondWait (c=<value optimized out>, m=<value optimized out>) at util/virthread.c:154 #2 0x00002ae63b2c13fb in virThreadPoolWorker (opaque=<value optimized out>) at util/virthreadpool.c:124 #3 0x00002ae63b2c0036 in virThreadHelper (data=<value optimized out>) at util/virthread.c:206 #4 0x00002ae63d977aa1 in start_thread () from /lib64/libpthread.so.0 #5 0x00002ae63e4d893d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x2ae64dec8700 (LWP 15632)): #0 0x00002ae63d97ed0d in recvmsg () from /lib64/libpthread.so.0 #1 0x00002ae63e9caef0 in udev_monitor_receive_device () from /lib64/libudev.so.0 #2 0x00002ae64be26864 in udevEventHandleThread (opaque=<value optimized out>) at node_device/node_device_udev.c:1623 #3 0x00002ae63b2c0075 in virThreadHelper (data=<value optimized out>) at util/virthread.c:206 ---Type <return> to continue, or q <return> to quit--- #4 0x00002ae63d977aa1 in start_thread () from /lib64/libpthread.so.0 #5 0x00002ae63e4d893d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x2ae6429759e0 (LWP 15555)): #0 0x00002ae63d97e334 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00002ae63d9795d8 in _L_lock_854 () from /lib64/libpthread.so.0 #2 0x00002ae63d9794a7 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00002ae64be2364b in udevEventHandleCallback (watch=<value optimized out>, fd=19, events=<value optimized out>, data=<value optimized out>) at node_device/node_device_udev.c:1666 #4 0x00002ae63b257564 in virEventPollDispatchHandles () at util/vireventpoll.c:508 #5 virEventPollRunOnce () at util/vireventpoll.c:657 #6 0x00002ae63b255eb0 in virEventRunDefaultImpl () at util/virevent.c:327 #7 0x00002ae63b3a338d in virNetDaemonRun (dmn=0x55b1d39818d0) at rpc/virnetdaemon.c:858 #8 0x000055b1d2a4d60b in main (argc=<value optimized out>, argv=<value optimized out>) at remote/remote_daemon.c:1475 (gdb) This issue I know is fixed in 4.7.0 because I run this version on my CentOS 7 machines and don't have this issue. However on my CentOS 6 machines I have 4.2.0, and do experience this issue. Upgrading to 4.7.0 on CentOS 6 is troublesome though, because of the requirement of gnutls >= 3.2. I'm hoping with the above output someone might be able to point me in the right direction to a commit that resolved this between 4.2.0 and 4.7.0, or a possible way to prevent this hang in 4.2.0 as described above ? Thanks in advance

1 1