[Lxc-users] Network questions

[Daniel Lezcano]

Tim wrote:
> Hello
> 
> I am trying out LXC as a replacement for Linux-VServer on a Ubuntu Lucid 
> Beta System with Kernel 2.6.32-19 and have different questions 
> concerning the network.
> 
> [note: I assume I will stay on kernel 2.6.32 as this will be the kernel 
> of the lucid final release. as this will be a long term support release 
> I would like to be able to optain security updates thru standart 
> channels (apt-get) without having to rebuild the kernel after every 
> security notice.]
> 
> 
> 1) network types:
> 
> what is a macvlan?
> what can I do with a macvlan and what can I not do with it? (for the 
> kernel version 2.6.32)

The macvlan is like an aliased IP but at the eth level. When you create 
a macvlan you specify a physical network device (eg. eth0), and you have 
a new network device with its own mac address.

The advantage of the macvlan is you don't lose the offloading of your 
nic unlike the veth, so you have the best performances.

The disadvantage is you can not have the container to communicate with 
the host itself neither the other containers running on the same host. 
This is good for security but maybe inflexible for other use cases.
This restriction is no longer valid with the 2.6.33 kernel with the 
optional macvlan bridge mode.

> what is vlan?
> also: what can I do with a vlan?

The vlan is very similar to the macvlan except the ethernet protocol 
takes a specific id allowing to create several virtual network.
The wikipedia article maybe more clean than me  :)
http://en.wikipedia.org/wiki/Virtual_LAN

The advantages are the performances + network segmentation and the 
routers takes care of this id, the disadvantage is you can not specify 
the same vlan id for different containers on the same host (this is not 
supported by the kernel).

> did I understand this right: network type 'phys' is not functional in my 
> kernel version? eg, I cannot use the physical eth0 device in my vserver.

That's correct. The support of the physical devices depends on the sysfs 
per namespace which is not yet merged upstream. The option is valid for 
lxc but the kernel will prevent that, the work is on the way, hopefully, 
that will be available for the 2.6.35 - crossing fingers :)

> 2) I have a server with one external device eth0. I have different IPs 
> attached to this device. one of them is the main host IP.
> my goal is to have one of this IPs in a Container, so that I can eg. run 
> a Web/FTP/Mailserver with its own IP Address within that VServer. I do 
> not need to communicate with the host from the container thru this IP, 
> as I setup an internal Network for internal communication.
> However, from my provider I cannot use bridges as it seems that he is 
> checking the mac address of the originating device (eth0 oder br0, ..). 
> so I cannot put eth0 in a bridge and link to that one from within the 
> container.
> Is this possible with my current kernel?
> also I might need to have access to the same IP/Device from different 
> vservers, is this also possible?

Maybe the following thread can help you:

https://sourceforge.net/mailarchive/message.php?msg_name=4BBA3ECD.8030305%40free.fr

> 3) I read about two types how to install and use containers: either with 
> the lxc tools or with libvirt.
> 
> are these basicly two interfaces to the same functionality?

These are different implementations.
IMHO, the lxc tools does more than the libvirt in the container area.

> is the networking support different in libvirt?

The libvirt uses the ip utils command with a "system(command)" 
invocation, while the lxc tools has the network management embedded in. 
I think only veth is supported at present in libvirt.

> eg does it allow a physical interface to be passed thru to the container?

No. This is not supported by the kernel yet.

> what is the advantage of libvirt over lxc tools?

libvirt is a glue between an unified api for virtual machine and a 
specific implementation. So if you handle a heterogeneous configurations 
with Xen, Kvm, etc .. and you want the containers, the libvirt maybe a 
good solution. But unfortunately, the containers are not virtual 
machine, so depending on what you want to do with the containers, you 
may fall in a dead-end with libvirt due to smallest common denominator 
it provides with the unified virtualization API.