lxc userspace tools 0.3.0 released
Hi,
a new version of lxc has been released.
https://sourceforge.net/projects/lxc/
This version takes into account the control group and provides the checkpoint / restart for external checkpoint.
It includes a lot of small improvements and fixes, full details are in the ChangeLog file.
Thanks.
-- Daniel
A message that is not in the archive (sent off-list or not yet received): 48F4AF2E.3000204-NmTC/[email protected]
Quoted 11 lines · Daniel Lezcano
Hi,
a new version of lxc has been released.
https://sourceforge.net/projects/lxc/
This version takes into account the control group and provides the checkpoint / restart for external checkpoint.
It includes a lot of small improvements and fixes, full details are in the ChangeLog file.
and the patchset that goes with the user tools is available here :
http://lxc.sourceforge.net/patches/2.6.27/2.6.27-lxc1/
http://lxc.sourceforge.net/patches/2.6.27/2.6.27-lxc1.tar.gz
http://lxc.sourceforge.net/patches/2.6.27/2.6.27-lxc1.patch.gz
Cheers,
C.
Hi, Daniel!
I studied a bit lxc tools and have a couple of questions. Could you answer them?
1) Why did you chose such way of a container's configuration storing? IMHO, configuration in one file is better, because this file will be small and could be easily mmap'ed for the following operations instead of multiple readdir() and filesystem lookups.
2) why did you chose cvs as VCS? Git is more common and convenient for distributed development...
Signature · 2 lines
Thanks, Dmitry.
Quoted 24 lines · On Tuesday 14 October 2008 18:39:42 Daniel Lezcano wrote:
Hi,
a new version of lxc has been released.
https://sourceforge.net/projects/lxc/
This version takes into account the control group and provides the checkpoint / restart for external checkpoint.
It includes a lot of small improvements and fixes, full details are in the ChangeLog file.
Thanks.
-- Daniel_______________________________________________
Containers mailing list Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers_______________________________________________
Devel mailing list
[email protected]
https://openvz.org/mailman/listinfo/devel
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 1 line · Dmitry Mishin
Hi, Daniel!
Hi Dmitry ! good to see you again :)
Quoted 2 lines
I studied a bit lxc tools and have a couple of questions. Could you answer them?
Of course I can :)
Quoted 4 lines
1) Why did you chose such way of a container's configuration storing? IMHO, configuration in one file is better, because this file will be small and could be easily mmap'ed for the following operations instead of multiple
readdir()and filesystem lookups.
I wanted to have the configuration easily hackable, so you can edit directly the files inside the directory. For example, if you remove the network directory, when you will start the container, the network will not be unshared. If you have a single file, that will be more difficult to edit especially if it is a binary file.
The container tree contains more than the configuration file, for example, it contains some runtime information.
It is true having a mmapped configuration is more efficient but it is just for container startup, and there are not thousand of files. The application running inside the container is not impacted.
Quoted 2 lines
2) why did you chose cvs as VCS? Git is more common and convenient for distributed development...
The lxc userspace tool is a low level component I wrote to play with the container, and especially to facilitate the kernek hacking. The lxc kernel website is at lxc.sourceforge.net, so logically I put this component at the same place. Unfortunately the sourceforge website does not provide the services for git tree, only CVS/SVN. But I agree 100% with you, I would have definitively preferred to use git.
A message that is not in the archive (sent off-list or not yet received): 48F70425.5090606-NmTC/[email protected]
Quoted 4 lines · On Thursday 16 October 2008 13:06:45 Daniel Lezcano wrote:
Quoted 1 line · Dmitry Mishin
Hi, Daniel!
Hi Dmitry ! good to see you again :)
Thank you ! :)
Quoted 17 lines
Quoted 3 lines
I studied a bit lxc tools and have a couple of questions. Could you answer them?
Of course I can :)
Quoted 4 lines
1) Why did you chose such way of a container's configuration storing? IMHO, configuration in one file is better, because this file will be small and could be easily mmap'ed for the following operations instead of multiple
readdir()and filesystem lookups.I wanted to have the configuration easily hackable, so you can edit directly the files inside the directory. For example, if you remove the network directory, when you will start the container, the network will not be unshared. If you have a single file, that will be more difficult to edit especially if it is a binary file.
Quoted 6 lines
The container tree contains more than the configuration file, for example, it contains some runtime information.
It is true having a mmapped configuration is more efficient but it is just for container startup, and there are not thousand of files. The application running inside the container is not impacted.
OK, but what if I need some namespace to be shared between containers? How it will be handled? For example, CT 1 and CT 2 need to share network namespace, but keep it separated from host one.
Quoted 10 lines
Quoted 3 lines
2) why did you chose cvs as VCS? Git is more common and convenient for distributed development...
The lxc userspace tool is a low level component I wrote to play with the container, and especially to facilitate the kernek hacking. The lxc kernel website is at lxc.sourceforge.net, so logically I put this component at the same place. Unfortunately the sourceforge website does not provide the services for git tree, only CVS/SVN. But I agree 100% with you, I would have definitively preferred to use git.
Worth to create it at git.openvz.org?
Signature · 2 lines
Thanks, Dmitry.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 23 lines · Dmitry Mishin
Quoted 3 lines · On Thursday 16 October 2008 13:06:45 Daniel Lezcano wrote:
Quoted 1 line · Dmitry Mishin
Hi, Daniel!
Hi Dmitry ! good to see you again :)
Thank you ! :)
Quoted 17 lines
Quoted 2 lines
I studied a bit lxc tools and have a couple of questions. Could you answer them?
Of course I can :)
Quoted 4 lines
1) Why did you chose such way of a container's configuration storing? IMHO, configuration in one file is better, because this file will be small and could be easily mmap'ed for the following operations instead of multiple
readdir()and filesystem lookups.I wanted to have the configuration easily hackable, so you can edit directly the files inside the directory. For example, if you remove the network directory, when you will start the container, the network will not be unshared. If you have a single file, that will be more difficult to edit especially if it is a binary file.
The container tree contains more than the configuration file, for example, it contains some runtime information.
Quoted 6 lines
Quoted 3 lines
It is true having a mmapped configuration is more efficient but it is just for container startup, and there are not thousand of files. The application running inside the container is not impacted.
OK, but what if I need some namespace to be shared between containers? How it will be handled? For example, CT 1 and CT 2 need to share network namespace, but keep it separated from host one.
I think that can be solved by nested container, a container 1, unsharing the network, and inside create 2 containers without unsharing the network.
Example:
in a script called myscript.sh:
#!/bin/bash
lxc-execute -n ctr1 echo "hello1" & lxc-execute -n ctr2 echo "hello2"
in the shell:
lxc-create -n mynetwork -f myconf
lxc-execute -n mynetwork ./myscript.sh
Do you have an example, an use case for this kind of configuration ?
Quoted 9 lines
Quoted 8 lines
Quoted 2 lines
2) why did you chose cvs as VCS? Git is more common and convenient for distributed development...
The lxc userspace tool is a low level component I wrote to play with the container, and especially to facilitate the kernek hacking. The lxc kernel website is at lxc.sourceforge.net, so logically I put this component at the same place. Unfortunately the sourceforge website does not provide the services for git tree, only CVS/SVN. But I agree 100% with you, I would have definitively preferred to use git.
Worth to create it at git.openvz.org?
Yep, why not. I have to think about that.
A message that is not in the archive (sent off-list or not yet received): 48F73358.80208-NmTC/[email protected]
Quoted 45 lines · On Thursday 16 October 2008 16:28:08 Daniel Lezcano wrote:
Quoted 27 lines · Dmitry Mishin
Quoted 4 lines · On Thursday 16 October 2008 13:06:45 Daniel Lezcano wrote:
Quoted 1 line · Dmitry Mishin
Hi, Daniel!
Hi Dmitry ! good to see you again :)
Thank you ! :)
Quoted 19 lines
Quoted 2 lines
I studied a bit lxc tools and have a couple of questions. Could you answer them?
Of course I can :)
Quoted 4 lines
1) Why did you chose such way of a container's configuration storing? IMHO, configuration in one file is better, because this file will be small and could be easily mmap'ed for the following operations instead of multiple
readdir()and filesystem lookups.I wanted to have the configuration easily hackable, so you can edit directly the files inside the directory. For example, if you remove the network directory, when you will start the container, the network will not be unshared. If you have a single file, that will be more difficult to edit especially if it is a binary file.
The container tree contains more than the configuration file, for example, it contains some runtime information.
Quoted 7 lines
Quoted 3 lines
It is true having a mmapped configuration is more efficient but it is just for container startup, and there are not thousand of files. The application running inside the container is not impacted.
OK, but what if I need some namespace to be shared between containers? How it will be handled? For example, CT 1 and CT 2 need to share network namespace, but keep it separated from host one.
I think that can be solved by nested container, a container 1, unsharing the network, and inside create 2 containers without unsharing the network.
Example:
in a script calledmyscript.sh:
#!/bin/bash
lxc-execute -n ctr1 echo "hello1" & lxc-execute -n ctr2 echo "hello2"
Quoted 3 lines
in the shell:
lxc-create -n mynetwork -f myconf
lxc-execute -n mynetwork ./myscript.sh
I mean how it will be handled from configuration layout POV?
Quoted 3 lines
Do you have an example, an use case for this kind of configuration ?
For example, web server and dns server for the same domain, hosted on the external node.
As you mentioned, the goal of this tool is to provide ability for kernel hackers to test namespaces support in mainstream. Thus it should be flexible as possible and do not add limitations over current functionality. Current design of configuration storing is likely to be a week place in this sense. At least I do not understand yet how namespaces inheritance could be reflected in it.
Quoted 14 lines
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
2) why did you chose cvs as VCS? Git is more common and convenient for distributed development...
Quoted 8 lines
Quoted 6 lines
The lxc userspace tool is a low level component I wrote to play with the container, and especially to facilitate the kernek hacking. The lxc kernel website is at lxc.sourceforge.net, so logically I put this component at the same place. Unfortunately the sourceforge website does not provide the services for git tree, only CVS/SVN. But I agree 100% with you, I would have definitively preferred to use git.
Worth to create it at git.openvz.org?
Yep, why not. I have to think about that.
Signature · 2 lines
Thanks, Dmitry.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 43 lines · Dmitry Mishin
Quoted 39 lines · On Thursday 16 October 2008 16:28:08 Daniel Lezcano wrote:
Quoted 23 lines · Dmitry Mishin
Quoted 3 lines · On Thursday 16 October 2008 13:06:45 Daniel Lezcano wrote:
Quoted 1 line · Dmitry Mishin
Hi, Daniel!
Hi Dmitry ! good to see you again :)
Thank you ! :)
Quoted 17 lines
Quoted 2 lines
I studied a bit lxc tools and have a couple of questions. Could you answer them?
Of course I can :)
Quoted 4 lines
1) Why did you chose such way of a container's configuration storing? IMHO, configuration in one file is better, because this file will be small and could be easily mmap'ed for the following operations instead of multiple
readdir()and filesystem lookups.I wanted to have the configuration easily hackable, so you can edit directly the files inside the directory. For example, if you remove the network directory, when you will start the container, the network will not be unshared. If you have a single file, that will be more difficult to edit especially if it is a binary file.
The container tree contains more than the configuration file, for example, it contains some runtime information.
Quoted 6 lines
Quoted 3 lines
It is true having a mmapped configuration is more efficient but it is just for container startup, and there are not thousand of files. The application running inside the container is not impacted.
OK, but what if I need some namespace to be shared between containers? How it will be handled? For example, CT 1 and CT 2 need to share network namespace, but keep it separated from host one.
I think that can be solved by nested container, a container 1, unsharing the network, and inside create 2 containers without unsharing the network.
Example:
in a script calledmyscript.sh:
#!/bin/bash
lxc-execute -n ctr1 echo "hello1" & lxc-execute -n ctr2 echo "hello2"Quoted 3 lines
in the shell:
lxc-create -n mynetwork -f myconf
lxc-execute -n mynetwork ./myscript.sh
Quoted 6 lines
I mean how it will be handled from configuration layout POV?
Quoted 2 lines
Do you have an example, an use case for this kind of configuration ?
For example, web server and dns server for the same domain, hosted on the external node.
Ok I see, thanks.
Quoted 6 lines
As you mentioned, the goal of this tool is to provide ability for kernel hackers to test namespaces support in mainstream. Thus it should be flexible as possible and do not add limitations over current functionality. Current design of configuration storing is likely to be a week place in this sense. At least I do not understand yet how namespaces inheritance could be reflected in it.
I don't think it is a current limitation as I shown in the previous example. Not being able to define a configuration for a nested container is not a big issue right now because the nested container are not fully supported (eg. network devices being pushed back to init_net).
The configuration storing is I think a good approach and it is not an API like the cgroup, it can be changed at any time. The advantage of having a tree file for a container will appear more clear with the future functionalities.
If the nested containers become a must-have and asked by people, the lxc tools will be changed in this way. We can imagine to do like the cgroup and create in the container directory a new container directory to reflect the hierarchy and we access a container by doing for example "lxc-stop -n foo/bar" (bar is a child of foo). We can imagine to implement a fuse for containers and create / destroy when doing mkdir/rmdir, as well as create a directory when doing lxc_create.
The configuration could be something like:
Create a nested container with two configuration files:
lxc-create -n foo/bar -f foo.conf -f bar.conf
And so execute:
lxc-execute -n foo/bar /usr/sbin/httpd /bin/bash
will unshare 'foo', exec 'httpd' and so unshare 'bar' (under 'foo') and exec 'bash'
Well these are random thoughts... :)
Thanks
-- Daniel
A message that is not in the archive (sent off-list or not yet received): 48F8F8BE.7080509-NmTC/[email protected]
Quoted 68 lines · On Saturday 18 October 2008 00:42:38 Daniel Lezcano wrote:
Quoted 51 lines · Dmitry Mishin
Quoted 46 lines · On Thursday 16 October 2008 16:28:08 Daniel Lezcano wrote:
Quoted 27 lines · Dmitry Mishin
Quoted 4 lines · On Thursday 16 October 2008 13:06:45 Daniel Lezcano wrote:
Quoted 1 line · Dmitry Mishin
Hi, Daniel!
Hi Dmitry ! good to see you again :)
Thank you ! :)
Quoted 19 lines
Quoted 2 lines
I studied a bit lxc tools and have a couple of questions. Could you answer them?
Of course I can :)
Quoted 4 lines
1) Why did you chose such way of a container's configuration storing? IMHO, configuration in one file is better, because this file will be small and could be easily mmap'ed for the following operations instead of multiple
readdir()and filesystem lookups.I wanted to have the configuration easily hackable, so you can edit directly the files inside the directory. For example, if you remove the network directory, when you will start the container, the network will not be unshared. If you have a single file, that will be more difficult to edit especially if it is a binary file.
The container tree contains more than the configuration file, for example, it contains some runtime information.
Quoted 7 lines
Quoted 3 lines
It is true having a mmapped configuration is more efficient but it is just for container startup, and there are not thousand of files. The application running inside the container is not impacted.
OK, but what if I need some namespace to be shared between containers? How it will be handled? For example, CT 1 and CT 2 need to share network namespace, but keep it separated from host one.
I think that can be solved by nested container, a container 1, unsharing the network, and inside create 2 containers without unsharing the network.
Example:
in a script calledmyscript.sh:
#!/bin/bash
lxc-execute -n ctr1 echo "hello1" & lxc-execute -n ctr2 echo "hello2"Quoted 3 lines
in the shell:
lxc-create -n mynetwork -f myconf
lxc-execute -n mynetwork ./myscript.shQuoted 6 lines
I mean how it will be handled from configuration layout POV?
Quoted 1 line
Do you have an example, an use case for this kind of configuration ?
For example, web server and dns server for the same domain, hosted on the external node.
Ok I see, thanks.
Quoted 6 lines
As you mentioned, the goal of this tool is to provide ability for kernel hackers to test namespaces support in mainstream. Thus it should be flexible as possible and do not add limitations over current functionality. Current design of configuration storing is likely to be a week place in this sense. At least I do not understand yet how namespaces inheritance could be reflected in it.
Quoted 7 lines
I don't think it is a current limitation as I shown in the previous example. Not being able to define a configuration for a nested container is not a big issue right now because the nested container are not fully supported (eg. network devices being pushed back to
init_net).The configuration storing is I think a good approach and it is not an API like the cgroup, it can be changed at any time.
With the respective backward-compatibility or conversion code to be written...
Quoted 9 lines
The advantage of
having a tree file for a container will appear more clear with the future functionalities.If the nested containers become a must-have and asked by people, the lxc tools will be changed in this way. We can imagine to do like the cgroup and create in the container directory a new container directory to reflect the hierarchy and we access a container by doing for example "lxc-stop -n foo/bar" (bar is a child of foo).
Unification with cgroups is good idea, IMHO.
Quoted 9 lines
We can imagine to
implement a fuse for containers and create / destroy when doing mkdir/rmdir, as well as create a directory when doinglxc_create.The configuration could be something like:
Create a nested container with two configuration files:
lxc-create -n foo/bar -f foo.conf -f bar.conf
Quoted 7 lines
And so execute:
lxc-execute -n foo/bar/usr/sbin/httpd/bin/bashwill unshare 'foo', exec 'httpd' and so unshare 'bar' (under 'foo') and exec 'bash'
Well these are random thoughts... :)
Good thoughts! I need to take a look at cgroups management tools and possibly develop something usefull for lxc :)
Quoted 3 lines
Thanks
-- Daniel
Signature · 2 lines
Thanks, Dmitry.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 59 lines · Dmitry Mishin
Quoted 58 lines · On Saturday 18 October 2008 00:42:38 Daniel Lezcano wrote:
Quoted 41 lines · Dmitry Mishin
Quoted 40 lines · On Thursday 16 October 2008 16:28:08 Daniel Lezcano wrote:
Quoted 23 lines · Dmitry Mishin
Quoted 3 lines · On Thursday 16 October 2008 13:06:45 Daniel Lezcano wrote:
Quoted 1 line · Dmitry Mishin
Hi, Daniel!
Hi Dmitry ! good to see you again :)
Thank you ! :)
Quoted 17 lines
Quoted 2 lines
I studied a bit lxc tools and have a couple of questions. Could you answer them?
Of course I can :)
Quoted 4 lines
1) Why did you chose such way of a container's configuration storing? IMHO, configuration in one file is better, because this file will be small and could be easily mmap'ed for the following operations instead of multiple
readdir()and filesystem lookups.I wanted to have the configuration easily hackable, so you can edit directly the files inside the directory. For example, if you remove the network directory, when you will start the container, the network will not be unshared. If you have a single file, that will be more difficult to edit especially if it is a binary file.
The container tree contains more than the configuration file, for example, it contains some runtime information.
Quoted 6 lines
Quoted 3 lines
It is true having a mmapped configuration is more efficient but it is just for container startup, and there are not thousand of files. The application running inside the container is not impacted.
OK, but what if I need some namespace to be shared between containers? How it will be handled? For example, CT 1 and CT 2 need to share network namespace, but keep it separated from host one.
I think that can be solved by nested container, a container 1, unsharing the network, and inside create 2 containers without unsharing the network.
Example:
in a script calledmyscript.sh:
#!/bin/bash
lxc-execute -n ctr1 echo "hello1" & lxc-execute -n ctr2 echo "hello2"Quoted 8 lines
Quoted 3 lines
in the shell:
lxc-create -n mynetwork -f myconf
lxc-execute -n mynetwork ./myscript.shI mean how it will be handled from configuration layout POV?
Quoted 1 line
Do you have an example, an use case for this kind of configuration ?
For example, web server and dns server for the same domain, hosted on the external node.
Ok I see, thanks.
Quoted 6 lines
As you mentioned, the goal of this tool is to provide ability for kernel hackers to test namespaces support in mainstream. Thus it should be flexible as possible and do not add limitations over current functionality. Current design of configuration storing is likely to be a week place in this sense. At least I do not understand yet how namespaces inheritance could be reflected in it.
Quoted 8 lines
Quoted 7 lines
I don't think it is a current limitation as I shown in the previous example. Not being able to define a configuration for a nested container is not a big issue right now because the nested container are not fully supported (eg. network devices being pushed back to
init_net).The configuration storing is I think a good approach and it is not an API like the cgroup, it can be changed at any time.
With the respective backward-compatibility or conversion code to be written...
Good point :)
Quoted 6 lines · Daniel Lezcano
Hi,
a new version of lxc has been released.
Quoted 8 lines
This version takes into account the control group and provides the checkpoint / restart for external checkpoint.
It includes a lot of small improvements and fixes, full details are in the ChangeLog file.
Thanks.
-- Daniel
Hi !
I'm glad to hear about progress of Linux containers.
But I have a few questions:
1. How does LXC compare to OpenVZ ?
and
2. What portion of code is shared between the two ?
Signature · 1 line
-Alexey Eromenko "Technologov"
A message that is not in the archive (sent off-list or not yet received): 7fac565a0810160122n7afa6e71l929be8cb08ba05c6-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 16 lines · Alexey Eremenko
Quoted 6 lines · Daniel Lezcano
Hi,
a new version of lxc has been released.
Quoted 8 lines
This version takes into account the control group and provides the checkpoint / restart for external checkpoint.
It includes a lot of small improvements and fixes, full details are in the ChangeLog file.
Thanks.
-- Daniel
Quoted 6 lines
Hi !
I'm glad to hear about progress of Linux containers.
But I have a few questions:
1. How does LXC compare to OpenVZ ?
I used OpenVZ a few years ago, so perhaps I am wrong comparing OpenVZ and LXC, I know the openvz devel mailling list is tied with the containers@ mailing, so I hope if I am wrong someone will correct me :)
Just to clarify to avoid confusion. There is a LXC project inside the libvirt and there is the lxc userspace tools (liblxc). We are talking about the liblxc.
The liblxc is a low level component. There is a library and a set of command lines.
The library provides a set of API to manage the containers. That allows people to start, stop, create, destroy, monitor, etc ... containers. On top of that, there is a set of command lines relying on this library to play with the containers in a shell.
OpenVZ is a full featured container, providing a lot of services. A single command 'vzctl' manages the containers.
The liblxc follows what is in mainline and what will be in mainline. So the liblxc can be used with a vanilla kernel or the development kernel we are working on.
OpenVZ provides more than what is existing in mainline, that means it needs a modified kernel, even if the different features are little by little pushed upstream and the OpenVZ kernel patch is being smaller.
The liblxc takes into account two families of containers, the system containers and the application containers. The first one launches a full distro like a debian, the first process is the 'init' process, the system configuration is done by the different services of the distros. The second one, launches only an application (that can be 'bash', 'sshd', or something else), and setup the container (network, mount points, etc ...) because there is no services to do that.
OpenVZ, AFAIK, supports the system container but not the application containers.
To summarize:
* OpenVZ is a mature project with a lot of features, (for example the
migration, checkpoint/restart), aiming to create system container using a shell command.
* Liblxc is a low level component following what is in mainline, (or
in a near future), with the objective to be simple to use.
Quoted 1 line
2. What portion of code is shared between the two ?
I am not sure I understand the question. Do you mean : "is liblxc using OpenVZ code ?"
A message that is not in the archive (sent off-list or not yet received): 48F70E53.9070002-NmTC/[email protected]
Well, Thanks for explanation...
libvirt uses liblxc or uses kernelspace containers directly ?
Quoted 5 lines
Quoted 1 line
2. What portion of code is shared between the two ?
I am not sure I understand the question. Do you mean : "is liblxc using OpenVZ code ?"
Here I mean that OpenVZ and LXC have kernelspace code shared - at least partially.
(because OpenVZ developers are the ones who are developing kernelspace LXC and pushing code upstream)
Do you know how much of it ?
I think userspace is not shared at all.
Signature · 1 line
-Alexey Eromenko "Technologov"
A message that is not in the archive (sent off-list or not yet received): 7fac565a0810160256mc3de8b5raf4bab31470b051a-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 3 lines · Alexey Eremenko
Well, Thanks for explanation...
libvirt uses liblxc or uses kernelspace containers directly ?
kernelspace containers directly.
Quoted 11 lines
Quoted 4 lines
Quoted 1 line
2. What portion of code is shared between the two ?
I am not sure I understand the question. Do you mean : "is liblxc using OpenVZ code ?"
Here I mean that OpenVZ and LXC have kernelspace code shared - at least partially.
(because OpenVZ developers are the ones who are developing kernelspace LXC and pushing code upstream)Do you know how much of it ?
Well OpenVZ guys are part of the container community, we are working together to push upstream the kernel code, this is not only an OpenVZ effort.
The userspace code is using a set of services provided by the kernel. So instead of talking about shared kernel code, IMO, we can talk about the used services by both OpenVZ and liblxc.
I can not give a full detail of what are the services used by OpenVZ but I think it is reasonable to say liblxc uses at least a subset of what is using OpenVZ.
Here is the detail of the kernel features used by the liblxc:
* cgroup with cgroup scheduler and all the subsystems
* freezer
* ipc namespace
* pid namespace
* uts namespace
* network namespace
* mount namespace
Quoted 1 line
I think userspace is not shared at all.
Correct :)
Quoted 3 lines
Just to clarify to avoid confusion. There is a LXC project inside the libvirt and there is the lxc userspace tools (liblxc). We are talking about the liblxc.
I wouldn't say there is a "LXC project inside the libvirt" but rather there is a libvirt driver emulating a virtual machine using namespaces. This driver is called lxc for some reason I don't know and this is very unfortunate IMO.
C.
A message that is not in the archive (sent off-list or not yet received): 48F739BB.4070201-NmTC/[email protected]
Quoted 8 lines · Cedric Le Goater
Quoted 3 lines
Just to clarify to avoid confusion. There is a LXC project inside the libvirt and there is the lxc userspace tools (liblxc). We are talking about the liblxc.
I wouldn't say there is a "LXC project inside the libvirt" but rather there is a libvirt driver emulating a virtual machine using namespaces. This driver is called lxc for some reason I don't know and this is very unfortunate IMO.
It is called LXC because it implements "LinuX Containers". When we first released this LXC driver in libvirt this lxc userspace tools package didn't exist so there was no naming clash.
Daniel
Signature · 4 lines
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines · Daniel P. Berrange
Quoted 3 lines · Cedric Le Goater
Quoted 3 lines
Just to clarify to avoid confusion. There is a LXC project inside the libvirt and there is the lxc userspace tools (liblxc). We are talking about the liblxc.
Quoted 8 lines
Quoted 4 lines
I wouldn't say there is a "LXC project inside the libvirt" but rather there is a libvirt driver emulating a virtual machine using namespaces. This driver is called lxc for some reason I don't know and this is very unfortunate IMO.
It is called LXC because it implements "LinuX Containers". When we first released this LXC driver in libvirt this lxc userspace tools package didn't exist so there was no naming clash.
Libvirt being a VM/container middleware, shouldn't we change lxc-driver to use liblxc ?