search

canonical / lxd

Powerful system container and virtual machine manager
https://canonical.com/lxd
GNU Affero General Public License v3.0
4.32k stars 926 forks source link

Mounting directories #592

Closed techtonik closed 9 years ago

techtonik commented 9 years ago

First of all I want to say that LXD rocks. After struggling with LXC, Vagrant and Docker I finally back to LXD and I like the experience (the next thing in queue is Rocket).

The only feature that I miss from https://linuxcontainers.org/lxd/getting-started-cli/ is the ability to mount directories. pull/push workflow is fine, but when developing something from IDE, getting forth and back to console is not really fun. I know that LXC supports mounting, so if LXD exposes that through its convenient user interface, that would be a killer feature.

tych0 commented 9 years ago

On Wed, May 06, 2015 at 12:18:06AM -0700, anatoly techtonik wrote:

First of all I want to say that LXD rocks. After struggling with LXC, Vagrant and Docker I finally back to LXD and I like the experience (the next thing in queue is Rocket).

Glad to hear it!

The only feature that I miss from https://linuxcontainers.org/lxd/getting-started-cli/ is the ability to mount directories. pull/push workflow is fine, but when developing something from IDE, getting forth and back to console is not really fun. I know that LXC supports mounting, so if LXD exposes that through its convenient user interface, that would be a killer feature.

Yes, we do support it in theory (via "raw.lxc" and a few tricks); there is a blog post in the works about how to do this, but it is currently broken by:

https://github.com/lxc/lxd/issues/579

The problem is that you need to map your uid to the host to the uid on the container, but liblxc doesn't handle the extra id_map correctly. Once that's fixed we will support it in practice, too.

Reply to this email directly or view it on GitHub: https://github.com/lxc/lxd/issues/592

hallyn commented 9 years ago

Idmap issues aside, bind mounting host directories into the container is done using a 'disk' device. There are a few small bugs (fixed in a merge proposal https://github.com/lxc/lxd/pull/594), but it works by doing:

lxc config device add v1 homedir disk source=/mnt path=/opt/home

'homedir' is the name of the device as lxd sees it (i.e. you can later 'lxc config device remove v1 homedir'); disk is the device type; source is the host path and path is the container path.

I'm hoping that 'lxc config edit v1' will allow you to edit all devices more easily though an external editor.

hallyn commented 9 years ago

I expect both to be done by end of day. the example shown at the top when you say 'lxc config edit v1" will show an example mounting a host directory into a container.

Note our usual policy of "when something is updated for a running container, the running container should be updated" cannot currently be adhered to in this case, because the kernel forbids cross-namespace mounts. We're hoping to look into loosening that restriction in the near future, but doing so safely may be problematic. This means you'll need to stop and restart a container for a change to take effect.

If this address what you want, then please close this issue. Otherwise, please let us know if you were looking for something different.

chrisglass commented 9 years ago

Thanks for the tip, it seems like adding a device to the container is easier and cleaner from an interface perspective than fiddling with the config directly.

It seems this approach also requires some uid/gid remapping like for https://github.com/lxc/lxd/issues/579 ? Could you give an example of how to do that?

techtonik commented 9 years ago

I didn't have time to experiment with it today, but it is nice to see it is possible. I hope there is some documentation about those config/profiles.

hallyn commented 9 years ago

This is temporary, as I hope that once we get the per-(lxd-)user uid ranges going we'll provide a better interface for this, but let's say that your files are owned by uid 1002 and gid 1004 on the host, and you want to map just the group (to protect the host user a bit). You would add the following line to /etc/subgid:

root:1004:1

then add the following to your lxd container config:

config: raw.lxc: lxc.id_map = g 400000 1004 1

Now group 1004 on the host is mapped to 400000 in the container. I'd recommend this (creating a new group, adding it to the groups for your host user, chgrping just the files you want to share to that new group, and mapping that group into the container) as the safest way to share files from your host user into the container. Of course if you 100% trust what's running in the container then you can just map your host userid.

techtonik commented 9 years ago 
$ lxc config device add gp sources disk source=$HOME/p/gratipay.com path=/opt/srv
Device sources added to gp
$ lxc exec gp -- ls -la /opt/srv
ls: cannot access /opt/srv: No such file or directory

Where is the device? Why config help refers to container as resource?

hallyn commented 9 years ago

On Fri, May 08, 2015 at 05:31:34AM -0700, anatoly techtonik wrote:

$ lxc config device add gp sources disk source=$HOME/p/gratipay.com path=/opt/srv
Device sources added to gp
$ lxc exec gp -- ls -la /opt/srv
ls: cannot access /opt/srv: No such file or directory

Just to be sure, did you (stop and) start gp between these two actions?

Where is the device?
Why config help refers to container as `resource`?

In general 'resource' has meant a potentially remote object, like a remote:image or remote:container. But I think you're right, in caess like this were it can only be a container, we should use the word container. Would you mind sending a patch to fix that?

techtonik commented 9 years ago

Just to be sure, did you (stop and) start gp between these two actions?

No. Restarted. Now I can see the files! =)

Would you mind sending a patch to fix that?

I don't mind sending a patch, but I do mind signing papers. My point is that it is harmful practice that should be abandoned. https://www.joyent.com/blog/broadening-node-js-contributions

Sorry about that.

tych0 commented 9 years ago

On Fri, May 08, 2015 at 08:15:26AM -0700, anatoly techtonik wrote:

Just to be sure, did you (stop and) start gp between these two actions?

No. Restarted. Now I can see the files! =)

Would you mind sending a patch to fix that?

I don't mind sending a patch, but I do mind signing papers. My point is that it is harmful practice that should be abandoned. https://www.joyent.com/blog/broadening-node-js-contributions

Sorry about that.

Note that the DCO is not a CLA. The DCO is basically a leagalese thing that came out of the SCO lawsuits, as I understand it. Lots of projects without a CLA (in particular, the Linux kernel) use it.

Reply to this email directly or view it on GitHub: https://github.com/lxc/lxd/issues/592#issuecomment-100268469

techtonik commented 9 years ago

Because CLA and DCO is offtopic here, I moved the answer to #609

stgraber commented 9 years ago

Ok, so going through this issue it looks to me like we already have:

Which cover the main issue raised here.

The other one is about the command line help saying "resources" in cases where only "container" is allowed. I filed #611.

Closing this one.

hallyn commented 9 years ago

Ok, thanks @techtonik . Sorry this has to be an issue. (I disagree in this particular case but can see where you're coming from). I'll post a patch myself in a bit.

techtonik commented 9 years ago

@stgraber it is not #419, because this one is still about mounting directories.

The final script to get development environment for Gratipay from scratch:

lxc init ubuntu gp
lxc config device add gp sources disk source=$PWD path=/root/gratipay.com
lxc start gp
lxc exec gp -- ./gratipay.com/scripts/bootstrap-debian.sh

But now I see the problem. The directory is owned by "nobody nogroup" and even root can not do anything in it.

techtonik commented 9 years ago

Will there be a better command to mount dirs? Like lxc mount source=... path=...?

Also, what is the role of sources disk name? I don't see it in /dev/sources.

stgraber commented 9 years ago

@techtonik disks as defined in LXD does cover directory bind-mounts.

We currently aren't planning an extra command for this, instead we plan on providing good examples in "lxc config edit" and "lxc config profile edit".

For disks, the "source" is either a partition UUID, or a block device path on the host or a directory or file path on the host. The actual type will make LXD either mount the device or do a bind-mount.

techtonik commented 9 years ago

Thanks for clarification. The question is then what is the role of name in config device add. I thought it is something that is available as device on guest under that name.

$ lxc config device add <resource> <name> <type> [key=value]...
stgraber commented 9 years ago

The "name" field is mandatory for all devices entry, that's because both internally and over the REST API, the device list is exported as a dict/map.

The reason why we're doing this, rather than treat it as a list is to deal with inheritance between profiles and local container config.

So if a device is defined both in a profile and directly in the container's config, the one in the container config will be used (we don't allow overriding of single device properties).