Re: [lxc-users] Networking issue

[Janjaap Bos]

Downgrade the kernel to verify your guess, as the other feedback you got
also points to the kernel. If that solves it, go file a kernel bug.

2016-11-09 7:33 GMT+01:00 Saint Michael :

> It was working fine until a week ago.
> I have two sites, it happened on both, so the issue is not on my router or
> my switch, since they are different sites and we did not upgrade anything.
> Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-45-generic x86_64)
> LXC installed from apt-get install lxc1
> iptables off in both hosts and containers. I protect my network at the
> perimeter.
>
> All my container networking is defined
>
> lxc.network.type=macvlan
> lxc.network.macvlan.mode=bridge
> lxc.network.link=eth1
> lxc.network.name = eth0
> lxc.network.flags=up
> lxc.network.hwaddr = XX:XX:XX:XX:XX:XX
> lxc.network.ipv4 = 0.0.0.0/24
>
> Now suppose I have a machine, not a container, in the same broadcast
> domain as the containers, same subnet.
> It cannot ping or ssh into a container, which is accessible from outside
> my network.
> However, from inside the container the packets come and go perfectly, when
> the connection is originated by the container.
> A container can ping that host I mentioned, but the host cannot ping back
> the container.
> It all started a few days ago.
> Also, from the host, this test works
> arping -I eth0 (container IP address)
> it shows that we share the same broadcast domain.
>
> My guess is that the most recent kernel update in the LXC host, is
> blocking the communication to the containers, but it allows connections
> from the containers or connections from IP addresses not on the same
> broadcast domain.
> Any idea?
>
> ___
> 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

Re: [lxc-users] How to open a ticket with LXC

[Fajar A. Nugraha]

On Wed, Nov 9, 2016 at 12:37 PM, Saint Michael  wrote:

> I understand how you see it.
> Maybe it was my mistake to get on the LXC bandwagon two years ago. I
> should not bet my business on a non-commercial, unsupported software.
>

You do realise that if you purchase support package from canonicall for
ubuntu, it should also include commercial support for lxc/lxd on ubuntu?



> Now it is too late.
>
>

I read your ticket, and there's not much info to go on there. With the
limited amount of info, the obvious thing to check would be your
configuration.

If you still have the problem, I suggest you create a NEW thread on list,
with the appropriate subject, and include these info:
- what version of distro and lxc are you running
- how did you install lxc package (e.g. ubuntu's default repo, ppa self
compiled)
- how did you setup your network (e.g. creating a manual bridge with the
host physical interface eth0, or default lxcbr0 bridge, or proxyarp, etc)
- do you have firewall active on your host (e.g. output of "iptables -nL"
or similar)
- lxc config file for the problematic container (you can mask sensitive
info if you like)

-- 
Fajar
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] How to open a ticket with LXC

[Saint Michael]

I understand how you see it.
Maybe it was my mistake to get on the LXC bandwagon two years ago. I should
not bet my business on a non-commercial, unsupported software.
Now it is too late.



On Tue, Nov 8, 2016 at 1:26 PM, Serge E. Hallyn  wrote:

> Stéphane was helpfully pointing you in the direction of where the problem
> probably lies.  Don't read it as "your problem isn't important so I'm
> closing it", read it as "your problem sounds like it could be x or y."
>
> github.com/lxc/lxc tracks upstream lxc.  This is independent of Ubuntu.
> If you want to file an ubuntu bug, go to
> https://launchpad.net/ubuntu/+source/lxc or
> https://launchpad.net/ubuntu/+source/linux for the kernel, and hit
> 'Report a bug' on the right.  (Or if you pay for support go through your
> support channel)
>
> github.com/lxc/lxc is also an independent volunteer project, so the
> entitlement
> in this message is unwarranted.  If I show up to help move your couch in my
> free time, you can't complain that I didn't paint your walls.  The message
> closing your issue was a very polite, respectful, and helpful one.
>
> I understand that as a user you don't really want to have to care about
> who's providing what software, but everyone will be able to do their jobs
> much better if they can focus on what they focus on.
>
> -serge
>
> Quoting Saint Michael (vene...@gmail.com):
> > Stephane Grabber closed my report without investigating the evidence. He
> > says it is a firewall or a Kernel bug. If this a Kernel bug, he needs to
> > act, because I don't upgrade the Kernels, Ubuntu does it. And there is no
> > firewall in my LXC host.
> > I am complaining tomorrow to Canonical.
> >
> > On Mon, Nov 7, 2016 at 1:49 PM, Saint Michael  wrote:
> >
> > > I already open a ticket
> > > https://github.com/lxc/lxc/issues/1284
> > >
> > > On Mon, Nov 7, 2016 at 1:43 PM, Saint Michael 
> wrote:
> > >
> > >> The issue is very simple, and it started a few days ago, after an
> update.
> > >> You cannot communicate from the same network to a container, but from
> the
> > >> container you can initiate any connection just fine.
> > >> Also from outside my network I can ssh into a container and ping. From
> > >> the same network I cannot even ping a container.
> > >>
> > >>
> > >>
> > >> On Mon, Nov 7, 2016 at 1:29 PM, Judd Meinders <
> > >> judd.meind...@rockwellcollins.com> wrote:
> > >>
> > >>> On Mon, Nov 7, 2016 at 12:10 PM, Saint Michael 
> > >>> wrote:
> > >>> >
> > >>> > Does anybody know how to open a bug with LXC?
> > >>> > I cannot figure it out. Ubuntu does point me to another site, but I
> > >>> cannot see how to open a new ticket.
> > >>> >
> > >>> >
> > >>> >
> > >>> > ___
> > >>> > lxc-users mailing list
> > >>> > lxc-users@lists.linuxcontainers.org
> > >>> > http://lists.linuxcontainers.org/listinfo/lxc-users
> > >>>
> > >>> https://github.com/lxc/lxc/issues
> > >>>
> > >>> If you can, include steps to reproduce the issue, software versions,
> > >>> configs, workarounds, etc.  A well formed and organized issue will
> get
> > >>> more attention.
> > >>>
> > >>> --
> > >>> Judd Meinders
> > >>> ___
> > >>> 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
>
> ___
> 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

Re: [lxc-users] Current state of LXC as it relates to VoIP / realtime transcoding

[Serge E. Hallyn]

Quoting Kevin Long (kevin.l...@haloprivacy.com):
> 
> Greetings, first post to the list.
> 
> I’ve been doing some initial research,  started with docker and also LXC by 
> way of Proxmox (which I use for virtualization).
> 
> Basically, I’m looking at rolling out Freeswitch for a whole bunch of my 
> customers in an automated fashion, and using containers, whether via docker,  
> LXD or proxmox is an attractive platform for this.
> 
> But everywhere I’ve raised the idea, IRC/forums etc,  people are saying that 
> Linux containers are still not really suitable for this, unless security is 
> significantly compromised by allowing container processes to access features 
> of the kernel that they normally would not be able to, in order to have a 
> clocking mechanism that is reliable enough for real-time transcoding etc,  
> and this also means the solution is not portable, as it presupposes that 
> these escalated privileges will be available in all deployment environments.
> 
> 
> Anyone have more specifics on this,  is LXD any better/worse for this 
> application than other containerization platforms, etc?

Can you give us some more details on what hardware you need the containers
to be able to use?

In general it'll depend on the kernel and the hardware drivers (in the
kernel), and whether you want to just delegate them to one container at
a time or actually virtualize them (i.e. handing a network card to multiple
containers).
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] How to open a ticket with LXC

[Serge E. Hallyn]

Stéphane was helpfully pointing you in the direction of where the problem
probably lies.  Don't read it as "your problem isn't important so I'm
closing it", read it as "your problem sounds like it could be x or y."

github.com/lxc/lxc tracks upstream lxc.  This is independent of Ubuntu.
If you want to file an ubuntu bug, go to
https://launchpad.net/ubuntu/+source/lxc or
https://launchpad.net/ubuntu/+source/linux for the kernel, and hit
'Report a bug' on the right.  (Or if you pay for support go through your
support channel)

github.com/lxc/lxc is also an independent volunteer project, so the entitlement
in this message is unwarranted.  If I show up to help move your couch in my
free time, you can't complain that I didn't paint your walls.  The message
closing your issue was a very polite, respectful, and helpful one.

I understand that as a user you don't really want to have to care about
who's providing what software, but everyone will be able to do their jobs
much better if they can focus on what they focus on.

-serge

Quoting Saint Michael (vene...@gmail.com):
> Stephane Grabber closed my report without investigating the evidence. He
> says it is a firewall or a Kernel bug. If this a Kernel bug, he needs to
> act, because I don't upgrade the Kernels, Ubuntu does it. And there is no
> firewall in my LXC host.
> I am complaining tomorrow to Canonical.
> 
> On Mon, Nov 7, 2016 at 1:49 PM, Saint Michael  wrote:
> 
> > I already open a ticket
> > https://github.com/lxc/lxc/issues/1284
> >
> > On Mon, Nov 7, 2016 at 1:43 PM, Saint Michael  wrote:
> >
> >> The issue is very simple, and it started a few days ago, after an update.
> >> You cannot communicate from the same network to a container, but from the
> >> container you can initiate any connection just fine.
> >> Also from outside my network I can ssh into a container and ping. From
> >> the same network I cannot even ping a container.
> >>
> >>
> >>
> >> On Mon, Nov 7, 2016 at 1:29 PM, Judd Meinders <
> >> judd.meind...@rockwellcollins.com> wrote:
> >>
> >>> On Mon, Nov 7, 2016 at 12:10 PM, Saint Michael 
> >>> wrote:
> >>> >
> >>> > Does anybody know how to open a bug with LXC?
> >>> > I cannot figure it out. Ubuntu does point me to another site, but I
> >>> cannot see how to open a new ticket.
> >>> >
> >>> >
> >>> >
> >>> > ___
> >>> > lxc-users mailing list
> >>> > lxc-users@lists.linuxcontainers.org
> >>> > http://lists.linuxcontainers.org/listinfo/lxc-users
> >>>
> >>> https://github.com/lxc/lxc/issues
> >>>
> >>> If you can, include steps to reproduce the issue, software versions,
> >>> configs, workarounds, etc.  A well formed and organized issue will get
> >>> more attention.
> >>>
> >>> --
> >>> Judd Meinders
> >>> ___
> >>> 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

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Wierd issue with high userID's

[Stéphane Graber]

So I had a branch to add ipvlan a while back, it's not exactly hard but
it was a bit weird given that LXD doesn't do L3 configuration of network
devices and an IPVLAN device that's not configured before it's passed to
the container didn't seem very useful.

We were also a bit concerned about potential confusion with macvlan as
they both behave very similarly, except for the fact that you don't get
to configure L2 on an IPVLAN. That point also raised another problem,
which is that LXD usually expects to be able to set and track the mac
address, which isn't really a thing with ipvlan.

On Tue, Nov 08, 2016 at 10:35:54AM -0500, Tardif, Christian wrote:
> Again, you solved my problems  :-)
> 
> That did the job. I have been struggling with this problem over the weekend,
> without any path to this. I understand that this is a Linux-related "issue",
> and not at all directly related to LXD. I'll remember that!
> 
> On another idea...  do you have any plan to support IPVLAN directly in LXD?
> For our use case (we're deploying LXC containers inside Openstack
> instances), the only viable way without too much hassle on the entworking
> side is to use IPVLAN but, right now, this requests to have pre-populated
> IPVLAN network devices outside of the LXD environment.
> 
> ---
> Christian Tardif
> 
> -
> 
> On 2016-11-08 00:11, Stéphane Graber wrote:
> > On Tue, Nov 08, 2016 at 03:00:48AM +, Christian Tardif wrote:
> > > Hi,
> > > 
> > > I just faced a strange issue with LXD containers. I'm using them quite
> > > extensively, but never faced that before. Normally, the userID that
> > > are
> > > presented to the container (they're coming from SSSD with
> > > ActiveDirectory
> > > backend) are relatively low...   2000, 3000, that kind of ID's
> > > 
> > > Last friday, at the office, I built two containers (Ubuntu 16.04,
> > > CentOS
> > > 7.1) with the same kind of configuration regarding authentication;
> > > SSSD. And
> > > I notice that I wasn't able to log in via SSH. But one of my
> > > colleague was
> > > able to. We re-checke the config, just to make sure (but at the same
> > > time,
> > > it was impossible for this config to fail, as it is presented to the
> > > servers
> > > via Puppet. So the same config, and on the same OS level as other
> > > installs
> > > (we have numerous Ubuntu 16.04 with the same config, but the first
> > > one on
> > > LXD containers).
> > > 
> > > We were trying to find out what piece was missing when we discover
> > > that this
> > > is not just the logging that fails, but everything related to these
> > > high
> > > UserID's. They are coming from a calculation based on Windows SID's
> > > for the
> > > user, which gives a huge range of userID's, from a few thousands to
> > > tens, if
> > > not hundreds thousands.   So with my user, I can't set a permission
> > > with it,
> > > and I can't login.In fact, I don't exist with this user other than
> > > using
> > > "getent passwd", or "id".
> > > 
> > > What can be the cause? Something to do with namespaces, maybe?
> > > cgroups?
> > > 
> > > We'ew in the dark. And until we can solve this, LXD containers
> > > aren't that
> > > helpful to us, unfortunately.
> > > 
> > > Christian Tardif
> > 
> > Hey there,
> > 
> > By default LXD uses a range of 65536 uid and gid as the user namespace
> > map for the containers.
> > 
> > This means that only uid 0 through 65536 exist in your container,
> > anything outside of that will be treated as invalid by the kernel.
> > 
> > 
> > sssd and similar authentication mechanisms will typically use uids/gids
> > above that POSIX range and so require you to grow the default map size
> > in /etc/subuid and /etc/subgid.
> > 
> > 
> > On the systems I use with sssd I typically just bump the allocation for
> > lxd and root in /etc/subuid and /etc/subgid from 65536 to 100 which
> > takes care of that problem.
> > 
> > 
> > ___
> > 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


signature.asc
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Wierd issue with high userID's

[Tardif, Christian]

Again, you solved my problems  :-)

That did the job. I have been struggling with this problem over the 
weekend, without any path to this. I understand that this is a 
Linux-related "issue", and not at all directly related to LXD. I'll 
remember that!


On another idea...  do you have any plan to support IPVLAN directly in 
LXD? For our use case (we're deploying LXC containers inside Openstack 
instances), the only viable way without too much hassle on the 
entworking side is to use IPVLAN but, right now, this requests to have 
pre-populated IPVLAN network devices outside of the LXD environment.


---
Christian Tardif

-

On 2016-11-08 00:11, Stéphane Graber wrote:

On Tue, Nov 08, 2016 at 03:00:48AM +, Christian Tardif wrote:

Hi,

I just faced a strange issue with LXD containers. I'm using them quite
extensively, but never faced that before. Normally, the userID that 
are
presented to the container (they're coming from SSSD with 
ActiveDirectory

backend) are relatively low...   2000, 3000, that kind of ID's

Last friday, at the office, I built two containers (Ubuntu 16.04, 
CentOS
7.1) with the same kind of configuration regarding authentication; 
SSSD. And
I notice that I wasn't able to log in via SSH. But one of my colleague 
was
able to. We re-checke the config, just to make sure (but at the same 
time,
it was impossible for this config to fail, as it is presented to the 
servers
via Puppet. So the same config, and on the same OS level as other 
installs
(we have numerous Ubuntu 16.04 with the same config, but the first one 
on

LXD containers).

We were trying to find out what piece was missing when we discover 
that this
is not just the logging that fails, but everything related to these 
high
UserID's. They are coming from a calculation based on Windows SID's 
for the
user, which gives a huge range of userID's, from a few thousands to 
tens, if
not hundreds thousands.   So with my user, I can't set a permission 
with it,
and I can't login.In fact, I don't exist with this user other than 
using

"getent passwd", or "id".

What can be the cause? Something to do with namespaces, maybe?  
cgroups?


We'ew in the dark. And until we can solve this, LXD containers aren't 
that

helpful to us, unfortunately.

Christian Tardif


Hey there,

By default LXD uses a range of 65536 uid and gid as the user namespace
map for the containers.

This means that only uid 0 through 65536 exist in your container,
anything outside of that will be treated as invalid by the kernel.


sssd and similar authentication mechanisms will typically use uids/gids
above that POSIX range and so require you to grow the default map size
in /etc/subuid and /etc/subgid.


On the systems I use with sssd I typically just bump the allocation for
lxd and root in /etc/subuid and /etc/subgid from 65536 to 100 which
takes care of that problem.


___
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

Re: [lxc-users] Mount additional storage into unprivileged container

[Andriy Tovstik]

вт, 8 нояб. 2016 г. в 13:57, Andrey Repin :

> Greetings, Andriy Tovstik!
>
> >>> I am learning LXC features because we are going  to implement it in our
> >>> production environment.
> >>
> >>  LXC or LXD? Your configuration smells the latter.
>
> > LXD, you are right. But AFAIK LXD is an extension that was built over LXC
> > subsystem, isn't it?
>
> LXD is an environment by and in itself. It uses different configuration
> tools
> to setup and manage containers.


Ok, lets forget about lxc, lets talking about lxd.


>
> My (overly simplified) explanation of use case is that LXC is what I'd use
> if
> I need to setup a system once and forget (as a figure of speech) it exists,
> while LXD is a tool for mass-deployment of applications/appliances. With
> leaning to the latter, since LXD deploys entire stack in a single
> container.
>

I have big plans :) so LXD looks more suitable for me


> >>> Could somebody explain me is there any well documented way to mount
> >>> additional filesystems or (preferable) block devices into Unprivileged
> >>> containers? is it supports live migration of container?
> >>
> >>  You could do better at explaining, what you need that for. It'll speed
> up the
> >>  answer.
> >>  Normally, you don't need to "mount block devices into container".
>
> > Well... I'm going to use LXD to isolate two applications that will be
> > heavily loaded. May be it will be necessary to give for each other
> dedicated storage.
>
> You can do that by just mounting that dedicated storage in the profile. You
> don't really need block devices inside a container, unless your use case
> demands specifically block-level access.
>

Ok, let me clarify my question. As i've read in
https://github.com/lxc/lxd/blob/master/doc/configuration.md  there are two
storage option can be mounted into container:

disk and unix-block device. I played with the both ones. Lets talk about
disk device. As you can see in my example i've used disk device with a
block device as a source. I can change source option and set directory as a
source. Anyway i recieve "permission denied" error when i try to access to
this directory inside my container... Remember we talk about unprivileged
container. Privileged container works fine. I have found a lot of topics
about this problem, but i'm seeking for official, best practice soluiton.

--
> With best regards,
> Andrey Repin
> Tuesday, November 8, 2016 14:25:33
>
> Sorry for my terrible english...
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users

-- 
WBR, Andriy Tovstik
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Mount additional storage into unprivileged container

[Andrey Repin]

Greetings, Andriy Tovstik!

>>> I am learning LXC features because we are going  to implement it in our
>>> production environment.
>>  
>>  LXC or LXD? Your configuration smells the latter.

> LXD, you are right. But AFAIK LXD is an extension that was built over LXC
> subsystem, isn't it?

LXD is an environment by and in itself. It uses different configuration tools
to setup and manage containers.

My (overly simplified) explanation of use case is that LXC is what I'd use if
I need to setup a system once and forget (as a figure of speech) it exists,
while LXD is a tool for mass-deployment of applications/appliances. With
leaning to the latter, since LXD deploys entire stack in a single container.

>>> Could somebody explain me is there any well documented way to mount
>>> additional filesystems or (preferable) block devices into Unprivileged
>>> containers? is it supports live migration of container?
>>  
>>  You could do better at explaining, what you need that for. It'll speed up 
>> the
>>  answer.
>>  Normally, you don't need to "mount block devices into container".

> Well... I'm going to use LXD to isolate two applications that will be
> heavily loaded. May be it will be necessary to give for each other dedicated 
> storage.

You can do that by just mounting that dedicated storage in the profile. You
don't really need block devices inside a container, unless your use case
demands specifically block-level access. F.e. if you want to prepare bootable
media from inside a container (there was a thread about it a while ago,
apparently, OP's host OS was unable to produce desirable results, and they
wanted to use a container with a newer OS (thus newer toolchain) to prepare
the media).

> Rootfs i'll put to ZFS pool. Alternative way is to use zfs over high speed
> storage system and use IOPS limit for each container...

>>> I've read a lot of articles and man pages but unfortunatly this question is 
>>> still unclear for me...
>>>
>>> Currently my config looks like:
>>>
>>>  
>>>
>>> name: test-container
>>> profiles:
>>> - default
>>> config:
>>>   raw.lxc: lxc.aa_profile=unconfined
>>>   security.privileged: "true"
>>>   volatile.base_image: 
>>> a19c9ae2bd2e7bf99b0e2d31a0707cc534781a4eba47f44f172f486d2e01c96b
>>>   volatile.eth0.hwaddr: 00:16:3e:87:d6:d9
>>>   volatile.last_state.idmap: '[]'
>>> devices:
>>>   data:
>>>     path:  /datastorage
>>>     source: /dev/sdf
>>>     type: disk
>>>
>>>
>>> But when I try to change security.privileged to ‘false’ I lost an ability
>>> to write to /datastorage path inside container.
>>>
>>> Currently I’m using version 2.0.5 of LXC
>>  
>>  Doesn't match to your listed config. Smells like LXD.

> All versions looks like something like this:

You have LXD installed. "lxc2" is an alternative name for it. LXC is named
"lxc1" in the repository.

> ii  lxc-common     2.0.5-0ubuntu1~ubuntu16.04.2 amd64        Linux
> Containers userspace tools (common tools)

> ii  lxc2           2.0.5-0ubuntu1~ubuntu16.04.1 all          Container 
> hypervisor based on LXC - metapackage
> ii  lxcfs          2.0.4-0ubuntu1~ubuntu16.04.1 amd64        FUSE based 
> filesystem for LXC
> ii  lxd            2.0.5-0ubuntu1~ubuntu16.04.1 amd64        Container 
> hypervisor based on LXC - daemon
> ii  lxd-client     2.0.5-0ubuntu1~ubuntu16.04.1 amd64        Container 
> hypervisor based on LXC - client
> ii  lxd-tools      2.0.5-0ubuntu1~ubuntu16.04.1 amd64        Container 
> hypervisor based on LXC - extra tools


aptitude show lxc2
Package: lxc2
State: not installed
Version: 2.0.5-0ubuntu1~ubuntu14.04.1
Priority: extra
Section: universe/metapackages
Maintainer: Ubuntu Developers 
Architecture: all
Uncompressed Size: 57,3 k
Depends: lxd, lxd-client
Description: Container hypervisor based on LXC - metapackage
 LXD offers a REST API to remotely manage containers over the network, using an 
image based
 workflow and with support for live migration.

This is a dummy metapackage to install LXD and its client.
Homepage: https://linuxcontainers.org/


-- 
With best regards,
Andrey Repin
Tuesday, November 8, 2016 14:25:33

Sorry for my terrible english...
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Mount additional storage into unprivileged container

[Andriy Tovstik]

Hi, Andrey!

вт, 8 нояб. 2016 г. в 12:20, Andrey Repin :

> Greetings, Andriy Tovstik!
>
> > I am learning LXC features because we are going  to implement it in our
> > production environment.
>
> LXC or LXD? Your configuration smells the latter.
>
> LXD, you are right. But AFAIK LXD is an extension that was built over LXC
subsystem, isn't it?

> Could somebody explain me is there any well documented way to mount
> > additional filesystems or (preferable) block devices into Unprivileged
> > containers? is it supports live migration of container?
>
> You could do better at explaining, what you need that for. It'll speed up
> the
> answer.
> Normally, you don't need to "mount block devices into container".
>
>
Well... I'm going to use LXD to isolate two applications that will be
heavily loaded. May be it will be necessary to give for each other
dedicated storage.
Rootfs i'll put to ZFS pool. Alternative way is to use zfs over high speed
storage system and use IOPS limit for each container...

> I've read a lot of articles and man pages but unfortunatly this question
> is still unclear for me...
> >
> > Currently my config looks like:
> >
> >
> >
> > name: test-container
> > profiles:
> > - default
> > config:
> >   raw.lxc: lxc.aa_profile=unconfined
> >   security.privileged: "true"
> >   volatile.base_image:
> a19c9ae2bd2e7bf99b0e2d31a0707cc534781a4eba47f44f172f486d2e01c96b
> >   volatile.eth0.hwaddr: 00:16:3e:87:d6:d9
> >   volatile.last_state.idmap: '[]'
> > devices:
> >   data:
> > path:  /datastorage
> > source: /dev/sdf
> > type: disk
>
> >
> > But when I try to change security.privileged to ‘false’ I lost an ability
> > to write to /datastorage path inside container.
> >
> > Currently I’m using version 2.0.5 of LXC
>
> Doesn't match to your listed config. Smells like LXD.
>
> All versions looks like something like this:

ii  lxc-common 2.0.5-0ubuntu1~ubuntu16.04.2 amd64Linux
Containers userspace tools (common tools)
ii  lxc2   2.0.5-0ubuntu1~ubuntu16.04.1 all  Container
hypervisor based on LXC - metapackage
ii  lxcfs  2.0.4-0ubuntu1~ubuntu16.04.1 amd64FUSE based
filesystem for LXC
ii  lxd2.0.5-0ubuntu1~ubuntu16.04.1 amd64Container
hypervisor based on LXC - daemon
ii  lxd-client 2.0.5-0ubuntu1~ubuntu16.04.1 amd64Container
hypervisor based on LXC - client
ii  lxd-tools  2.0.5-0ubuntu1~ubuntu16.04.1 amd64Container
hypervisor based on LXC - extra tools



>
> --
> With best regards,
> Andrey Repin
> Tuesday, November 8, 2016 13:13:21
>
> Sorry for my terrible english...
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users

-- 
WBR, Andriy Tovstik
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] Mount additional storage into unprivileged container

[Andriy Tovstik]

Hi, all!



I am learning LXC features because we are going  to implement it in our
production environment.

Could somebody explain me is there any well documented way to mount
additional filesystems or (preferable) block devices into Unprivileged
containers? is it supports live migration of container?

I've read a lot of articles and man pages but unfortunatly this question is
still unclear for me...



Currently my config looks like:



name: test-container

profiles:

- default

config:

  raw.lxc: lxc.aa_profile=unconfined

*  security.privileged: "true"*

  volatile.base_image:
a19c9ae2bd2e7bf99b0e2d31a0707cc534781a4eba47f44f172f486d2e01c96b

  volatile.eth0.hwaddr: 00:16:3e:87:d6:d9

  volatile.last_state.idmap: '[]'

devices:

  data:

path:  /datastorage

source: /dev/sdf

type: disk





But when I try to change security.privileged to ‘false’ I lost an ability
to write to /datastorage path inside container.



Currently I’m using version 2.0.5 of LXC


-- 
WBR, Andriy Tovstik
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users