Created attachment 1235324 [details]
virt-manager debug log

1. I can reproduce the issue with
python-virtinst.noarch 0:0.600.0-30.el6    
libvirt-0.10.2-62.el6.x86_64
virt-manager-0.9.0-33.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.499.el6.x86_64

2. And after I changed to python-virtinst.noarch 0:0.600.0-29.el6, the failure disappear.

3. I'm very confused as the command "virt-xml-validate" always fail when I use it the validate the interface xml, no matter in rhel6.9 or rhel7.

on rhel6.9 with libvirt-0.10.2-62.el6.x86_64 (eth0 is my physical interface)
# virsh iface-dumpxml eth0 > /tmp/eth0

# cat /tmp/eth0
<interface type='ethernet' name='eth0'>
  <mac address='44:37:e6:6a:7f:29'/>
  <protocol family='ipv4'>
    <ip address='10.66.4.x' prefix='22'/>
  </protocol>
  <protocol family='ipv6'>
    <ip address='fe80::4637:e6ff:fe6a:7f29' prefix='64'/>
  </protocol>
</interface>

# virt-xml-validate /tmp/eth0
/tmp/eth0:1: element interface: Relax-NG validity error : Expecting element start, got mac
/tmp/eth0:1: element interface: Relax-NG validity error : Element interface failed to validate content
/tmp/eth0:1: element interface: Relax-NG validity error : Element interface failed to validate attributes
/tmp/eth0 fails to validate

on rhel7 with libvirt-2.5.0-1.el7.x86_64
# virsh iface-dumpxml enp0s25 > /tmp/enp0s25

# cat /tmp/enp0s25
<interface type='ethernet' name='enp0s25'>
  <protocol family='ipv4'>
    <ip address='10.66.5.x' prefix='22'/>
  </protocol>
  <protocol family='ipv6'>
    <ip address='fe80::1e6f:65ff:fe06:bc81' prefix='64'/>
  </protocol>
  <link speed='1000' state='up'/>
  <mac address='1c:6f:65:06:bc:81'/>
</interface>

# virt-xml-validate /tmp/enp0s25
/tmp/enp0s25:1: element interface: Relax-NG validity error : Expecting an element start, got nothing
/tmp/enp0s25:1: element interface: Relax-NG validity error : Invalid sequence in interleave
/tmp/enp0s25:1: element interface: Relax-NG validity error : Element interface failed to validate content
/tmp/enp0s25 fails to validate

Q1: If the failure in step 1 is caused by the command "virt-xml-validate" issue in step 3? If it is yes, then why the failure disappear after downgrade python-virtinst?

Q2: As the /usr/share/libvirt/schemas/interface.rng is not referred by other RNG, when will the interface validation happen? 
I have tried some scenarios, 
only define an interface by "virsh iface-define" and create an interface on virt-manager will do the validation; 
start an interface by "virsh iface-start" or edit it by "virsh iface-edit" will not do the validation(no error pop up). If these are expected?

(In reply to yalzhang from comment #5)
> Q1: If the failure in step 1 is caused by the command "virt-xml-validate"
> issue in step 3? If it is yes, then why the failure disappear after
> downgrade python-virtinst?

This is not caused by that command.  Python-virtinst simply creates an XML for the new interface and passes this XML to libvirt function from libvirt API.

That error is from netcf that is called by libvirt to create that interface.

Recent change that was trying to fix bridge on top of bond interface broke this, because netcf in RHEL-7 doesn't complain about XML validation.

> Q2: As the /usr/share/libvirt/schemas/interface.rng is not referred by other
> RNG, when will the interface validation happen? 
> I have tried some scenarios, 
> only define an interface by "virsh iface-define" and create an interface on
> virt-manager will do the validation; 
> start an interface by "virsh iface-start" or edit it by "virsh iface-edit"
> will not do the validation(no error pop up). If these are expected?

"virsh iface-edit" should error out if the XML is invalid, "virsh iface-start" doesn't need to validate the XML because you are not changing the XML

I can reproduce this issue with package:
python-virtinst.noarch 0:0.600.0-30.el6    

Then try to verify this bug with new build:
python-virtinst-0.600.0-31.el6.noarch

Steps as comment 0, I can add new bridge network interface with vlan interface as slave on rhel6.9 successfully, so move this bug to VERIFIED.

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-2017-0685.html