Bug 657453 - virsh iface-start raise an error when first running after reboot the host
Summary: virsh iface-start raise an error when first running after reboot the host
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 628545
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-26 06:51 UTC by wangyimiao
Modified: 2012-06-07 14:02 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 628545
Environment:
Last Closed: 2012-06-07 14:02:53 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description wangyimiao 2010-11-26 06:51:59 UTC
+++ This bug was initially created as a clone of Bug #628545 +++

Description of problem:
I test with the following steps after reboot the host for getting clean environment. After reboot the host and run iface-destroy and iface-start at first time, it fails with an error. It is very strange that after I reboot the NetworkManager, the iface-destroy and iface-start successfully, but after iface-destroy the eth0 state in iface-list is still active, and in fact it is already down.


Version-Release number of selected component (if applicable):
# rpm -qa |grep netcf
netcf-libs-0.1.6-4.el6.x86_64
# rpm -qa libvirt
libvirt-0.8.1-27.el6.x86_64
# rpm -qa NetworkManager
NetworkManager-0.8.1-5.el6.x86_64
# uname -r
2.6.32-70.el6.x86_64

How reproducible:
100%

Steps to Reproduce:

# virsh iface-list 
Name                 State      MAC Address
--------------------------------------------
eth0                 active     b8:ac:6f:3b:0d:56
lo                   active     00:00:00:00:00:00

# setenforce 0
# virsh iface-destroy eth0
Interface eth0 destroyed

# virsh iface-list
Name                 State      MAC Address
--------------------------------------------
lo                   active     00:00:00:00:00:00

# virsh iface-start eth0
error: Failed to start interface eth0
error: internal error failed to create (start) interface eth0 (netcf: failed to
execute external program - Running 'ifup eth0' failed with exit code 4)

# ifup eth0
Error: Connection activation failed: Device not managed by NetworkManager
********************************************************************************
# service NetworkManager stop
Stopping NetworkManager daemon:                            [  OK  ]
# service NetworkManager start
Setting network parameters...                              [  OK  ]
Starting NetworkManager daemon:                            [  OK  ]

# virsh iface-destroy eth0
Interface eth0 destroyed
#ifconfig
eth0      Link encap:Ethernet  HWaddr B8:AC:6F:3B:0D:56  
          inet6 addr: fe80::baac:6fff:fe3b:d56/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6267 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2455 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2528300 (2.4 MiB)  TX bytes:332620 (324.8 KiB)
          Memory:fdfe0000-fe000000 
...

# virsh iface-list 
Name                 State      MAC Address
--------------------------------------------
eth0                 active     b8:ac:6f:3b:0d:56
lo                   active     00:00:00:00:00:00

Actual results:
iface-start failed with error and the state of eth0 is wrong

Expected results:
it should success with no error and the status of network interface should be correct

Additional info:

--- Additional comment from weizhan on 2010-09-01 04:21:49 EDT ---

I create the br0 with virt-manager and have the same problem after restart the host with NetworkManager started

#vi virt-manager.log

[Wed, 01 Sep 2010 15:56:35 virt-manager 3002] DEBUG (error:86) Uncaught Error: Error creating interface: 'Could not create interface: internal error failed to create (start) interface br0 (netcf: failed to execute external program - Running 'ifup br0' failed with exit code 1)' : Error creating interface: '<type 'exceptions.RuntimeError'> Could not create interface: internal error failed to create (start) interface br0 (netcf: failed to execute external program - Running 'ifup br0' failed with exit code 1)
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/createinterface.py", line 1156, in do_install
    self.interface.install(meter, create=activate)
  File "/usr/lib/python2.6/site-packages/virtinst/Interface.py", line 258, in install
    raise RuntimeError(errmsg)
RuntimeError: Could not create interface: internal error failed to create (start) interface br0 (netcf: failed to execute external program - Running 'ifup br0' failed with exit code 1)

--- Additional comment from jklimes on 2010-11-01 09:04:48 EDT ---

(In reply to comment #0)
> Description of problem:
> I test with the following steps after reboot the host for getting clean
> environment. After reboot the host and run iface-destroy and iface-start at
> first time, it fails with an error. It is very strange that after I reboot the
> NetworkManager, the iface-destroy and iface-start successfully, but after
> iface-destroy the eth0 state in iface-list is still active, and in fact it is
> already down.
> 
> # setenforce 0
> # virsh iface-destroy eth0
> Interface eth0 destroyed
> 
> # virsh iface-list
> Name                 State      MAC Address
> --------------------------------------------
> lo                   active     00:00:00:00:00:00
> 
> # virsh iface-start eth0
> error: Failed to start interface eth0
> error: internal error failed to create (start) interface eth0 (netcf: failed to
> execute external program - Running 'ifup eth0' failed with exit code 4)
> 
> # ifup eth0
> Error: Connection activation failed: Device not managed by NetworkManager
> 

It could be the same as bug 612934, 'ifdown eth0' puts the link down and thus it's not available to be successfully started with 'ifup eth0' later on.

It would be nice if virsh returned the same error message as ifup ("Device not managed by NetworkManager" not just error code 4.). BTW, the error from NM is now "Device not managed by NetworkManager or unavailable", which is more exact.

(In reply to comment #1)
The error looks the same as in bug 612068.

Comment 1 Fedora Admin XMLRPC Client 2011-09-22 17:50:40 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 2 Fedora Admin XMLRPC Client 2011-09-22 17:53:17 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 3 Fedora Admin XMLRPC Client 2011-09-22 17:58:52 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 4 Fedora Admin XMLRPC Client 2011-11-30 19:31:26 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 5 Fedora Admin XMLRPC Client 2011-11-30 19:34:52 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 6 Fedora Admin XMLRPC Client 2011-11-30 19:41:41 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 7 Fedora Admin XMLRPC Client 2011-11-30 19:52:55 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 8 Cole Robinson 2012-06-07 14:02:53 UTC
Sorry for the lack of response, but given the age of this bug, closing as WONTFIX.

If anyone can still reproduce with a more recent Fedora,
please reopen this report and we can go from there.


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