We now need to find out what the difference is: a) your test case is slightly different and you can trigger it on the same SW levels it works for me, then we need to report that to upstream as those are the very latest versions b) your test is good once you use the more recent SW levels, in that case we need to drill down into your crash and identify the fix (that must be in between qemu 2.11 and 3.1 somewhere) to consider backporting it. c) This would be arch dependent (I tested x86), but we would find that further down the road as you'd report (a) to happen. After all TUNSETVNETLE is for setting big/little endian operations for linux tap/macvtap so it could be s390x only after all.
I can't re-deploy the system to use Bionic level components that you use at the moment and that also would only answer (b) but not (a). Therefore to differentiate between the above I'd want to ask you if you could re-run your test on Ubuntu 19.04 with Proposed enabled [1] as the new openvswitch still is in proposed for now. Report back if you can still trigger the issue, but then I'll most likely encourage you to report it upstream and I'd then participate in the discussion there - probably building test PPAs for you as needed. Also report back if this SW stack works for you as well, in that case I'd wonder if you get an actual crash in /var/crash that would help where in the qemu code we would look for TUNSETVNETLE ioctl() failed: File descriptor in bad state. I'd assume net/tap-linux.c in tap_fd_set_vnet_le, but let's be sure. [1]: https://wiki.ubuntu.com/Testing/EnableProposed ** Changed in: qemu (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1812822 Title: Guest crashed when detaching the ovs interface device Status in Ubuntu on IBM z Systems: New Status in linux package in Ubuntu: Incomplete Status in qemu package in Ubuntu: Incomplete Bug description: When detaching one openvswitch interface device with virsh detach-device, if the port has been deleted from the ovs and the interface device has been deleted. The virsh detach-device will fail with "error: Unable to read from monitor: Connection reset by peer", the qemu is terminated and the log shows " UNSETVNETLE ioctl() failed, File descriptor in bad state". [Background] This error is originally found from the openstack KVM CI tempest test. By investigating I found it's introduced by one ovs-vif patch, which deletes the ovs port and delete the interface before detaching the device. You can find the commit from https://bugs.launchpad.net/os-vif/+bug/1801072 Reproduced: root@xxxx:~# ovs-vsctl del-port br0 tap9273235a-dd root@xxxx:~# ip link del tap9273235a-dd The interface device tap9273235a-dd has been removed from the host(ifconfg, ovs-vsctl show) and can be found in the guest.(logon the guest, ip a it's in down state) root@xxxx:~# virsh detach-device kvm net.xml error: Failed to detach device from net.xml error: Unable to read from monitor: Connection reset by peer The qemu has terminated and the log in /var/log/libvirt/qemu/kvm.log TUNSETVNETLE ioctl() failed: File descriptor in bad state. 2019-01-18 08:16:11.304+0000: shutting down, reason=crashed It seems the qemu tried to handle this interface, but in fact it has been deleted. qemu couldn't read the file and give the error. But I don't think the guest should be crashed directly for the file descriptor error. Environment: Ubuntu 16.04.5 LTS Linux (EC12) 4.4.0-141-generic QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.5~cloud0) libvirtd (libvirt) 4.0.0 net.xml <interface type='bridge'> <mac address='52:54:00:fb:5c:46'/> <source bridge='br0'/> <virtualport type='openvswitch'> <parameters interfaceid='9273234d-9ad4-4ecf-8869-d63ac17a0e6d'/> </virtualport> <target dev='tap9273235a-dd'/> <model type='virtio'/> <mtu size='1450'/> <alias name='net1'/> <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0005'/> </interface> kvm.xml <domain type='kvm' id='31'> <name>kvm</name> <uuid>59f71b47-16e4-401d-9d33-30bc1605a84a</uuid> <memory unit='KiB'>524288</memory> <currentMemory unit='KiB'>524288</currentMemory> <vcpu placement='static'>1</vcpu> <resource> <partition>/machine</partition> </resource> <os> <type arch='s390x' machine='s390-ccw-virtio-bionic'>hvm</type> <boot dev='hd'/> </os> <cpu> <topology sockets='1' cores='1' threads='1'/> </cpu> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/bin/qemu-system-s390x</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/root/xenial-minimal.qcow2'/> <backingStore/> <target dev='vda' bus='virtio'/> <alias name='virtio-disk0'/> <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0000'/> </disk> <console type='pty' tty='/dev/pts/2'> <source path='/dev/pts/2'/> <target type='sclp' port='0'/> <alias name='console0'/> </console> <memballoon model='virtio'> <alias name='balloon0'/> <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0001'/> </memballoon> <panic model='s390'/> </devices> <seclabel type='dynamic' model='apparmor' relabel='yes'> <label>libvirt-59f71b47-16e4-401d-9d33-30bc1605a84a</label> <imagelabel>libvirt-59f71b47-16e4-401d-9d33-30bc1605a84a</imagelabel> </seclabel> <seclabel type='dynamic' model='dac' relabel='yes'> <label>+0:+0</label> <imagelabel>+0:+0</imagelabel> </seclabel> </domain> To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1812822/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
