(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.

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.

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.

(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.