Description of problem: Bridge device missing; VM will not start Version-Release number of selected component (if applicable): VMM 0.10.0 kernel 3.12.6-300.fc20.x86_64 How reproducible: 20% (seen twice in last week) Steps to Reproduce: 1. Start VMM 2. Doubleclick client to open 3. Click "run" gadget Actual results: Error popup "Error starting domain: Cannot get interface MTU on 'virbr0': No such device" Expected results: VM starts Additional info: Interfaces present: em1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1412 virbr0-nic: flags=4098<BROADCAST,MULTICAST> mtu 1500 wlp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 A reboot fixed it the first time.
Anything in dmesg or journalctl that might be related? Wonder if it has anything to do with https://bugzilla.redhat.com/show_bug.cgi?id=1053760 ... what's your firewalld version? Rather than reboot, you should be able to do 'sudo virsh net-destroy default ; sudo virsh net-start default'
firewalld-0.3.9-1.fc20.noarch
Nothing obviously relevant from journalctl (system time is GMT): Jan 15 09:51:49 localhost.localdomain /etc/gdm/Xsession[1851]: (thunderbird:2525): GLib-GObject-WARNING **: gsignal.c:3431: signal name 'selection_changed' is invalid for instance '0x7f48c8b Jan 15 09:51:49 localhost.localdomain /etc/gdm/Xsession[1851]: (thunderbird:2525): GLib-GObject-WARNING **: gsignal.c:3431: signal name 'selection_changed' is invalid for instance '0x7f48c8b Jan 15 09:52:13 localhost.localdomain /etc/gdm/Xsession[1851]: (xfce4-session:2013): GLib-GObject-CRITICAL **: g_value_get_boxed: assertion 'G_VALUE_HOLDS_BOXED (value)' failed Jan 15 09:52:13 localhost.localdomain /etc/gdm/Xsession[1851]: (xfce4-session:2013): libxfce4util-CRITICAL **: IA__xfce_rc_write_list_entry: assertion 'value != NULL' failed Jan 15 09:52:13 localhost.localdomain /etc/gdm/Xsession[1851]: (xfce4-session:2013): GLib-GObject-CRITICAL **: g_value_get_boxed: assertion 'G_VALUE_HOLDS_BOXED (value)' failed Jan 15 09:52:13 localhost.localdomain /etc/gdm/Xsession[1851]: (xfce4-session:2013): libxfce4util-CRITICAL **: IA__xfce_rc_write_list_entry: assertion 'value != NULL' failed Jan 15 09:52:14 localhost.localdomain systemd[1844]: Stopping Default. Jan 15 09:52:14 localhost.localdomain systemd[1844]: Stopped target Default. Jan 15 09:52:14 localhost.localdomain systemd[1844]: Starting Shutdown. Jan 15 09:52:14 localhost.localdomain systemd[1844]: Reached target Shutdown. Jan 15 09:52:14 localhost.localdomain systemd[1844]: Starting Exit the Session... -- Reboot --
A trivial reproducer for this: (1) Log in as root or sudo. (2) Run: # guestfish -a /dev/null --network run libguestfs: error: could not create appliance through libvirt. Try running qemu directly without libvirt using this environment variable: export LIBGUESTFS_BACKEND=direct Original error from libvirt: Cannot get interface MTU on 'virbr0': No such device [code=38 domain=0]
So it turns out the problem happens when the default network "disappears" (as it often does -- many report this eg [1], but we don't know when or why it happens). Machine where comment 4 doesn't fail: # virsh net-list --all Name State Autostart Persistent ---------------------------------------------------------- default active yes yes Machine were comment 4 fails: # virsh net-list --all Name State Autostart Persistent ---------------------------------------------------------- [1] http://serverfault.com/questions/534484/libvirt-network-error-no-default-network-device-found
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Moving to the upstream tracker. Has anyone seen this with recent libvirt versions?
Not this specific error, no.
I kind of suspect this was a host kernel issue or something. Closing, but if anyone can still reproduce with recent distro and libvirt versions, please reopen. Particularly interesting is if anyone can figure out what steps result in the bridge disappearing