Re: [Lxc-users] How to start the network services so as to get the IP address using lxc-execute???
Hi, *My basic need::* I am writing a *simple socket programme *and as input to programme I want to give the* IP address of containers*. Now* I have IP address in sequential order*, but to make my socket programme running I need the networking service of the containers to start. *I am able to do this using lxc-start* as it call lxc-init where upstart which handles the starting of service during booting, but* I don't want to use this lxc-start, but want to start only networking service* so that my socket programme works. Can I start only networking service using lxc-execute or not Is there any other solution to this? Regards, Nishant On Mon, Dec 12, 2011 at 3:31 PM, Greg Kurz gk...@fr.ibm.com wrote: On Mon, 2011-12-12 at 11:54 +0530, nishant mungse wrote: Hi Geordy, Hi Nishant, I removed Cc: to containers@ as your troubles are about using the lxc userspace tool: lxc-users@ is THE place for seeking help. This script gives the IP address of running system, but what I want is to get the IP address of the containers that are not started using lxc-start, lxc-start will call /sbin/init to init all the system, but I want to use lxc-execute that will no init the system. I still don't understand what you intend to do... All I can say is that using lxc-execute to partially start a container (that's what you're doing when you want do lxc-execute /etc/init.d/networking) is a total nonsense. Sorry. Hey Greg you said that, it is possible to get the IP address without starting the containers how can we do this Your containers don't get their IP addresses in a vacuum... Either the addresses are statically configured is some distro specific file, either they are assigned by an external service (DHCP most of the time). In the first case, you can probably find the address by parsing the appropriate file from your container's filesystem (/etc/sysconfig/network-scripts/ifcfg-eth0 for example on redhat). In the second case, it depends on the DHCP server setup... please see that with your sysadmin. And one more question how to start the network services using lxc-execute As told before, nonsense. Please help me ASAP. That's what several people on the list are trying to do... If you really need help, stop asking about how to misuse lxc-execute and give some hints about your network setup... Do your containers use static addresses ? Do they rely on a DHCP server ? Are you sysadmin for the DHCP server ? Unless you provide more context, I'm afraid nobody will be able to help you... Cheers. -- Gregory Kurz gk...@fr.ibm.com Software Engineer @ IBM/Meiosys http://www.ibm.com Tel +33 (0)534 638 479 Fax +33 (0)561 400 420 Anarchy is about taking complete responsibility for yourself. Alan Moore. -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] How to start the network services so as to get the IP address using lxc-execute???
On Tue, 2011-12-13 at 14:42 +0530, nishant mungse wrote: Hi, My basic need:: I am writing a simple socket programme and as input to programme I want to give the IP address of containers. Now I have IP address in sequential order, but to make my socket programme running I need the networking service of the containers to start. Hmmm... not enough context again. Where does the program run: container or host ? What does it do ? I am able to do this using lxc-start as it call lxc-init where upstart ^ Are you sure this is what you want to say ? AFAIK lxc-start doesn't call lxc-init by default but /sbin/init (upstart in your case). which handles the starting of service during booting, but I don't Right. want to use this lxc-start, but want to start only networking service Why don't you want to use lxc-start ? Is it because you want to defer the starting of some services to a later time ? so that my socket programme works. Can I start only networking service using lxc-execute or not No you can't. Is there any other solution to this? If your need is to defer the startup of some services, then it's an upstart story... I don't know upstart but I guess it's possible to configure it so that when you do lxc-start, a minimal set of services will be started to provide network. Regards, Nishant Cheers. -- Greg On Mon, Dec 12, 2011 at 3:31 PM, Greg Kurz gk...@fr.ibm.com wrote: On Mon, 2011-12-12 at 11:54 +0530, nishant mungse wrote: Hi Geordy, Hi Nishant, I removed Cc: to containers@ as your troubles are about using the lxc userspace tool: lxc-users@ is THE place for seeking help. This script gives the IP address of running system, but what I want is to get the IP address of the containers that are not started using lxc-start, lxc-start will call /sbin/init to init all the system, but I want to use lxc-execute that will no init the system. I still don't understand what you intend to do... All I can say is that using lxc-execute to partially start a container (that's what you're doing when you want do lxc-execute /etc/init.d/networking) is a total nonsense. Sorry. Hey Greg you said that, it is possible to get the IP address without starting the containers how can we do this Your containers don't get their IP addresses in a vacuum... Either the addresses are statically configured is some distro specific file, either they are assigned by an external service (DHCP most of the time). In the first case, you can probably find the address by parsing the appropriate file from your container's filesystem (/etc/sysconfig/network-scripts/ifcfg-eth0 for example on redhat). In the second case, it depends on the DHCP server setup... please see that with your sysadmin. And one more question how to start the network services using lxc-execute As told before, nonsense. Please help me ASAP. That's what several people on the list are trying to do... If you really need help, stop asking about how to misuse lxc-execute and give some hints about your network setup... Do your containers use static addresses ? Do they rely on a DHCP server ? Are you sysadmin for the DHCP server ? Unless you provide more context, I'm afraid nobody will be able to help you... Cheers. -- Gregory Kurz gk...@fr.ibm.com Software Engineer @ IBM/Meiosys http://www.ibm.com Tel +33 (0)534 638 479 Fax +33 (0)561 400 420 Anarchy is about taking complete responsibility for yourself. Alan Moore. -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Container size minialisation
Zhu Yanhai (2011-12-13 12:00:20 +0800) wrote: On 12/12/2011 09:47 AM, István Király - LaKing wrote: As next step I would like to minimize container size. My question is, what the best, most elegant and fail proof technique for that? It's not only an issue about disk space, it's about page cache cost. If the under level files are shared, the OS see them as unique inodes, so the OS allocate only one copy for each one inode. However if we copy them as separate directories, each of them will occupy one copy in the page cache, resulting in large cost of memory. I think a better approach here is a file-level copy-on-write trick in filesystem or some other proper layers. Initially all files are shared in the host, and copy one as a private item at the first time it is touched in one containers. I've carried out some tests with union mount points and Btrfs seeds and CoW copies, and all of them seem to work without problems with LXC. For union mount points, you can keep a base rootfs under a read-only directory, and then mount a writable directory on top of that for each container's rootfs, like this: /var/lib/lxc/.base/debian-squeeze (RO, don't change it!) + /var/lib/lxc/.store/lxc01/ (RW) = /var/lib/lxc/lxc01/rootfs/ (RW) + /var/lib/lxc/.store/lxc02/ (RW) = /var/lib/lxc/lxc02/rootfs/ (RW) Changed files are written under .store/lxcNN. Debian includes AuFS for union mount points. A similar solution are Btrfs seeds: you have a read-only seed Btrfs and writable images (e.g. files via loop devices) on top, like this: /dev/loop0 (var/lib/lxc/.base/debian-squeeze.btrfs) (RO, seed) + /dev/loop1 (/var/lib/lxc/.store/lxc01.raw) (RW) = /var/lib/lxc/lxc01/rootfs/ (RW) + /dev/loop2 (/var/lib/lxc/.store/lxc02.raw) (RW) = /var/lib/lxc/lxc02/rootfs/ (RW) Changed blocks are stored under .store/lxcNN.raw (which should be big enough). As for CoW copies in Btrfs, you can use simple CoW copies: # cp -a --reflink /var/lib/lxc/.base/debian-squeeze /var/lib/lxc/lxc01/rootfs/ or you can create a subvolume out of /var/lib/lxc/.base/debian-squeeze in your Btrfs filesystem and /var/lib/lxc/lxc01/rootfs/ as a snapshot of that subvolume. In both cases only changed blocks are stored on disc, but I've found subvolumes to be a lot faster on creation and removal. Hope that helps, -- Ivan Vilata i Balaguer -- https://elvil.net/ -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Container size minialisation
2011/12/13 Ivan Vilata i Balaguer i...@selidor.net: Zhu Yanhai (2011-12-13 12:00:20 +0800) wrote: On 12/12/2011 09:47 AM, István Király - LaKing wrote: As next step I would like to minimize container size. My question is, what the best, most elegant and fail proof technique for that? It's not only an issue about disk space, it's about page cache cost. If the under level files are shared, the OS see them as unique inodes, so the OS allocate only one copy for each one inode. However if we copy them as separate directories, each of them will occupy one copy in the page cache, resulting in large cost of memory. I think a better approach here is a file-level copy-on-write trick in filesystem or some other proper layers. Initially all files are shared in the host, and copy one as a private item at the first time it is touched in one containers. I've carried out some tests with union mount points and Btrfs seeds and CoW copies, and all of them seem to work without problems with LXC. For union mount points, you can keep a base rootfs under a read-only directory, and then mount a writable directory on top of that for each container's rootfs, like this: /var/lib/lxc/.base/debian-squeeze (RO, don't change it!) + /var/lib/lxc/.store/lxc01/ (RW) = /var/lib/lxc/lxc01/rootfs/ (RW) + /var/lib/lxc/.store/lxc02/ (RW) = /var/lib/lxc/lxc02/rootfs/ (RW) Changed files are written under .store/lxcNN. Debian includes AuFS for union mount points. A similar solution are Btrfs seeds: you have a read-only seed Btrfs and writable images (e.g. files via loop devices) on top, like this: /dev/loop0 (var/lib/lxc/.base/debian-squeeze.btrfs) (RO, seed) + /dev/loop1 (/var/lib/lxc/.store/lxc01.raw) (RW) = /var/lib/lxc/lxc01/rootfs/ (RW) + /dev/loop2 (/var/lib/lxc/.store/lxc02.raw) (RW) = /var/lib/lxc/lxc02/rootfs/ (RW) Changed blocks are stored under .store/lxcNN.raw (which should be big enough). As for CoW copies in Btrfs, you can use simple CoW copies: # cp -a --reflink /var/lib/lxc/.base/debian-squeeze /var/lib/lxc/lxc01/rootfs/ or you can create a subvolume out of /var/lib/lxc/.base/debian-squeeze in your Btrfs filesystem and /var/lib/lxc/lxc01/rootfs/ as a snapshot of that subvolume. In both cases only changed blocks are stored on disc, but I've found subvolumes to be a lot faster on creation and removal. Hope that helps, -- Ivan Vilata i Balaguer -- https://elvil.net/ Thank you Ivan. My concern is deploying Btrfs only for COW is a really heavy solution for this...Is Btrfs ready for production system? -zyh -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Container size minialisation
Zhu Yanhai (2011-12-13 18:43:41 +0800) wrote: 2011/12/13 Ivan Vilata i Balaguer i...@selidor.net: I've carried out some tests with union mount points and Btrfs seeds and CoW copies, and all of them seem to work without problems with LXC. Thank you Ivan. My concern is deploying Btrfs only for COW is a really heavy solution for this...Is Btrfs ready for production system? Union mount points may be more lightweight but none is available in the mainstream Linux kernel, and their support of some peculiar filesystem features like inotify may vary. Btrfs is part of mainstream and well maintained, however its developers consider it experimental and I've only performed very basic tests on containers (e.g. starting, running some programs, shutting down), so I can't give you advice on that. I guess the best way to know is by testing on non-production systems. :) Cheers, -- Ivan Vilata i Balaguer -- https://elvil.net/ -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] lxc and guest /proc/kcore access restriction
Quoting Fiedler Roman (roman.fied...@ait.ac.at): Hello List, I have problems finding information about lxc with system virtualization and access restriction to /proc/kcore. In my setup, root in guest can read /proc/kcore, data from host shows up in container kcore, so kcore is not somehow faked/virtualized. I did not find no suitable information about securing /proc use inside container, so perhaps someone could point me to information to these questions? * Is secure /proc use (no escape, no major host/container or inter-container info leaks) inside guest possible? ATM I recommend you use an LSM to do that. -serge -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] seeing a network pause when starting and stopping LXCs - how do I stop this ?
I always hate replying to my own posts but I have stumbled onto some interesting clarification as I've continued to play with this... Below in-line. On Tue, 2011-12-13 at 01:30 -0500, Michael H. Warfield wrote: On Mon, 2011-12-12 at 08:43 +0100, Ulli Horlacher wrote: On Sun 2011-12-11 (19:48), Derek Simkowiak wrote: The problem is not related to the setfd option. It is caused by the bridge acquired a new MAC address. Libvirt already has a fix for this, and there is a patch in the works for the LXC tools. I am wonder why I do not have this problem: I really often start new containers and I do not have this patch, but no network freeze at all. Look to your MAC addresses. If the MAC address of the new container is greater than the MAC address of the bridge, you will never see this problem. If it's less than the bridge MAC address, the MAC address will change and, if you have any active network traffic, you WILL see this problem. The problem is old and related to a design decision wrt the bridges in the Linux kernel. I don't really agree with where the decision went but I understand the problem and their concerns (IIRC). The problem is the bridge NEEDS a MAC address but has no intrinsic address. So, they started out by assigning the MAC address of the first device assigned to the bridge. That worked but had a problem. The bridge is an independent autonomous object within the kernel and must be independent of the connected devices. Sooo, what happens to the MAC address if you delete that device from the bridge? It can't stay the same. Now, my memory is very fuzzy after about a decade (and Google searches are NOT helping my research) and anyone is welcome to correct me if I recall incorrect but... The arbitrary decision was made to always use the lowest MAC address on the bridge. The trouble is that they did that when they added devices. The problem really only occurs when you delete devices and, even then, only when the MAC of the bridge matches the MAC of the device being deleted and there is no other device with that MAC address (multihomed SPARCs) on that bridge. I would have chosen differently but this was not my shot to call and I didn't have any strong arguments to even insert into the discussion. They chose to always use the lowest MAC address. The choice was arbitrary but a choice had to be made. No choice was a non-starter and all choices had some downside to them. There are actually TWO solutions to this problem. The first one people have already glommed onto. You have to set your MAC address of your containers to be greater than the MAC address of the bridge. Problems there are that 1) we don't have our own vendor code and 2) we have to make sure we're higher than ANY vendor code and 3) the locally administered bit is NOT the highest order bit in the MAC address (that really would have made it too easy to fix but that's and even more ancient bad choice). The good point is that we CAN auto assign anything we WANT as long as that locally administered bit is set and we can then set the vendor code as high as we want. THAT works. Use FF:FF:F2:: and you are gold. Play with the remaining bits all you want. There is another. When creating the bridge, assign it a MAC address that's very LOW. You can do that with ifconfig or ip. It doesn't HAVE to have a MAC address that matches ANY interface attached to it. That's a misconception. It merely has to HAVE a MAC address. The problem with this solution is that technically that MAC address is then locally administered so the locally administered bit SHOULD be set (00:02::) but then anything of the vendor codes from 00:00:00:: through 00:00:ff:: would be less than that (00:01:: is the multicast bit). Grrr... But it's only 256 old vendors. Using 00:00:00:: for the vendor code works and is sooo unlikely to conflict with Xerox Corporation (vendor code 00:00:00) or their Ethernet cards (I know I'll get HATE MAIL from purists on THAT comment) that it's really NOT worth worrying about. According to this post, I may be mistaken that it doesn't have to be an address of a connected interface. http://backreference.org/2010/07/28/linux-bridge-mac-addresses-and-dynamic-ports/ In my testing I've certainly found that it does NOT have to be a MAC of a connected interface for IPv6 to work. My results for IPv4 have been mixed where, in one case, it did not and, in another case, it did. IPv6 worked in both cases but there are some peculiar filtering paths down in the kernel bridging logic that could well be coming into play here. It may also have to do with the MAC address detection logic and spanning tree algorithms. So be cautious there. But there was this remark: -- Fortunately, there is a way to ensure that the bridge's MAC address is fixed and never changes, thus entirely avoiding the problem. Thanks to this thread
