Bug 694382

Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Looks like some oddity introduced by the new dummy tap device

The problem is that an interface device name can be a maximum of 15 characters long, and test_noip_br-nic is 16 characters - removing one character from the name makes it work. We should probably just use the first 11 characters or the bridge device name when creating the dummy tap interface.

According to comment 5, I removed one character from the name as below
# cat test_noip.xml
<network>
  <name>test_noip</name>
  <uuid>9d92939c-208a-9cec-5ff9-86b6645ca2a5</uuid>
  <bridge name='est_noip_br' stp='on' forwardDelay='0' />
</network>
Then could define&start the nic with libvirt-0.8.7-16.el6.x86_64, but 2 nic is generated in #ip -o link show
# virsh net-define test_noip.xml 
Network test_noip defined from test_noip.xml
# virsh net-start test_noip
Network test_noip started
# ip -o link show
....
11: est_noip_br: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN \    link/ether 52:54:00:33:49:45 brd ff:ff:ff:ff:ff:ff
12: est_noip_br-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500\    link/ether 52:54:00:33:49:45 brd ff:ff:ff:ff:ff:ff

Only 1 nic is show if test with libvirt-0.8.1-27.el6.x86_64
# ip -o link show
...
14: est_noip_br: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN \    link/ether 86:65:40:db:20:36 brd ff:ff:ff:ff:ff:ff

> The problem is that an interface device name can be a maximum of 15 characters
> long, and test_noip_br-nic is 16 characters - removing one character from the
> name makes it work. We should probably just use the first 11 characters or the
> bridge device name when creating the dummy tap interface.

Just using the first N characters may introduce uniqueness problems, because it is quite common for users to have a common prefix, and a unique letter/number on the end. Chopping off the end risks removing the entire of the unique part.

It is probably better to just reduce the size of our postfix from '-nic' to a single letter 't' or 'v' or something.

And also make sure the code has an explicit name length check so we can report a clear error message to users.

A fix was committed upstream (see commit notice below) and a rebased version has been posted to rhvirt-patches:

   http://post-office.corp.redhat.com/archives/rhvirt-patches/2011-April/msg00383.html

commit 020ad8d1a272a7974cdcd897706fa12744802533
Author: Laine Stump <laine>
Date:   Wed Apr 13 12:38:58 2011 -0400

    network: truncate bridges' dummy tap device names to IFNAMSIZ (15) chars
    
    This patch addresses:
    
       https://bugzilla.redhat.com/show_bug.cgi?id=694382
    
    In order to give each libvirt-created bridge a fixed MAC address,
    commit 5754dbd56d4738112a86776c09e810e32f7c3224, added code to create
    a dummy tap device with guaranteed lowest MAC address and attach it to
    the bridge. This tap device was given the name "${bridgename}-nic".
    However, an interface device name must be IFNAMSIZ (15) characters or
    less, so a valid ${bridgename} such as "verylongname123" (15
    characters) would lead to an invalid tap device name
    ("verylongname123-nic" - 19 characters), and that in turn led to a
    failure to bring up the network.
    
    The solution is to shorten the part of the original name used to
    generate the tap device name. However, simply truncating it is
    insufficient, because the last few characters of an interface name are
    often a number used to indicate one of a list of several similar
    devices (for example, "verylongname123", "verylongname124", etc) and
    simple truncation would lead to duplicate names (eg "verlongnam-nic"
    and "verylongnam-nic"). So instead we take the first 8 characters of
    $bridgename ("verylong" in the example), add on the final 3 bytes
    ("123"), then add "-nic" (so "verylong123-nic").  Not pretty, but it
    is much more likely to generate a unique name, and is reproducible
    (unlike, say, a random number).

The similar as said in comment 6, 2 nics are shown in #ip link with libvirt-0.9.1-1.el6.x86_64. I don't think it is correct because in because only 1 nic is show if test with libvirt-0.8.1-27.el6.x86_64 (please refer to comment 6)
1. # cat test_noip.xml 
<network>
  <name>test_noip</name>
  <uuid>9d92939c-208a-9cec-5ff9-86b6645ca2a5</uuid>
  <bridge name='verylongname123' stp='on' forwardDelay='0' />
</network>
2. # virsh net-define test_noip.xml 
Network test_noip defined from test_noip.xml
3. # virsh net-start test_noip
Network test_noip started
4. # ip link
....
71: verylongname123: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether 52:54:00:12:75:ad brd ff:ff:ff:ff:ff:ff
72: verylong123-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
...

The "xxx-nic" device is a tap device created solely for the purpose of setting a fixed MAC address and attaching it to the bridge, so that the bridge will have a fixed MAC address. libvirt-0.8.1 doesn't have the code that provides a fixed MAC address for the virtual network bridge, so it will not have the "xxx-nic" tap device.

(NB: that tap device is marked as DOWN, so it won't show up in the output of "ifconfig", but of course if you uses a low level enough / verbose enough command (like "ip link") it will show up.

At any rate, the output of "ip link" in 0.8.1 is as expected, and the output in 0.9.1-1 is also as expected.

Thanks for Laine. According to comment 12 and comment 13, verified the bug pass.

Move to VERIFIED according to Comment 14

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.

http://rhn.redhat.com/errata/RHBA-2011-1513.html