- Users - libvirt List Archives

investigate locks on a domain
by Jiatong Shen 20 Jul '21

20 Jul '21

Hello community, I am seeing following log in production, 2021-07-20 07:43:49.417+0000: 3918294: error : qemuDomainObjBeginJobInternal:4945 : Timed out during operation: cannot acquire state change lock (held by qemuProcessReconnect) 2021-07-20 07:44:19.424+0000: 3918296: warning : qemuDomainObjBeginJobInternal:4933 : Cannot start job (modify, none) for domain instance-0000074e; current job is (modify, none) owned by (3919429 qemuProcessReconnect, 0 <null>) for (2183193s, 0s) 2021-07-20 07:44:19.424+0000: 3918296: error : qemuDomainObjBeginJobInternal:4945 : Timed out during operation: cannot acquire state change lock (held by qemuProcessReconnect) 2021-07-20 07:44:49.428+0000: 3918296: warning : qemuDomainObjBeginJobInternal:4933 : Cannot start job (query, none) for domain instance-0000074e; current job is (modify, none) owned by (3919429 qemuProcessReconnect, 0 <null>) for (2183223s, 0s) 2021-07-20 07:44:49.428+0000: 3918296: error : qemuDomainObjBeginJobInternal:4945 : Timed out during operation: cannot acquire state change lock (held by qemuProcessReconnect) 2021-07-20 07:45:19.429+0000: 3918298: warning : qemuDomainObjBeginJobInternal:4933 : I am confused about what is qemuProcessReconnect and why it acquires a domain state lock.. -- Best Regards, Jiatong Shen

3 2

Failed to terminate process 1901409 with SIGKILL: Device or resource busy
by 梁朝军 19 Jul '21

19 Jul '21

Hi All, I hit another issue that libvirt sometimes throw exception like 'Failed to terminate process 1901409 with SIGKILL: Device or resource busy’ once we try to destroy vm through 'conn.lookupByID(id_).destroy()’. After this issue occur, it will caused the socket fd and pipe increased and finally caused fd leak. Who know the root cause of this issue or give some cues? Any comments are appreciated Thanks !

1 0

Re: how to build a github release tarball
by Andrea Bolognani 15 Jul '21

15 Jul '21

[re-adding the list] On Thu, Jul 15, 2021 at 01:25:02PM +0800, Jiatong Shen wrote: > On Thu, Jul 15, 2021 at 5:54 AM Jiatong Shen <yshxxsjt715(a)gmail.com> wrote: > > thank you very much for reply. but what should I do if I want to > > build release tarball myself (for 6.0.0..)? I would like to backport some > > features > > to 6.0.0.. > > hmm. it looks like `make -j3 dist` could produce a tarball for 6.0.0.. Is > it the right > approach? Yes, if your goal is to create a release archive for libvirt 6.0.0 with some patches on top[1] then the best way to go about it is to clone the repo, branch off the v6.0.0 tag, cherry-pick the changes you're interested in and then generate the archive using 'make distcheck'. [1] You could have told us this in the first place instead of asking a more generic question for which a different answer was more appropriate ;) -- Andrea Bolognani / Red Hat / Virtualization

1 0

openVswitch won't get to a virtual IP
by lejeczek 14 Jul '21

14 Jul '21

Hi guys. Among all the mailing lists I'm subscriber of this one I thought, would where chances to find 'openvswitch'+'libvirtd' experts to share thoughts & suggestions should be grater. A case: a) all guests are KVM. b) I have NM managed OVS bridge and libvirtd network to/on that bridge c) "regular" NM bridge and network off it in libvirt problem is - guests on OVS network can _not_ ping a virtual IP of a guest(s) on 'regular' bridge network, but.. can ping "actual" IP of that same guest(s) okey. any thoughts and ideas on how & what to investigate are very appreciated. many thanks, L.

2 2

how to build a github release tarball
by Jiatong Shen 14 Jul '21

14 Jul '21

Hello community, I am trying to figure out a way to build a release tarball like https://github.com/libvirt/libvirt/releases?after=v6.2.0, for libvirt 6.0.0, but don't know how. Could anyone teach me how to package it? thank you. -- Best Regards, Jiatong Shen

3 2

DAC & glusterFS - errors
by lejeczek 14 Jul '21

14 Jul '21

Hi guys I'm trying to spin up a VM whose image is on a GlusterFS vol, and I fail: -> $ virsh create /var/lib/pacemaker/conf.d/win10Pro.xml error: Failed to create domain from /var/lib/pacemaker/conf.d/win10Pro.xml error: failed to initialize gluster connection (src=0x7f0af807b410 priv=0x7f0af8090070): Invalid argument In logs: ... 2021-07-05 21:13:12.950+0000: 141524: warning : virSecurityDACSetOwnership:828 : Unable to restore label on 'win10Pro.qcow2'. XATTRs might have been left in inconsistent state. internal error: child reported (status=125): failed to initialize gluster connection (src=0x7f0b00097030 priv=0x7f0b000956c0): Invalid argument Any ideas & suggestions greatly appreciated. thanks, L.

5 5

virsh qemu-monitor-command block_resize not working
by arjen-libvirt＠gugu.be 14 Jul '21

14 Jul '21

Hi List, some version info: ]# /usr/libexec/qemu-kvm -version QEMU emulator version 4.2.0 (qemu-kvm-4.2.0-48.module+el8.4.0+534+4680a14e) Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers ]# virsh version Compiled against library: libvirt 6.0.0 Using library: libvirt 6.0.0 Using API: QEMU 6.0.0 Running hypervisor: QEMU 4.2.0 information about block devices for one specific guest: ]# virsh qemu-monitor-command uat-win201202.uat.gugu.be --hmp info block libvirt-2-format: /data/kvm/storage/diskimages01/uat-win201202_disk1_C.qcow2 (qcow2) Attached to: /machine/peripheral/virtio-disk0/virtio-backend Cache mode: writeback ide0-0-0: [not inserted] Attached to: ide0-0-0 Removable device: not locked, tray closed But then, when I want to resize the block device, I just cannot seem to find the correct device. I tried all of these: virsh qemu-monitor-command uat-win201202.uat.gugu.be --hmp block_resize libvirt-2-storage 48G Error: Cannot find device=libvirt-2-storage nor node_name= virsh qemu-monitor-command uat-win201202.uat.gugu.be --hmp block_resize drive-libvirt-2-storage 48G Error: Cannot find device=drive-libvirt-2-storage nor node_name= virsh qemu-monitor-command uat-win201202.uat.gugu.be --hmp block_resize virtio-disk0 48G Error: Cannot find device=virtio-disk0 nor node_name= virsh qemu-monitor-command uat-win201202.uat.gugu.be --hmp block_resize drive-virtio-disk0 48G Error: Cannot find device=drive-virtio-disk0 nor node_name= In a previous qemu version this worked (EL 7). Can someone help me out? Best regards, Arjen Van Drie, Antwerp

2 2

host identifier
by Jiatong Shen 05 Jul '21

05 Jul '21

Hello community, I am using OpenStack nova and realize that nova now uses host fqdn from libvirt as a uniq identifier for a compute node. The issue is that host might need to change its fqdn under some rare circumstances and lose some usage data due to the nova manages compute node resources. My question is: does libvirt already export host uuid identifier to other applications? I skim through the code base and find there is host uuid related code which reads /etc/machine-id to obtain a uniq uuid for migration, but seems this uuid cannot be obtained through virsh interface. Thank you for you help. -- Best Regards, Jiatong Shen

2 2

Fail to do blockcopy to network dest xml with --reuse-external
by Han Han 28 Jun '21

28 Jun '21

Hello, libvirt developers, Recently I find an issue of libvirt blockcopy: Versions: libvirt-7.4.0 qemu-kvm-6.0.0 Steps: 1. Create a nbd server # qemu-img create -f qcow2 /var/lib/libvirt/images/fedora-1.qcow2 10G -o preallocation=full # qemu-nbd -e 10 /var/lib/libvirt/images/fedora-1.qcow2 -p 10001 2. Prepare a running VM # virsh list Id Name State ------------------------ 3 fedora running # virsh dumpxml 3|xmllint --xpath //disk - <disk type="file" device="disk"> <driver name="qemu" type="qcow2"/> <source file="/var/lib/libvirt/images/fedora.qcow2" index="1"/> <backingStore/> <target dev="hda" bus="ide"/> <alias name="ide0-0-0"/> <address type="drive" controller="0" bus="0" target="0" unit="0"/> </disk> 3. Blockcopy to a nbd dest xml with --reuse-external # cat /tmp/copy.xml <disk type='network' device='disk'> <driver name='qemu' type='qcow2'/> <source protocol="nbd"> <host name="localhost" port="10001" /> </source> <backingStore/> <target dev='hda' bus='ide'/> </disk> # virsh blockcopy fedora hda --xml /tmp/copy.xml --transient-job --wait --verbose --finish --reuse-external error: unsupported configuration: reused mirror destination format must be specified But it works without --reuse-external # virsh blockcopy fedora hda --xml /tmp/copy.xml --transient-job --wait --verbose --finish Block Copy: [100 %] Successfully copied Since it is clear that the format of dest image is qcow2, the error message "reused mirror destination format must be specified" is wrong. The blockcopy with network disk + --reuse-external should either be supported or post a better error message. I am not sure if --reuse-external flag is only for file type disk. It seems the description of VIR_DOMAIN_BLOCK_COPY_REUSE_EXT( https://github.com/libvirt/libvirt/blob/7c08141f906e20e730c4b6407bc638e743d…) indicates this flag is for file only: * VIR_DOMAIN_BLOCK_COPY_REUSE_EXT flag is present stating that the file * was pre-created with the correct format and metadata and sufficient * size to hold the copy. In case the VIR_DOMAIN_BLOCK_COPY_SHALLOW flag * is used the pre-created file has to exhibit the same guest visible contents * as the backing file of the original image. This allows a management app to * pre-create files with relative backing file names, rather than the default * of absolute backing file names. Please help to confirm if it is a bug here.

1 0

issue when not using acpi indices in libvirt 7.4.0 and qemu 6.0.0
by Riccardo Ravaioli 25 Jun '21

25 Jun '21

Hi everyone, We have an issue with how network interfaces are presented in the VM with the latest libvirt 7.4.0 and qemu 6.0.0. Previously, we were on libvirt 7.0.0 and qemu 5.2.0, and we used increasing virtual PCI addresses for any type of network interface (virtio, PCI passthrough, SRIOV) in order to decide the interface order inside the VM. For instance the following snippet yields ens1, ens2 and ens3 in a Debian Buster VM: <interface type="ethernet"> <target dev="0.vSrv"/> <mac address="52:54:00:aa:cc:05"/> <address bus="0x01" domain="0x0000" function="0x0" slot="0x01" type="pci"/> <model type="virtio"/> <driver> <host csum="off"/> </driver> </interface> <interface type="ethernet"> <target dev="1.vSrv"/> <mac address="52:54:00:aa:bb:81"/> <address bus="0x01" domain="0x0000" function="0x0" slot="0x02" type="pci"/> <model type="virtio"/> <driver> <host csum="off"/> </driver> </interface> <hostdev managed="yes" mode="subsystem" type="pci"> <source> <address bus="0x0d" domain="0x0000" function="0x0" slot="0x00"/> </source> <address bus="0x01" domain="0x0000" function="0x0" slot="0x03" type="pci"/> </hostdev> After upgrading to libvirt 7.4.0 and qemu 6.0.0, the XML snippet above yielded: - ens1 for the first virtio interface => OK - rename4 for the second virtio interface => **KO** - ens3 for the PCI passthrough interface => OK Argh! What happened to ens2? By running udev inside the VM, I see that "rename4" is the result of a conflict between the ID_NET_NAME_SLOT of the second and the third interface, both appearing as ID_NET_NAME_SLOT=ens3. In theory rename4 should show ID_NET_NAME_SLOT=ens2. What happened? # udevadm info -q all /sys/class/net/rename4 P: /devices/pci0000:00/0000:00:03.0/0000:01:02.0/virtio4/net/rename4 L: 0 E: DEVPATH=/devices/pci0000:00/0000:00:03.0/0000:01:02.0/virtio4/net/rename4 E: INTERFACE=rename4 E: IFINDEX=4 E: SUBSYSTEM=net E: USEC_INITIALIZED=94191911 E: ID_NET_NAMING_SCHEME=v240 E: ID_NET_NAME_MAC=enx525400aabba1 E: ID_NET_NAME_PATH=enp1s2 E: ID_NET_NAME_SLOT=ens3 E: ID_BUS=pci E: ID_VENDOR_ID=0x1af4 E: ID_MODEL_ID=0x1000 E: ID_PCI_CLASS_FROM_DATABASE=Network controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller E: ID_VENDOR_FROM_DATABASE=Red Hat, Inc. E: ID_MODEL_FROM_DATABASE=Virtio network device E: ID_PATH=pci-0000:01:02.0 E: ID_PATH_TAG=pci-0000_01_02_0 E: ID_NET_DRIVER=virtio_net E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/rename4 E: TAGS=:systemd: # udevadm info -q all /sys/class/net/ens3 P: /devices/pci0000:00/0000:00:03.0/0000:01:03.0/net/ens3 L: 0 E: DEVPATH=/devices/pci0000:00/0000:00:03.0/0000:01:03.0/net/ens3 E: INTERFACE=ens3 E: IFINDEX=2 E: SUBSYSTEM=net E: USEC_INITIALIZED=3600940 E: ID_NET_NAMING_SCHEME=v240 E: ID_NET_NAME_MAC=enx00900b621235 E: ID_OUI_FROM_DATABASE=LANNER ELECTRONICS, INC. E: ID_NET_NAME_PATH=enp1s3 E: ID_NET_NAME_SLOT=ens3 E: ID_BUS=pci E: ID_VENDOR_ID=0x8086 E: ID_MODEL_ID=0x1533 E: ID_PCI_CLASS_FROM_DATABASE=Network controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller E: ID_VENDOR_FROM_DATABASE=Intel Corporation E: ID_MODEL_FROM_DATABASE=I210 Gigabit Network Connection E: ID_PATH=pci-0000:01:03.0 E: ID_PATH_TAG=pci-0000_01_03_0 E: ID_NET_DRIVER=igb E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/ens3 E: TAGS=:systemd: Is there anything we can do in the XML definition of the VM to fix this? The PCI tree from within the VM is the following, if it helps: (with libvirt 7.0.0 and qemu 5.2.0 it was the same) # lspci -tv -[0000:00]-+-00.0 Intel Corporation 440FX - 82441FX PMC [Natoma] +-01.0 Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] +-01.1 Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] +-01.2 Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] +-01.3 Intel Corporation 82371AB/EB/MB PIIX4 ACPI +-02.0 Cirrus Logic GD 5446 +-03.0-[01]--+-01.0 Red Hat, Inc. Virtio network device | +-02.0 Red Hat, Inc. Virtio network device | \-03.0 Intel Corporation I210 Gigabit Network Connection +-04.0-[02]-- +-05.0-[03]-- +-06.0-[04]-- +-07.0-[05]-- +-08.0-[06]----01.0 Red Hat, Inc. Virtio block device +-09.0 Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] +-0a.0 Red Hat, Inc. Virtio console +-0b.0 Red Hat, Inc. Virtio memory balloon \-0c.0 Red Hat, Inc. Virtio RNG I see that a new feature in qemu and libvirt is to add ACPI indices in order to have network interfaces appear as *onboard* and sort them through this index as opposed to virtual PCI addresses. This is great. I see that in this case, interfaces appear as eno1, eno2, etc. However, for the sake of backward compatibility, is there a way to have the previous behaviour where interfaces were called by their PCI slot number (ens1, ens2, etc.)? If I move to the new naming yielded by ACPI indices, I am mostly worried about any possible change in interface names that might occur across VMs running different OS's, with respect to what we had before with libvirt 7.0.0 and qemu 5.2.0. Thanks! Best, Riccardo Ravaioli

3 4