libvirt NAT creating problem

Hi,

I would like to create a NAT Virtual Network with the Virtual Machine Manager tool but I get the following error and I don’t know how to solve it.

http://i61.tinypic.com/2hmnf2c.png

Error creating virtual network: internal error: Failed to apply firewall rules /usr/sbin/iptables --table filter --insert FORWARD --source 192.168.100.0/24 --in-interface virbr0 --out-interface net_wlp16s0_00_1f_3b_59_61_3d --jump ACCEPT: iptables v1.4.21: interface name `net_wlp16s0_00_1f_3b_59_61_3d' must be shorter than IFNAMSIZ (15)
Try `iptables -h' or 'iptables --help' for more information.


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/createnet.py", line 758, in _async_net_create
    net.install()
  File "/usr/share/virt-manager/virtinst/network.py", line 261, in install
    net.create()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2836, in create
    if ret == -1: raise libvirtError ('virNetworkCreate() failed', net=self)
libvirtError: internal error: Failed to apply firewall rules /usr/sbin/iptables --table filter --insert FORWARD --source 192.168.100.0/24 --in-interface virbr0 --out-interface net_wlp16s0_00_1f_3b_59_61_3d --jump ACCEPT: iptables v1.4.21: interface name `net_wlp16s0_00_1f_3b_59_61_3d' must be shorter than IFNAMSIZ (15)
Try `iptables -h' or 'iptables --help' for more information.

Any ideas?

Yup.
Your error says it all…

Error creating virtual network: internal error: Failed to apply firewall rules /usr/sbin/iptables --table filter --insert FORWARD --source 192.168.100.0/24 --in-interface virbr0 --out-interface net_wlp16s0_00_1f_3b_59_61_3d --jump ACCEPT: iptables v1.4.21: interface name `net_wlp16s0_00_1f_3b_59_61_3d' must be shorter than IFNAMSIZ (15)

I’ve never seen an interface name that long, you must have some really unusual NIC. Also for general reference, if you could post exactly what this NIC is, others can be forewarned about it.

  1. Pls create a bug at http://bugzilla.opensuse.org about this… I can believe there are probably good reasons to restrict the interface name to 15 characters, but none good enough to actually do so. I would guess that another byte should be allocated to the interface name (ie increasing the name to 23 characters limit), and that should be done upstream.

  2. So, what to do? There are probably a few ways to approach this, my initial question might be whether you have multiple physical NICs or only a single NIC in your system. The supposed main reason for the new naming convention is to avoid confusing interfaces on a system when multiple NICs might have the same name. If this “legacy” problem is something you can deal with, then prob the simplest problem is to force the old naming convention which would rename your interface to something like “eth0” The problem for the moment (for me) right now though is that I just took a look at the networking config files in 13.2 and found that a number of changes were made including how to return to the legacy naming convention.

So, if someone already knows how to change the interface naming convention back to the legacy “eth0/wlan0” names, maybe they can post that…

I found the “label=” setting in /etc/sysconfig/network/ifcfg.template but haven’t figured how to make that setting do what I want (assuming it might do what I expect).

TSU

I think the problem lies in the libvirt / Virtual Machine Manager and how it sees the network interface.

Because:

# ifconfig net_wlp16s0_00_1f_3b_59_61_3d
net_wlp16s0_00_: error fetching interface information: Device not found

and

# ifconfig wlp16s0
wlp16s0   Link encap:Ethernet  HWaddr 00:1F:3B:59:61:3D  
          inet addr:192.168.12.7  Bcast:192.168.12.255  Mask:255.255.255.0
          inet6 addr: fe80::21f:3bff:fe59:613d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1832248 errors:0 dropped:0 overruns:0 frame:0
          TX packets:533071 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1494972744 (1425.7 Mb)  TX bytes:151975779 (144.9 Mb)

If I wasn’t clear in my previous post, the real problem is that the name given your interface is too long (exceeds 15 characters).
Solve that and <everything> will likely work.

TSU

I understand, but I can’t find this long interface name anywhere else in my system, just only in the Virtual Machine Manager, and I don’t know from where it reads or gets.

Interface names are created based on a template (ie rules).
All the configured interfaces on your system can be found in

/etc/sysconfig/network/

But, as I described above I don’t know how the changes to wicked may have altered instructing your system to use legacy names which aren’t hardware-specific. I don’t see the instructions embedded in the 13.1 configuration files and even see a new network configuration file that’s more comprehensive (and likely wicked specific).

Recommend you should post this more simpler and basic question in the Networking forum because your problem isn’t actually a virtualization issue, it’s a hardware naming issue.

TSU

There’s a pattern in this “long” filename, though…
It’s some label, then an underscore, plus the actual name of the device on which NAT takes place, plus the interface’s MAC address attached by an underscore and with all colons substituted with underscores as well.
If that cannot be found within any config, that would point me to some kind of bug within libvirt - which would require filing a bug report on this issue.

A workaround would be to set up an empty network bridge (i. e. one that isn’t attached to any physical interface) and then NAT that one against the physical interfaces so that all traffic appears to come from the dom0 instead of any VM - however, that would be a problem for the Network forum as well.
My recommendation, though, would reside with the empty bridge set up in dom0 as it spares you a LOT of headaches.

The likely problem in setting up any bridge is that it has to be bound to a specified network interface so you can’t avoid the problems an especially long NIC interface name would cause.

TSU

Nope - I have exactly this setup on my box, and it works like a charm - plus the bridge isn’t bound to any physical device, but merely serves as a hook for libvirt to which to attach its vNICs. Since the bridge has an IP address any traffic emanating from the bridge can be routed anywhere (even NATed).

The “dangling” bridge approach is tantamount to a virtual hub, though - and that a bridge absolutely has to be attached to a physical NIC is just nonsense.

If your bridge device is anything other than “Host Only” it has to be bound to an interface associated with a physical NIC(or chained eventually to such).
Else, how would the packets know to be routed through any physical NIC?

Recommend you run “brctl show” to first list the bridge devices on your machine, then the same command specifying the bridge device to display all its details.

brctl show *bridgename *

TSU

I’ve got exactly the same problem with my existing VMs after updating from 12.3 to 13.2.
Setting up an empty brigde hasn’t help. Has somebody found a solution or workaround to get network running for KVM ?

To get an idea whether the interface name is unusually long, you have to do what I described earlier and post the results (of ip addr or ifconfig) from your machine(Host).

In any case, if an excessively long physical interface name is the issue, the following describes how to change back to the older naming scheme
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

  1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev’s rule file for the default policy: ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules (since v209: this file was called 80-net-name-slot.rules in release v197 through v208)

Although there was a different way to change the naming scheme embedded in the 13.1 configuration file comments, I’ve verified the above works fine for both 13.1 and 13.2.

TSU