[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#863266: marked as done (libvirt-daemon: spice port conflict - multiple VMs want Port 5900)

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 --- 
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 --- 
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 Thompson

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
Reply to: