Bug 819805 - host interfaces commands relevant issues
host interfaces commands relevant issues
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.3
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Laine Stump
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-08 05:15 EDT by Alex Jia
Modified: 2012-05-22 23:55 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-22 15:37:13 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alex Jia 2012-05-08 05:15:28 EDT
Description of problem:
At present, host interfaces commands exists many issues, for example, can successfully define the same interface XML configuration many times, also can start a inactive interface many times and destroy a inactive interface many times without any error, etc.

Version-Release number of selected component (if applicable):
# rpm -q libvirt netcf-libs selinux-policy
libvirt-0.9.10-16.el6.x86_64
netcf-libs-0.1.9-2.el6.x86_64
selinux-policy-3.7.19-148.el6.noarch

How reproducible:
always.

Steps to Reproduce:
# cat /tmp/iface.xml 
<interface type="ethernet" name="eth1">
  <start mode="onboot"/>
  <protocol family="ipv4">
    <ip address="192.168.0.5" prefix="24"/>
    <route gateway="192.168.0.1"/>
  </protocol>
</interface>

# virsh iface-define /tmp/iface.xml 
Interface eth1 defined from /tmp/iface.xml

# virsh iface-define /tmp/iface.xml 
Interface eth1 defined from /tmp/iface.xml

Notes, can successfully define the same iface XML configuration many times without any warning or error like this "xxx exists xxxx", it should be a common issues, at present, also can find similar issue on define the same XML configuration of domain and storage, etc.

# virsh iface-list --all
Name                 State      MAC Address
--------------------------------------------
eth0                 active     00:23:ae:6f:f1:d7
lo                   active     00:00:00:00:00:00
eth1                 inactive

# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
ONBOOT=yes
BOOTPROTO=none
IPADDR=192.168.0.5
NETMASK=255.255.255.0
GATEWAY=192.168.0.1

# virsh iface-dumpxml eth1
<interface type='ethernet' name='eth1'>
</interface>

Notes, don't know which protocol family is used based on the above ifcfg-eth1 or eth1 XML dump.

# virsh iface-start eth1
Interface eth1 started

# echo $?
0

# virsh iface-list --all
Name                 State      MAC Address
--------------------------------------------
eth0                 active     00:23:ae:6f:f1:d7
lo                   active     00:00:00:00:00:00
eth1                 inactive 

# virsh iface-dumpxml eth0
<interface type='ethernet' name='eth0'>
  <mac address='00:23:ae:6f:f1:d7'/>
  <protocol family='ipv4'>
    <ip address='192.168.0.5' prefix='24'/>
  </protocol>
  <protocol family='ipv6'>
    <ip address='fe80::223:aeff:fe6f:f1d7' prefix='64'/>
  </protocol>
</interface>

Notes, the 'eth0' is assigned 'eth1' private ip address when run virsh iface-start eth1, it will result in host can't access public network.

# virsh iface-start eth1
Interface eth1 started

# virsh iface-start eth1
Interface eth1 started

# virsh iface-list --all | grep eth1
eth1                 inactive


Notes, in fact, I can't find a 'eth1' on my host by ifconfig -a|grep eth1, and 'eth1' still is inactive. In addition, I also can't find error information in libvirtd.log.

# virsh iface-destroy eth1
Interface eth1 destroyed

# echo $?
0

# virsh iface-destroy eth1
Interface eth1 destroyed

Notes, the similar issue for virsh iface-destroy, the current 'eth1' is inactive not active, but I can successfully run virsh iface-destroy.


Actual results:
see above.

Expected results:
fix these.

Additional info:
There is only 'eth0' interface on my host:
# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:23:AE:6F:F1:D7  
          inet addr:10.66.4.201  Bcast:10.66.7.255  Mask:255.255.252.0
          inet6 addr: fe80::223:aeff:fe6f:f1d7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8152350 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9585077 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3488405075 (3.2 GiB)  TX bytes:5036620794 (4.6 GiB)
          Interrupt:21 Memory:febe0000-fec00000

# ifconfig eth1
eth1: error fetching interface information: Device not found
Comment 2 Alex Jia 2012-05-08 06:09:33 EDT
(In reply to comment #0)
> # cat /tmp/iface.xml 
> <interface type="ethernet" name="eth1">
>   <start mode="onboot"/>
>   <protocol family="ipv4">
>     <ip address="192.168.0.5" prefix="24"/>
>     <route gateway="192.168.0.1"/>
>   </protocol>
> </interface>
> 
In addition, if I specify name='eth0' in the above iface.xml then define the interface from iface.xml, it's successful without any warning or error, and then my host eth0 configuration is override.
Comment 3 Laine Stump 2012-05-09 16:05:12 EDT
This bug report touches a lot of area, so I'll try to enumerate each "problem" described:

0)
> Additional info:
> There is only 'eth0' interface on my host:

That is a large part of your problem. The virsh iface-* commands are not privy to what hardware is actually present on the machine; they only take the XML configuration info you provide to them and translate it into ifcfg-* files understandable by /sbin/ifup and /sbin/ifdown, and later call those two shell scripts to start/stop the interface. The only method the iface-* commands have of learning that an interface doesn't actually exist in the hardware is via failure of /sbin/ifup; it turns out that in RHEL6 (and also in Fedora 16), if you try to ifup an interface that has no MAC address defined, and that doesn't actually exist, /sbin/ifup will not only return success, but prior to that will set whatever IP address you've configured for the non-existent interface into *every existing ethernet interface that doesn't already have an IP address* (and some that do; I haven't yet determined the exact pattern). (In F17, /sbin/ifup will properly fail if you try to ifup a non-existent interface).

(Once this improper behavior is better classified, it should be filed as a bug against the initscripts component, or possibly NetworkManager (my system has NetworkManager enabled, and ifup ends up just calling NetworkManager, so it's unclear who is really at fault)).

The bottom line is that it's assumed that, prior to defining an interface config with virsh iface-define, the user / management application will have determined what interfaces actually exist in the hardware (via libvirt's nodedev api, or manually looking at the output of ifconfig -a, for example).

1)

> Notes, can successfully define the same iface XML configuration many times
> without any warning or error like this "xxx exists xxxx", it should be a
> common issues, at present, also can find similar issue on define the same XML
> configuration of domain and storage, etc.

NOTABUG - Redefining an interface (or domain or network or ...) is explicitly permitted by libvirt - that's how an existing entity is edited (and internally, how "virsh edit / net-edit / iface-edit" are implemented.

2) 

> can start a inactive interface many times and destroy a inactive interface
> many times without any error, etc.

virsh iface-start and virsh iface-destroy simply call netcf's ifup and ifdown commands, which themselves exec /sbin/ifup and /sbin/ifdown. They rely on those scripts to determine what is and isn't an error. I have verified that they behave as you indicate on RHEL6.3 *when operating on a non-existent device* (see above for why that is a problem with initscripts, not libvirt or netcf).

You will see the same behavior in Fedora 16, but it is fixed in F17.

For interfaces that *do exist*, things are a bit different. An attempt to iface-start / ifup one of these interfaces that is already up is successful; that's because ifup takes it as an indication to reread the configuration of the interface and update its state accordingly - this allows you to change the IP address of an interface and update it without suffering a period where the interface is completely down (which could lead to an unreachable machine).

Finally, for an existing interface, an attempt to iface-destroy / ifdown that interface multiple times will properly result in an error.

So, again, NOTABUG.

3)

# virsh iface-dumpxml eth1
> <interface type='ethernet' name='eth1'>
> </interface>

> Notes, don't know which protocol family is used based on the above ifcfg-eth1
> or eth1 XML dump.

Because you haven't specified "--inactive", you will get the current running status of the interface. But the interface isn't running, so nothing is returned. If you want to see the IP information you configured, you should run:

  # virsh iface-dumpxml --inactive eth1

There *might* be a case for having iface-dumpxml behave similarly to dumpxml - if an interface isn't active, return the --inactive (i.e. config) XML rather than live status. That would require discussion though.

4)

> In addition, if I specify name='eth0' in the above iface.xml then define the
> interface from iface.xml, it's successful without any warning or error, and
> then my host eth0 configuration is override.

In other words, it's done exactly what you told it to do. Just as re-defining an existing domain with completely different information will succeed without any warning or error. See item (0) - NOTABUG.


In the end, I see one valid issue here - that ifup and ifdown don't return an error if you attempt to ifup/ifdown a non-existing device (and will set the IP address of other unrelated interfaces in the process). That last bit wasn't included in the description here, though, and I think it would probably be better to file a completely new bug so that the initscripts people don't have to wade through so much verbiage to get to the part that concerns them.
Comment 4 Laine Stump 2012-05-22 15:37:13 EDT
I just filed Bug 824130 against NetworkManager (I found that when NM is disabled and the network service is enabled, attempts to ifup a non-existent interface will properly end in error, but when NetworkManager is enabled, it will report success but instead setup *some other interface* with the desired configuration).

Since that's the one item in this report that I see as needing attention, and since it's not a libvirt (or netcf) problem, I'm closing this BZ.
Comment 5 Alex Jia 2012-05-22 23:55:34 EDT
(In reply to comment #4)
> I just filed Bug 824130 against NetworkManager (I found that when NM is
Great, thx.
> disabled and the network service is enabled, attempts to ifup a non-existent
> interface will properly end in error, but when NetworkManager is enabled, it
> will report success but instead setup *some other interface* with the
> desired configuration).
Yeah, we also confirm this.
> 
> Since that's the one item in this report that I see as needing attention,
> and since it's not a libvirt (or netcf) problem, I'm closing this BZ.
Indeed, Agree, however, although libvirt uses netcf library to manage host interface then simply call ifup and ifdown cmds, and so forth, I worry about libvirt users use virsh iface-* cmds result in original host network(such as eth0) aren't available, but libvirt hasn't raise any warning message with NetworkManager is enabled, then some users probably don't know how to recovery original network, it may be a trouble.

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