[lxc-users] lxc / lxd I'm lost somewhere

[Benoit GEORGELIN - Association Web4all]

Hi Serge 

Thanks for the explantation, really appreciated. 
Multi-tenant support is what I'm looking for here but the way I designed it without thinking in an LXD point of view but more into an LXC point of view . 
I think many people talking about LXD in fact never did use the daemon if they did not "launch" any containers that way. 
I came through when I start asked myself questions about the API and live migration . Witch should become really easy in the future using LXD . 

Looks like I have a lot of work ahead . 

Cordialement, 

Benoît 


De: "Serge Hallyn" <serge.hallyn at ubuntu.com> 
À: "lxc-users" <lxc-users at lists.linuxcontainers.org> 
Envoyé: Mardi 1 Mars 2016 13:55:20 
Objet: Re: [lxc-users] lxc / lxd I'm lost somewhere 

Quoting Benoit GEORGELIN - Association Web4all (benoit.georgelin at web4all.fr): 
> Hi Serge, 
> 
> Thanks for your input. 
> I still don't understand how I can manage the equivalent to create a container using LXD instant of lxc-create. 
> 
> My goal is just to create a container with a permanent existence . 
> To me, lxc launch is only for volatile containers, a bit more like a docker container 

Why is that? 

lxc launch is just lxc init && lxc start. The container sticks around 
until you lxc delete it. 

> I'll try to understand more how I should work with LXD instant of only LXC . I understand all the capabilities of LXD but I misunderstand how I can just do what i am doing right now : 
> 
> - Create a dedicated système user (unpriv container) 

lxc init imagelias containername 

> - Apply a specific lxc.config file 

lxc config edit containername 

> - Create a new rootfs with LVM or BTRFS 

You do need to choose whether you're using lvm, btrfs, zfs, or 
just a regular rootfs as backing store, although you could 
run 4 different lxd instances each with different backing 
store, all on the same host, if you wanted. 

> - Create a new container like this 
> lxc-create -n test -t ubuntu -B lvm --lvname test --vgname vg_node1 --fstype ext4 --fssize 1GB 
> 
> So the specific user will have his own container . 
> 
> User A will have his own space for containers 
> User B will have his own space for containers 

The real support for segratated lxc users (multi-tenant support) is not 
yet there. And at the moment, giving user A the ability to use the lxd 
remote on host X (meaning, full ability to configure the containers and 
devices there) means that user A is effectively root on host X. 

> They should do "lxc-ls -f" or "lxc list" and see only their own containers 
> 
> Maybe this is not a typical use case ? 

I'm hoping we can focus on multi-tenant support as a design goal after 
the 2.0 release. But with lxd being remote based, the idea really is 
that A and B can both have accounts on host H1, with lxd remotes running 
on host H2 for user A and H3 for user B, and their lxc client configured 
to use the appropriate remotes. (where H2 and H3 can of course just be 
VMs on H1, or truly remote). So whereas lxc was host-based, i.e. I 
create and use containers on the host I'm logged in on, lxd is 
remote-based and it doesn't really matter where things are. 

For instance I have my local laptop and a (very) remote server. I 
can 'lxc launch xenial h:x1; lxc file push my.tar.gz h:x1/; lxc 
shell h:x1' and the fact that x1 is running on 'h' on a different 
continent really doesn't matter a lick. it's the same thing I'd 
do locally - 'lxc launch xenial x1; lxc file push my.tar.gz x1; 
lxc shell x1'. 

-serge 
_______________________________________________ 
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/20160302/2e63d098/attachment.html>