Networking issues after upgrade to 1:2.5+dfsg-5ubuntu10.37

I just noticed you released a new version already. Testing 1:2.5+dfsg-5ubuntu10.38.

Thank you for the bug report, let us know how the new version testing is going

I'm wondering as 1:2.5+dfsg-5ubuntu10.37 never existed in the wild.
The archive should have went from .36 to .38 I'd think.

There is a single upload [1] covering both.
.37 only existed in proposed I'd think.

Never the less it contained a few changes to networking.
One to slirp (not your case), but also:
  * d/p/lp1823458/add-VirtIONet-vhost_stopped-flag-to-prevent-multiple.patch,
    d/p/lp1823458/do-not-call-vhost_net_cleanup-on-running-net-from-ch.patch:
    - Prevent crash due to race condition on shutdown;
      this is fixed differently upstream (starting in Bionic), but
      the change is too large to backport into Xenial. These two very
      small patches work around the problem in an unintrusive way.
      (LP: #1823458)

I'll subscribe mdeslaur, sbeattie (uploaders) and ddstreet (patch author) to consider your case.

Please add whatever else you found, in particular:
- does every qemu start fail networking for you?
- if not what part of the config is it that seem required to hit the issue
- how is your networking set up in general (normal libvirt network, OVS, ..)?
- which network HW is attached (in case it makes a difference)?
- the guest cmdline looks like a libvirt qemu-cmdline, so you might add the guest XML

[1]: https://launchpad.net/ubuntu/+source/qemu/1:2.5+dfsg-5ubuntu10.37

Version 1:2.5+dfsg-5ubuntu10.38 doesn't fix it entirely but works better than ...10.37. It seem to lose network connectivity only on reboots of a VM. Poweroff/resume (killing and restarting the kvm process) fixes it again.

Still no error messages or something. Willing to provide more information when you tell me what you need.

@sw0x2a can you try the qemu from this ppa:
https://launchpad.net/~ddstreet/+archive/ubuntu/lp1829245

This is a OpenNebula cluster. AFAICS all hosts are effected as soon as they run with the new versions. Hosts have different hardware but similar network configuration: 2 bonded NICs and a bridged interface to be used by VMs.

 Network setup on VH host
auto lo
iface lo inet loopback
#eth0 is manually configured, and slave to the "bond0" bonded NIC
auto eth0
iface eth0 inet manual
bond-master bond1
#eth1 ditto, thus creating a 2-link bond.
auto eth1
iface eth1 inet manual
bond-master bond1
# bond1 is the bonded NIC and can be used like any other normal NIC.
auto bond1
iface bond1 inet manual
# bond1 uses standard IEEE 802.3ad LACP bonding protocol
bond-mode 802.3ad
bond-miimon 100
bond-lacp-rate 1
bond-xmit-hash-policy layer3+4
bond-slaves eth0 eth1
# Bridged interface to be used by VMs
auto ipblsrvrs
iface ipblsrvrs inet static
  bridge_ports bond1
  address 172.20.4.106
  gateway 172.20.4.1
  netmask 255.255.252.0
  bridge_stp on
  bridge_fd 1
  bridge_hello 2
  bridge_maxage 12

# Guest XML created by OpenNebula looks like this:

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
 <name>one-1110</name>
 <vcpu><![CDATA[2]]></vcpu>
 <cputune>
  <shares>205</shares>
 </cputune>
 <memory>4194304</memory>
 <os>
  <type arch='x86_64'>hvm</type>
 </os>
 <cpu mode='host-passthrough'>
 </cpu>
 <devices>
  <emulator><![CDATA[/usr/bin/kvm]]></emulator>
  <disk type='file' device='disk'>
   <source file='/var/lib/one//datastores/101/1110/disk.0'/>
   <target dev='vda'/>
   <boot order='2'/>
   <driver name='qemu' type='raw' cache='writeback'/>
  </disk>
  <disk type='file' device='cdrom'>
   <source file='/var/lib/one//datastores/101/1110/disk.1'/>
   <target dev='hda'/>
   <readonly/>
   <driver name='qemu' type='raw'/>
  </disk>
  <interface type='bridge'>
   <source bridge='ipblsrvrs'/>
   <mac address='02:00:3d:86:51:7b'/>
   <target dev='one-1110-0'/>
   <boot order='1'/>
   <model type='virtio'/>
  </interface>
  <graphics type='vnc' listen='0.0.0.0' port='7010' passwd='secret'/>
 </devices>
 <features>
  <acpi/>
 </features>
 <devices><serial type='pty'><source path='/dev/pts/5'/><target port='0'/></serial><console type='pty' tty='/dev/pts/5'><source path='/dev/pts/5'/><target port='0'/></console></devices>
 <metadata>
  <system_datastore><![CDATA[/var/lib/one//datastores/101/1110]]> </system_datastore>
 </metadata>
</domain>

@dan Ok, will try and report back soon.

@dan It works! I cannot reproduce the bug on the patched host (version 1:2.5+dfsg-5ubuntu10.38+bug1829245v20190516b1 from your ppa).

> I'm wondering as 1:2.5+dfsg-5ubuntu10.37 never existed in the wild.
> The archive should have went from .36 to .38 I'd think.

@christian: We mirror Ubuntu repositories in a way that keeps versions in our repo even when they have been removed from the original one. I guess this means version .37 was published for a moment and quickly removed again from official repos but the sync'ed it already into ours.

@sw0x2a thanks - my patch (that breaks things) will be reverted in a new release through the security pocket and i'll reapply the fixed version thru the normal sru process.

This bug was fixed in the package qemu - 1:2.5+dfsg-5ubuntu10.39

---------------
qemu (1:2.5+dfsg-5ubuntu10.39) xenial-security; urgency=medium

  * Disable patches from 1:2.5+dfsg-5ubuntu10.37 to prevent regression
    (LP: #1829245)
    - d/p/lp1823458/add-VirtIONet-vhost_stopped-flag-to-prevent-multiple.patch
    - d/p/lp1823458/do-not-call-vhost_net_cleanup-on-running-net-from-ch.patch

 -- Marc Deslauriers <email address hidden> Thu, 16 May 2019 07:11:54 -0400