Bug 1053532 - Cannot get interface MTU on 'virbr0': No such device (default network 'disappears')
Summary: Cannot get interface MTU on 'virbr0': No such device (default network 'disapp...
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs
TreeView+ depends on / blocked
 
Reported: 2014-01-15 11:37 UTC by Jeremy Harris
Modified: 2016-04-26 13:59 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-10 17:28:54 UTC


Attachments (Terms of Use)

Description Jeremy Harris 2014-01-15 11:37:19 UTC
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.

Comment 1 Cole Robinson 2014-01-18 00:02:10 UTC
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'

Comment 2 Jeremy Harris 2014-01-20 10:34:16 UTC
firewalld-0.3.9-1.fc20.noarch

Comment 3 Jeremy Harris 2014-01-20 10:40:59 UTC
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 --

Comment 4 Richard W.M. Jones 2015-03-17 22:08:10 UTC
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]

Comment 5 Richard W.M. Jones 2015-03-17 22:22:47 UTC
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

Comment 6 Jan Kurik 2015-07-15 14:43:45 UTC
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

Comment 7 Cole Robinson 2016-03-17 01:06:45 UTC
Moving to the upstream tracker. Has anyone seen this with recent libvirt versions?

Comment 8 Richard W.M. Jones 2016-03-17 10:19:51 UTC
Not this specific error, no.

Comment 9 Cole Robinson 2016-04-10 17:28:54 UTC
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


Note You need to log in before you can comment on or make changes to this bug.