Your message dated Thu, 12 Jul 2018 23:56:54 +0100 with message-id <044dbce23c72893ad5be1efeaa59caa8e6a6948e.camel@decadent.org.uk> and subject line Re: libvirt-daemon: spice port conflict - multiple VMs want Port 5900 has caused the Debian Bug report #863266, regarding libvirt-daemon: spice port conflict - multiple VMs want Port 5900 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) -- 863266: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863266 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: libvirt-daemon: spice port conflict - multiple VMs want Port 5900
- From: Marc Haber <mh+debian-packages@zugschlus.de>
- Date: Wed, 24 May 2017 17:24:51 +0200
- Message-id: <149563949102.15236.8296682453434983486.reportbug@swivel.zugschlus.de>
Package: libvirt-daemon Version: 3.0.0-4 Severity: normal Dear Maintainer, somewhere in mid-may, libvirt broke in regard to autoport and SPICE in sid. On my systems, I cannot start more than a single VM any more; libvirt complains that Port 5900 is already in use: [3/6034]mh@swivel:~ $ virsh start test01 error: Failed to start domain test01 error: internal error: process exited while connecting to monitor: ((null):9786): Spice-Warning **: reds.c:2499:reds_init_socket: listen: Address already in use 2017-05-24T14:26:01.824277Z qemu-system-x86_64: failed to initialize spice server This affects both newly defined domains and older domains as well, including domains that used to happily run concurrently before may. There is a number of reports regarding this out on the net, mostly from Red Hat users, but Red Hat is on a fairly more recent version of libvirt than we are. Also, those bug reports all do suggest that this is a race condition when domains get started quickly after each other, but I am also seeing this when starting the second domain minutes after the first one was started, the system has settled down and a qemu process with "-spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on" has become visible in the process list. I doubt that this issue is actually caused by libvirt itself. The last libvirt update was back in March, and I upgrade my sid about twice a month, and the breakage is fairly recent. I do create my domains with virt-manager's help, but virt-manager also hasn't been updated recently. Here is the tail of which-pkg-broke libvirt-daemon: enstore3.0:amd64 Thu May 4 20:09:36 2017 libxen-4.8:amd64 Thu May 4 20:09:37 2017 libudev1:amd64 Sat May 13 09:35:52 2017 libsystemd0:amd64 Sat May 13 09:35:54 2017 librbd1 Sat May 13 09:37:38 2017 librados2 Sat May 13 09:37:38 2017 dpkg Mon May 22 06:30:16 2017 gcc-6-base:amd64 Mon May 22 06:30:18 2017 libstdc++6:amd64 Mon May 22 06:30:19 2017 libgcc1:amd64 Mon May 22 06:30:43 2017 debconf Mon May 22 06:30:56 2017 New domains get created with <graphics type='spice' autoport='yes'> <listen type='address'/> <image compression='off'/> </graphics> which mutates on a running domain to <graphics type='spice' port='5900' autoport='yes' listen='127.0.0.1'> <listen type='address' address='127.0.0.1'/> <image compression='off'/> </graphics> Changing the XML on the second domain to <graphics type='spice' port='5933' autoport='no'> <listen type='address'/> <image compression='off'/> </graphics> allows me to happily start the second domain, but this of course does not scale at all. If there is anything I can help to debug, please let me know.# Greetings Marc -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.2-zgws1 (SMP w/4 CPU cores) Locale: LANG=en_DK.utf8, LC_CTYPE=en_DK.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libvirt-daemon depends on: ii libapparmor1 2.11.0-3 ii libaudit1 1:2.6.7-2 ii libavahi-client3 0.6.32-2 ii libavahi-common3 0.6.32-2 ii libblkid1 2.29.2-1 ii libc6 2.24-10 ii libcap-ng0 0.7.7-3+b1 ii libdbus-1-3 1.10.18-1 ii libdevmapper1.02.1 2:1.02.137-2 ii libfuse2 2.9.7-1 ii libgnutls30 3.5.8-5 ii libnetcf1 1:0.2.8-1+b2 ii libnl-3-200 3.2.27-2 ii libnl-route-3-200 3.2.27-2 ii libnuma1 2.0.11-2.1 ii libparted2 3.2-17 ii libpcap0.8 1.8.1-3 ii libpciaccess0 0.13.4-1+b2 ii librados2 10.2.5-7 ii librbd1 10.2.5-7 ii libsasl2-2 2.1.27~101-g0780600+dfsg-3 ii libselinux1 2.6-3+b1 ii libssh2-1 1.8.0-1 ii libudev1 232-23 ii libvirt0 3.0.0-4 ii libxen-4.8 4.8.1-1+deb9u1 ii libxenstore3.0 4.8.1-1+deb9u1 ii libxml2 2.9.4+dfsg1-2.2 ii libyajl2 2.1.0-2+b3 Versions of packages libvirt-daemon recommends: ii libxml2-utils 2.9.4+dfsg1-2.2 ii netcat-openbsd 1.130-3 ii qemu-kvm 1:2.8+dfsg-5 Versions of packages libvirt-daemon suggests: ii libvirt-daemon-system 3.0.0-4 pn numad <none> -- no debconf information
--- End Message ---
--- Begin Message ---
- To: 863266-done@bugs.debian.org
- Subject: Re: libvirt-daemon: spice port conflict - multiple VMs want Port 5900
- From: Ben Hutchings <ben@decadent.org.uk>
- Date: Thu, 12 Jul 2018 23:56:54 +0100
- Message-id: <044dbce23c72893ad5be1efeaa59caa8e6a6948e.camel@decadent.org.uk>
- In-reply-to: <149563949102.15236.8296682453434983486.reportbug@swivel.zugschlus.de>
- References: <149563949102.15236.8296682453434983486.reportbug@swivel.zugschlus.de>
Version: 4.14~rc3-1~exp1 This was fixed upstream by the following commits which went into 4.14-rc2: cbb2fb5c72f4 net: set tb->fast_sk_family 7a56673b58f2 net: use inet6_rcv_saddr to compare sockets fbed24bcc69d inet: fix improper empty comparison Ben. -- Ben Hutchings When in doubt, use brute force. - Ken ThompsonAttachment: signature.asc
Description: This is a digitally signed message part
--- End Message ---