Bug 1154480

Summary: Start mode can only show as 'none' in Network Interfaces though changed to 'onboot' or 'hotplug'
Product: Red Hat Enterprise Linux 7 Reporter: zhoujunqin <juzhou>
Component: virt-managerAssignee: Giuseppe Scrivano <gscrivan>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: dyuan, gscrivan, mzhan, riehecky, tzheng
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: virt-manager-1.2.0-3-el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-19 05:22:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
virt-manager-debug.log none

Description zhoujunqin 2014-10-20 03:59:11 UTC
Created attachment 948380 [details]
virt-manager-debug.log

Description of problem:
Start mode can only show as 'none' in Network Interfaces though changed to 'noboot' or 'hotplug'

Version-Release number of selected component (if applicable):
libvirt-1.2.8-5.el7.x86_64
virt-manager-1.1.0-4.el7.noarch
pygobject3-3.8.2-6.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Launch virt-manager: #virt-manager.
2. Click Edit->Host Details.
3. Click Network Interfaces tab on Host Details dialogue.
4. Click + button.
5. Select interface type as 'VLAN', click Forward button.
6. Select start mode as 'hotplug', enable activate now, Fill VLAN tag as 1, choose eth0 as parent interface. Click Finish button.
7. After eth0.1 showing, check its start mode.
8. Repeated step 6 and step7 again with choosing start mode as 'onboot'.

Actual results:
Though changed, Start mode just showing 'none'.

Expected results:
Start mode should show correctly.

Additional info:
Cannot reproduce this issue with virt-manager version: virt-manager-0.10.0-20.el7.noarch

Comment 5 Giuseppe Scrivano 2015-05-14 14:38:17 UTC
I found an easier way to address the issue.

Patch proposed upstream:

https://www.redhat.com/archives/virt-tools-list/2015-May/msg00050.html

Comment 8 fwu 2015-06-01 07:16:17 UTC
I can reproduce this bug with package:
virt-manager-1.1.0-4.el7.noarch

Steps are the same as description.

Then verify with the latest:
virt-manager-1.2.0-4.el7.noarch

Scenario 1: Uncheck "active now" when create VLAN network
Steps:
1. Launch virt-manager: #virt-manager.
2. Click Edit->Host Details.
3. Click Network Interfaces tab on Host Details dialogue.
4. Click + button.
5. Select interface type as 'VLAN', click Forward button.
6. Select start mode as 'hotplug', disable activate now, Fill VLAN tag as 1, configure IP settings as IPV4: DHCP, choose enp0s25 as parent interface. Click Finish button.
7. After enp0s25 appear, start the interface. Check the start mode of vlan network.
8. Repeat step 6 and step7 again with choosing start mode as 'onboot'.

Result:
1. After Step 7, start mode was shown correctly.
2. Start the interface, after 1-2 minute, an error message occur. The status of the interface is inactive. Re-enter this tab, the status of this interface become active.
Error creating interface: 'Could not create interface: internal error: failed to create (start) interface enp0s25.1: failed to execute external program - Running 'ifup enp0s25.1' failed with exit code 1: 
Determining IP information for enp0s25.1... failed.
'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/createinterface.py", line 1140, in do_install
    self.interface.install(meter, create=activate)
  File "/usr/share/virt-manager/virtinst/interface.py", line 273, in install
    raise RuntimeError(errmsg)
RuntimeError: Could not create interface: internal error: failed to create (start) interface enp0s25.1: failed to execute external program - Running 'ifup enp0s25.1' failed with exit code 1: 
Determining IP information for enp0s25.1... failed.


3. Stop the interface, an error message occur. Re-enter this tab, the status of this interface become inactive.
Error stopping interface 'enp0s25.1': internal error: failed to destroy (stop) interface enp0s25.1: failed to execute external program - Running 'ifdown enp0s25.1' failed with exit code 1: 

Scenario 2: Check "active now" when create VLAN network
Steps:
1. Launch virt-manager: #virt-manager.
2. Click Edit->Host Details.
3. Click Network Interfaces tab on Host Details dialogue.
4. Click + button.
5. Select interface type as 'VLAN', click Forward button.
6. Select start mode as 'hotplug', enable activate now, Fill VLAN tag as 1, configure IP settings as IPV4: DHCP, choose enp0s25 as parent interface. Click Finish button.
7. After enp0s25 appear, check the start mode of vlan network.
8. Repeat step 6 and step7 again with choosing start mode as 'onboot'.

Result:
1.After Step 6, an error message occur. There is no newly created VLAN interface shown in virt-manager.
Error creating interface: 'Could not create interface: internal error: failed to create (start) interface enp0s25.1: failed to execute external program - Running 'ifup enp0s25.1' failed with exit code 1: 
Determining IP information for enp0s25.1... failed.
'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/createinterface.py", line 1140, in do_install
    self.interface.install(meter, create=activate)
  File "/usr/share/virt-manager/virtinst/interface.py", line 273, in install
    raise RuntimeError(errmsg)
RuntimeError: Could not create interface: internal error: failed to create (start) interface enp0s25.1: failed to execute external program - Running 'ifup enp0s25.1' failed with exit code 1: 
Determining IP information for enp0s25.1... failed.


2. Check and find a new VLAN network interface was created after Step 6.
# ifconfig -a| grep enp0s25
enp0s25: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
enp0s25.1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

As result 1 in scenario 1 shows, the bug itself was fixed.
However, when creating VLAN network, problems as Result 2,3 in scenario 1, Result 1,2 in scenario 2 will occur. If possible, could you please give me some more information about this? Thanks for your kindly help!

Comment 9 Giuseppe Scrivano 2015-06-01 09:33:43 UTC
please file it separately, as it looks as a new issue.

What happens if you manually do "ifup enp0s25.1" on the system?  What do you get?

Comment 10 fwu 2015-06-01 10:11:23 UTC
I did as you suggested.
Step 1, I created an inactive VLAN network and execute:
#ifup enp0s25.1

Determining IP information for enp0s25.1...failed.

Step 2, I found that after this command, the state of the VLAN network is active, but without ip address for ipv4.
#ifconfig enp0s25.1
enp0s25.1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::3e97:eff:fe22:ab2c  prefixlen 64  scopeid 0x20<link>
        ether 3c:97:0e:22:ab:2c  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 14  bytes 2700 (2.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Step 3, additionally, when I check the VLAN network status back on virt-manager, the status remains "inactive". However, when I switch to another tab, and then switch back, the network status was refreshed. The status was changed to "active".

Comment 11 Giuseppe Scrivano 2015-06-01 11:14:47 UTC
please file a different bug for this issue, as it requires more investigation.  I've not encountered it while working on this bug, and the proposed fix for 1154480 has no effect on it.

Comment 12 fwu 2015-06-03 09:16:50 UTC
File a new bug according to the issue I mentioned on Comment 8 - bug 1227641 

As was mentioned in comment 8, the bug itself was fixed in the latest version of virt-manager. So move the bug from ON_QA to VERIFIED.

Comment 14 errata-xmlrpc 2015-11-19 05:22:41 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2206.html