0

I have an issue with kvm/libvirt virtualization and network namespaces on my Ubuntu 16.04 LTS. What I want to do is the following fenced setup:

  • One network namespace (the fence)
  • Two Linux bridges in the namespace.
  • Each bridge has it's own ip network.
  • Allow ip forwarding between these two bridges.
  • Two VMs. VM1 is connected to bridge1 and VM2 is conncted to bridge2.
  • Ping VM1 to VM2.

The intention is to get a little lab on my laptop which is fully independent from the host's remaining network setup that has communication to the outside world and it seems to me that network namespaces are the way to attain this but I hit some snags.

Until now I've set up the following: 

ip netns add internalSpielwiese
ip netns exec internalSpielwiese bash
    ip addr add 127.0.0.1/8 dev lo
    ip link set lo up
    ip link add name iBr0 type bridge
    ip addr add 172.0.0.1/24 dev iBr0
    ip link set iBr0 up
    ip link add name iBr1 type bridge
    ip addr add 172.0.1.1/24 dev iBr1
    ip link set iBr1 up

Pinging the ips inside the namespace is successful. IP forwarding is enabled. Outside the namespace the bridges are not visible/existent. Now it would be time to make the bridges in libvirt known. But it doesn't work. I tried it with this xml

<network>
  <name>internalBr0</name>
  <uuid>3f4647d9-0c19-509f-b512-9cac91c7149b</uuid>
  <forward mode='bridge'/>
  <bridge name='iBr0'/>
</network>

and appropriate virsh net-define and net-start commands. I edited a VM's xml file and started the VM but the result was this: 

virsh # start kirke2
error: Failed to start domain kirke2
error: Cannot get interface MTU on 'iBr0': No such device

Obviously, libvirt didn't find the iBr0 in the namespace internalSpielwiese and after some googling I've got the impression that libvirt is not able to deal with network namespaces. Or is there a way? How?

zweiund40
  • 65
  • 1
  • 2
  • 7
  • This is off topic here. But I don't see any reason to use network namespaces at all. Libvirt will happily keep its own networks separated from your other networks. – Michael Hampton Feb 14 '18 at 16:11
  • No, there is no separation between (l3-)bridges controlled by libvirt and those "controlled" by other linux tools. I mean, in the end "libvirt-bridges" only work if they are created beforehand with ip link, bridge, brctl or what ever tool you'd prefer. That's why I'm looking for a possibility to fully separate my little network setup for testing from the rest of the network setup. To be more clear: to fully separate from virbr0 and eth0. – zweiund40 Feb 16 '18 at 09:13
  • Libvirt will create its own internal bridges itself. You don't have to create them beforehand. And if you put this in a namespace, it will make it much more difficult to establish communication with the outside world. – Michael Hampton Feb 16 '18 at 16:28
  • Ok. You are stating libvirt manages its own bridges and one doesn't need to create bridges with standard linux tools. Maybe you are right. But then I missed something in the way I've done it so far. That's of course possible, since I not an professional. But I'm always eager to learn new things and would be thankful if you could provide your knowledge. ... (Sorry. I need to break it in two comments) – zweiund40 Feb 19 '18 at 11:00
  • The usual way I follow to create a new network is that one: 1. Define a new bridge with appropriate linux tools. 2. Define a new network with appropriate virsh commands: ... whereby steps 1 and 2 are interchangeable. 3. Edit a VM's xml file to make a connect to that new bridge. 4. Start the VM and use it ... When I skip step 1, I'm always getting fault messages. The VM is then simply not startable. – zweiund40 Feb 19 '18 at 11:00

1 Answers1

1

Libvirt can only see resources that are located in the same namespaces that libvirtd is running in. So the devices in your private namespace are invisible to libvirtd. There's no good way around this at this time, aside from making libvirtd run in this custom network namespace too. Then the host NICs are invisible to libvirtd - whether this is a problem or not depends on what you try todo.

DanielB
  • 2,461
  • 1
  • 10
  • 13
  • After some further reading I now think I was on the wrong path. On some point I read that l2-bridges are not intended to be put in a namespace. I mean, in the end a l3-bridge (l2-bridge + ip address) is still a bridge. Thank you for your comment. It helped me to figure that out. – zweiund40 Feb 16 '18 at 08:28
  • I think you could use `veth` devices plugged to the bridge with its single endpoint and its paired endpoint available outside of it. `man veth`: `… ip link set netns …`, check it out (although, it's 2022, probably you did already) ) – poige Apr 28 '22 at 06:39