[lxc-users] lxc 2.0 adding a nic to a container on another vlan (was: access to snapshots from within the containers)

[Michel Jansens]

Thanks a lot Stéphane for this information,

I succeeded in attaching a bridge device from a specific vlan following your advise from https://github.com/lxc/lxd/issues/2551 <https://github.com/lxc/lxd/issues/2551>
command I used is: lxc config device add welcome-lemur eth1 nic nictype=macvlan parent=brvlan3904 name=eth1

In /etc/network/interfaces I added:

#vlan 3904 interface on enp1s0f0
auto vlan3904
iface vlan3904 inet manual
        vlan_raw_device enp1s0f0
#add a bridge for vlan3904
auto brvlan3904
iface  brvlan3904 inet  manual
       bridge_ports vlan3904


I managed to add the brvlan3904 to multiple containers, but this doesn’t create an interface for each container in the brvlan3904 bridge, and I don’t know what the security consequences are… 
Is This OK like this?


Alternatively, to mimic how lxc br0 bridge looks (one interface for each container with vethXXXXXX like names), I tried to add more ports to the bridge,with dummy interfaces: 

ip link add welcomelemur type dummy
brctl addif brvlan3904 welcomelemur
ifconfig welcomelemur up
lxc config device add welcome-lemur eth1 nic nictype=macvlan parent=brvlan3904 name=eth1

But this gave me: error: Failed to create the new macvlan interface: exit status 2
I tried using nictype=veth instead of mtacvlan but got 'error: Bad nic type: veth’ 

How should I do this properly?



I must say what I’d really like is a way to do networking like I used to in Solaris 10 with “shared IP interfaces”: 
   -the network interface is created in the host (one for each container) like eth0:1,eth0:2,...
   -the containers sees the interface in ifconfig but cannot change network IP, mask or anything.
Some apps don’t work (e.g.: tcpdump needs promiscuous mode), but someone cannot just change IP from within the container (maybe this can be prevented in LXC, but I’m not  experienced enough yet to know how). 




Thanks for any additional information


—

Michel

> On 15 Jun 2017, at 19:13, Stéphane Graber <stgraber at ubuntu.com> wrote:
> 
> On Thu, Jun 15, 2017 at 07:58:33AM +0200, mjansens wrote:
>> Hi,
>> 
>> Thank you Stéphane for this clarification.
>> I'll indeed try to stick with the LTS version if I can. The snapshot glitch has an easy work around:  just need to do a ‘ls’ of the new snapshot contents in the host (can even happen in a cron). And anyway, nobody said this issue was fixed in later updates...
> 
> Yeah, I don't expect this to be any different on the LXD feature branch.
> This behavior is an internal ZFS behavior and short of having LXD clone
> every snapshot and mount the resulting clone, I can't think of another
> way to easily expose that data.
> 
>> 
>> Where I might get stuck is in the network part: I will need at some point to lock some containers in specific VLANs. I more or less have gathered from various info on the web that LXD2.0.x networking is limited to a simple bridge (my actual config) or the standard NAT.
> 
> LXD 2.0.x doesn't have an API to let you define additional bridges.
> 
> There's however nothing preventing you from defining additional bridges
> at the system level and then telling LXD to use them.
> 




>> 
>> 
>> Thanks,
>> 
>> Michel
>> 
>> 
>>> On 14 Jun 2017, at 19:10, Stéphane Graber <stgraber at ubuntu.com> wrote:
>>> 
>>> On Wed, Jun 14, 2017 at 03:41:27PM +0800, gunnar.wagner wrote:
>>>> not directly related to your snapshot issue but still maybe good to know
>>>> fact
>>>> 
>>>> On 6/13/2017 8:37 PM, Michel Jansens wrote:
>>>>> I’m busy discovering LXD v2.0.9 on Ubuntu 16.04
>>>> if you want the most recent (yet regarded stable for production) version of
>>>> LXD on an ubuntu 16.04 host you'd install it from the xenial-backports
>>>> sources
>>>> 
>>>>   sudo apt install -t xenial-backports lxd lxd-client
>>>> 
>>>> this gives you 2.13 at this point in time. I am not really sure what the
>>>> lxd-client package exactly does (or which feature your are missing if you
>>>> don;t have that) but it was recommended somewhere to get that as well
>>> 
>>> Please don't tell people to do that unless they understand the implications!
>>> 
>>> Doing the above will get your system from the LXD LTS branch (2.0.x) to
>>> the LXD feature branch. Downgrading isn't possible, so once someone does
>>> that, there's no going back.
>>> 
>>> The LXD LTS branch (2.0.x) is supported for 5 years and only gets
>>> bugfixes and security updates. This is typically recommended for
>>> production environments where new features are considered a risk rather
>>> than benefit.
>>> 
>>> The LXD feature branch (currently at 2.14) is updated monthly, is only
>>> supported until the next release is out and will receive new features
>>> which may require user intervention to setup after upgrade.
>>> 
>>> 
>>> -- 
>>> Stéphane Graber
>>> Ubuntu developer
>>> http://www.ubuntu.com
>>> _______________________________________________
>>> lxc-users mailing list
>>> lxc-users at lists.linuxcontainers.org
>>> http://lists.linuxcontainers.org/listinfo/lxc-users
>> 
>> _______________________________________________
>> lxc-users mailing list
>> lxc-users at lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
> 
> -- 
> Stéphane Graber
> Ubuntu developer
> http://www.ubuntu.com
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20170616/462e7a2c/attachment.html>