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 <stgra...@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 <stgra...@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@lists.linuxcontainers.org >>> http://lists.linuxcontainers.org/listinfo/lxc-users >> >> _______________________________________________ >> lxc-users mailing list >> lxc-users@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@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-users
_______________________________________________ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users