<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Thanks a lot Stéphane for this information,<div class=""><br class=""></div><div class="">I succeeded in attaching a bridge device from a specific vlan following your advise from <a href="https://github.com/lxc/lxd/issues/2551" class="">https://github.com/lxc/lxd/issues/2551</a></div><div class="">command I used is: <span style="font-family: Monaco; font-size: 10px; background-color: rgb(255, 255, 255);" class="">lxc config device add welcome-lemur eth1 nic nictype=macvlan parent=brvlan3904 name=eth1</span></div><div class=""><span style="font-family: Monaco; font-size: 10px; background-color: rgb(255, 255, 255);" class=""><br class=""></span></div><div class="">In /etc/network/interfaces I added:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 10px; line-height: normal; font-family: Monaco; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">#vlan 3904 interface on enp1s0f0</span></div><div style="margin: 0px; font-size: 10px; line-height: normal; font-family: Monaco; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">auto vlan3904</span></div><div style="margin: 0px; font-size: 10px; line-height: normal; font-family: Monaco; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">iface vlan3904 inet manual</span></div><div style="margin: 0px; font-size: 10px; line-height: normal; font-family: Monaco; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> vlan_raw_device enp1s0f0</span></div></div><div style="margin: 0px; line-height: normal; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class=""><div style="font-family: Monaco; font-size: 10px; margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">#add a bridge for vlan3904</span></div><div style="font-family: Monaco; font-size: 10px; margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">auto brvlan3904</span></div><div style="font-family: Monaco; font-size: 10px; margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">iface brvlan3904 inet manual</span></div><div style="font-family: Monaco; font-size: 10px; margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> bridge_ports vlan3904</span></div><div style="font-family: Monaco; font-size: 10px;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div style="font-family: Monaco; font-size: 10px;" class=""><span style="font-family: Helvetica; font-size: 12px;" class=""><br class=""></span></div><div class="">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… </div><div class="">Is This OK like this?</div><div style="font-family: Monaco; font-size: 10px;" class=""><span style="font-family: Helvetica; font-size: 12px;" class=""><br class=""></span></div><div style="font-family: Monaco; font-size: 10px;" class=""><span style="font-family: Helvetica; font-size: 12px;" class=""><br class=""></span></div></span></div><div class="">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: </div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 10px; line-height: normal; font-family: Monaco; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">ip link add welcomelemur type dummy</span></div></div><div style="margin: 0px; font-size: 10px; line-height: normal; font-family: Monaco; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">brctl addif brvlan3904 welcomelemur</span></div><div style="margin: 0px; font-size: 10px; line-height: normal; font-family: Monaco; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">ifconfig welcomelemur up</span></div><div style="margin: 0px; font-size: 10px; line-height: normal; font-family: Monaco; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">lxc config device add welcome-lemur eth1 nic nictype=macvlan parent=brvlan3904 name=eth1</span></div><div style="margin: 0px; font-size: 10px; line-height: normal; font-family: Monaco; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><span style="font-family: Helvetica; font-size: 12px;" class=""><br class=""></span></span></div><div style="margin: 0px; line-height: normal; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">But this gave me: </span><span style="font-family: Monaco; font-size: 10px;" class="">error: Failed to create the new macvlan interface: exit status 2</span></div><div class="">I tried using nictype=veth instead of mtacvlan but got '<span style="font-family: Monaco; font-size: 10px; background-color: rgb(255, 255, 255);" class="">error: Bad nic type: veth</span><font face="Monaco" size="2" class="">’</font> </div><div class=""><br class=""></div><div class="">How should I do this properly?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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”: </div><div class=""> -the network interface is created in the host (one for each container) like eth0:1,eth0:2,...</div><div class=""> -the containers sees the interface in ifconfig but cannot change network IP, mask or anything.</div><div class="">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). </div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Thanks for any additional information</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">—</div><div class=""><br class=""></div><div class="">Michel</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 15 Jun 2017, at 19:13, Stéphane Graber <<a href="mailto:stgraber@ubuntu.com" class="">stgraber@ubuntu.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Thu, Jun 15, 2017 at 07:58:33AM +0200, mjansens wrote:<br class=""><blockquote type="cite" class="">Hi,<br class=""><br class="">Thank you Stéphane for this clarification.<br class="">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...<br class=""></blockquote><br class="">Yeah, I don't expect this to be any different on the LXD feature branch.<br class="">This behavior is an internal ZFS behavior and short of having LXD clone<br class="">every snapshot and mount the resulting clone, I can't think of another<br class="">way to easily expose that data.<br class=""><br class=""><blockquote type="cite" class=""><br class="">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.<br class=""></blockquote><br class="">LXD 2.0.x doesn't have an API to let you define additional bridges.<br class=""><br class="">There's however nothing preventing you from defining additional bridges<br class="">at the system level and then telling LXD to use them.<br class=""><br class=""></div></div></blockquote><div><br class=""></div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><br class=""><br class="">Thanks,<br class=""><br class="">Michel<br class=""><br class=""><br class=""><blockquote type="cite" class="">On 14 Jun 2017, at 19:10, Stéphane Graber <<a href="mailto:stgraber@ubuntu.com" class="">stgraber@ubuntu.com</a>> wrote:<br class=""><br class="">On Wed, Jun 14, 2017 at 03:41:27PM +0800, gunnar.wagner wrote:<br class=""><blockquote type="cite" class="">not directly related to your snapshot issue but still maybe good to know<br class="">fact<br class=""><br class="">On 6/13/2017 8:37 PM, Michel Jansens wrote:<br class=""><blockquote type="cite" class="">I’m busy discovering LXD v2.0.9 on Ubuntu 16.04<br class=""></blockquote>if you want the most recent (yet regarded stable for production) version of<br class="">LXD on an ubuntu 16.04 host you'd install it from the xenial-backports<br class="">sources<br class=""><br class=""> sudo apt install -t xenial-backports lxd lxd-client<br class=""><br class="">this gives you 2.13 at this point in time. I am not really sure what the<br class="">lxd-client package exactly does (or which feature your are missing if you<br class="">don;t have that) but it was recommended somewhere to get that as well<br class=""></blockquote><br class="">Please don't tell people to do that unless they understand the implications!<br class=""><br class="">Doing the above will get your system from the LXD LTS branch (2.0.x) to<br class="">the LXD feature branch. Downgrading isn't possible, so once someone does<br class="">that, there's no going back.<br class=""><br class="">The LXD LTS branch (2.0.x) is supported for 5 years and only gets<br class="">bugfixes and security updates. This is typically recommended for<br class="">production environments where new features are considered a risk rather<br class="">than benefit.<br class=""><br class="">The LXD feature branch (currently at 2.14) is updated monthly, is only<br class="">supported until the next release is out and will receive new features<br class="">which may require user intervention to setup after upgrade.<br class=""><br class=""><br class="">-- <br class="">Stéphane Graber<br class="">Ubuntu developer<br class=""><a href="http://www.ubuntu.com" class="">http://www.ubuntu.com</a><br class="">_______________________________________________<br class="">lxc-users mailing list<br class="">lxc-users@lists.linuxcontainers.org<br class="">http://lists.linuxcontainers.org/listinfo/lxc-users<br class=""></blockquote><br class="">_______________________________________________<br class="">lxc-users mailing list<br class=""><a href="mailto:lxc-users@lists.linuxcontainers.org" class="">lxc-users@lists.linuxcontainers.org</a><br class="">http://lists.linuxcontainers.org/listinfo/lxc-users<br class=""></blockquote><br class="">-- <br class="">Stéphane Graber<br class="">Ubuntu developer<br class=""><a href="http://www.ubuntu.com" class="">http://www.ubuntu.com</a><br class="">_______________________________________________<br class="">lxc-users mailing list<br class="">lxc-users@lists.linuxcontainers.org<br class="">http://lists.linuxcontainers.org/listinfo/lxc-users</div></div></blockquote></div><br class=""></div></body></html>