[Vserver] Re: [Devel] Container Test Campaign
Clement, Thanks for sharing the results! A few comments... (1) General 1.1 It would be nice to run vmstat (say, vmstat 10) for the duration of the tests, and put the vmstat output logs to the site. 1.2 Can you tell how you run the tests. I am particularly interested in - how many iterations do you do? - what result do you choose from those iterations? - how reproducible are the results? - are you rebooting the box between the iterations? - are you reformatting the partition used for filesystem testing? - what settings are you using (such as kernel vm params)? - did you stop cron daemons before running the test? - are you using the same test binaries across all the participants? - etc. etc... Basically, the detailed description of a process would be nice to have, in order to catch possible problems. There are a lot of tiny things which are influencing the results. For example, in linux kernels 2.4 binding the NIC IRQ to a single CPU on an SMP system boosts network performance by about 15%! Sure this is not relevant here, it's just an example. 1.3 Would be nice to have diffs between different kernel configs. (2) OpenVZ specifics 2.1 Concerning the tests running inside an OpenVZ VE, the problem is there is a (default) set of resource limits applied to each VE. Basically one should tailor those limits to suit the applications running, OR, for the purpose of testing, just set those limits to some very high values so they will never be reached. For example, the tbench test is probably failed to finish because it hits the limits for privvmpages, tcpsndbuf and tcprcvbuf. I have increased the limits for those parameters and the test was finished successfully. Also, dbench test could hit the disk quota limit for a VE. Some more info is available at http://wiki.openvz.org/Resource_management 2.2 For OpenVZ specifically, it would be nice to collect /proc/user_beancounters output before and after the test. Clément Calmels wrote: Hi, A first round about virtualisation benchmarks can be found here: http://lxc.sourceforge.net/bench/ These benchmarks run with vanilla kernels and the patched versions of well know virtualisation solutions: VServer and OpenVZ. Some benchs also run inside the virtual 'guest' but we ran into trouble trying to run some of them... probably virtual 'guest' configuration issues... we will trying to fix them... The metacluster migration solution (formely a Meiosys company produt) was added as it seems that the checkpoint/restart topic is close to the virtualisation's one (OpenVZ now provides a checkpoint/restart capability). For the moment, benchmarks only ran on xeon platform but we expect more architecture soon. Besides the 'classic' benchs used, more network oriented benchs will be added. Netpipe between two virtual 'guests' for example. We hope we will be able to provide results concerning the virtual 'guest' scalability, running several 'guest' at the same time. Best regards, Le mercredi 07 juin 2006 à 16:20 +0200, Clement Calmels a écrit : Hello ! I'm part of a team of IBMers working on lightweight containers and we are going to start a new test campaign. Candidates are vserver, vserver context, namespaces (being pushed upstream), openvz, mcr (our simple container dedicated to migration) and eventually xen. We will focus on the performance overhead but we are also interested in checkpoint/restart and live migration. A last topic would be how well the resource managment criteria are met, but that's extra for the moment. We plan on measuring performance overhead by comparing the results on a vanilla kernel with a partial and with a complete virtual environment. By partial, we mean the patched kernel and a 'namespace' virtualisation. Test tools -- o For network performance : * netpipe (http://www.scl.ameslab.gov/netpipe/) * netperf (http://www.netperf.org/netperf/NetperfPage.html) * tbench (http://samba.org/ftp/tridge/dbench/README) o Filesystem : * dbench (http://samba.org/ftp/tridge/dbench/README) * iozone (http://www.iozone.org/) o General * kernbench (http://ck.kolivas.org/kernbench/) stress cpu and filesystem through kernel compilation * More 'real world' application could be used, feel free to submit candidates... We have experience on C/R and migration so we'll start with our own scenario, migrating oracle under load. The load is generated by DOTS (http://ltp.sourceforge.net/dotshowWe ran into trouble trying to run sto.php). If you could provided us some material on what has already been done : URL, bench tools, scenarios. We'll try to compile them in. configuration hints and tuning are most welcome if they are reasonable. Results, tools, scenarios will be published on lxc.sf.net . We will set up the testing environment so as to be able to accept new versions, patches, test tools and rerun the all on demand. Results, tools, scenarios will be published on lxc.sf.net. thanks ! Clement,
Re: [Vserver] can't start a rembo server
Herbert Poetzl wrote:
On Fri, Jun 30, 2006 at 01:12:50PM +0200, dmanye wrote:
hi,
i've a debian etch host with kernel 2.6.16-2-vserver-686 original from
debian. util-vserver version is 0.30.210-10 original from debian also.
i've created some vservers (debian sarge) with no problems but now i
want to build a rembo [v]server on a debian sarge guest. rembo is a
comercial/closed-source (sorry) pxe server from www.rembo.com. all went
fine until i tried to start the daemon:
# ./rembo
Rembo Server 2.0 Toolkit (build 058.2)
(c) 1999-2003 Rembo Technology SaRL, Geneva, Switzerland
Error on interface 10.20.102.239
# strace ./rembo -d 21 | tail -n 25
open(./rembo, O_RDONLY) = 3
lseek(3, 0, SEEK_END) = 1238692
lseek(3, 0, SEEK_SET) = 0
mmap2(NULL, 1241088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7cd6000
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\0\241\4...,
1238692) = 1238692
open(rembo.conf, O_RDONLY)= 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=91, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f87000
fstat64(4, {st_mode=S_IFREG|0644, st_size=91, ...}) = 0
_llseek(4, 0, [0], SEEK_SET)= 0
read(4, \nBaseDir \/rembo\\n ..., 91) = 91
_llseek(4, 91, [91], SEEK_SET) = 0
close(4)= 0
munmap(0xb7f87000, 4096)= 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
bind(4, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr(127.0.0.1)}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(33007),
it looks like it is looking up 'lo' inside the guest,
you might try to add 127.0.0.1 as a separate 'nodev'
entry to the guest, or to disable the hide_netif flag
this is what i have on the host:
# cd /etc/vservers/alf/interfaces/
mosques:/etc/vservers/alf/interfaces# ls
0 1
mosques:/etc/vservers/alf/interfaces# ls 1/
dev ip mask nodev
mosques:/etc/vservers/alf/interfaces# cat 1/*
lo
127.0.0.1
8
i can ping localhost and 127.0.0.1 inside the vserver but this does not
work: the rembo daemon does not start. also, i've added CAP_NET_ADMIN
and got the same result.
what i think may bring some light is the following:
if i try to execute the server (it is statically linked) on the host it
works!
so i've compared the output of strace and i get:
alf (vserver):
...
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
bind(4, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr(127.0.0.1)}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(33018),
sin_addr=inet_addr(10.20.102.239)}, [16]) = 0
futex(0xb7f5b1f0, FUTEX_WAKE, 2147483647) = 0
write(2, Error on interface 10.20.102.239..., 33Error on interface
10.20.102.239
and it dies.
mosques(host):
...
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
bind(4, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr(127.0.0.1)}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(33018),
sin_addr=inet_addr(127.0.0.1)}, [16]) = 0
close(4) = 0
uname({sys=Linux, node=mosques, ...}) = 0
... and continue ahead.
after the 'bind' call, why does alf execute a getsockname with
10.20.102.239 (just before die) while mosques pass 127.0.0.1 and
continues successfully? is it due to chbind?
once more is clear that not having the source code is like selling your
soul, but we have no other viable alternative.
sin_addr=inet_addr(10.20.102.239)}, [16]) = 0
futex(0xb7f3a1f0, FUTEX_WAKE, 2147483647) = 0
write(2, Error on interface 10.20.102.239..., 33Error on interface
10.20.102.239) = 33
write(1, Rembo Server 2.0 Toolkit (build ..., 96Rembo Server 2.0
Toolkit (build 058.2)
(c) 1999-2003 Rembo Technology SaRL, Geneva, Switzerland) = 96
munmap(0xb7f88000, 4096)= 0
exit_group(0) = ?
i've have a couple of non-vserver servers with sarge+rembo running
perfectly so i think is a rembo-vserver compatibility issue.
you might also try to 'change' the configuration of
that pxe server to _not_ use 127.0.0.1 (and use localhost
or the first assigned ip instead)
don't know why that code looks for 127.0.0.1. on the other 'real' rembo
servers i have there's nothing in the config about the 'lo' interface.
the vserver has a couple of bcapabilities in order to run also a dhcp
server: CAP_NET_RAW and CAP_NET_BROADCAST.
CAP_NET_BROADCAST is not used, so it's unlikely you need
that one ... but it doesn't hurt either :)
i need it because i run a dhcpd server on the same vserser (as i do in
the 'real' other rembo servers).
thanks in advance.
HTH,
Herbert
begin:vcard
fn;quoted-printable:david many=C3=A9
n;quoted-printable:many=C3=A9;david
org;quoted-printable:Universitat Rovira i Virgili;Departament d'Enginyeria
Inform=C3=A0tica i Matem=C3=A0tiques
adr;quoted-printable;dom:;;Av. dels Pa=C3=AFsos Catalans, 26;Tarragona;;43007
email;internet:[EMAIL PROTECTED]
[Vserver] linux-vserver patch 2.0.x for kernel 2.6.16
Dear Herbert, Is it possible to maintain a linux-vserver patch for the kernel 2.6.16.x series? - kernel 2.6.16 is the kernel used by some large distributions for there next release (fedora and suse ?) - kernel 2.6.16 did receive a large number of fixes. Some people will use it as there stable kernel for the next months. (they will skip 2.6.17) The vserver-2.0.2-rcXX patches have some very nice fixes. It would be nice to have a 2.6.16.x-vs2.0.2 patch in the near future. Thanks, Bert. ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] linux-vserver patch 2.0.x for kernel 2.6.16
dag gentse collega!, ik ben van plan de 2.6.16.22 patch te maken met de laatste rc van vserver (en de laatste grsec). deze zal je altijd kunnen vinden op : http://ludit.kuleuven.be/software/vserver/ natuurlijk moeot je zelf kiezen of je grsec wilt enablen of niet :) groeten, Bert De Vuyst wrote: Dear Herbert, Is it possible to maintain a linux-vserver patch for the kernel 2.6.16.x series? - kernel 2.6.16 is the kernel used by some large distributions for there next release (fedora and suse ?) - kernel 2.6.16 did receive a large number of fixes. Some people will use it as there stable kernel for the next months. (they will skip 2.6.17) The vserver-2.0.2-rcXX patches have some very nice fixes. It would be nice to have a 2.6.16.x-vs2.0.2 patch in the near future. Thanks, Bert. ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver -- harry aka Rik Bobbaers K.U.Leuven - LUDIT -=- Tel: +32 485 52 71 50 [EMAIL PROTECTED] -=- http://harry.ulyssis.org Work hard and do your best, it'll make it easier for the rest -- Garfield Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] linux-vserver patch 2.0.x for kernel 2.6.16
sorry guys, this was supposed to be to Bert only, that's why it was in dutch... just ignore :) Rik Bobbaers wrote: dag gentse collega!, ik ben van plan de 2.6.16.22 patch te maken met de laatste rc van vserver (en de laatste grsec). deze zal je altijd kunnen vinden op : http://ludit.kuleuven.be/software/vserver/ natuurlijk moeot je zelf kiezen of je grsec wilt enablen of niet :) -- harry aka Rik Bobbaers K.U.Leuven - LUDIT -=- Tel: +32 485 52 71 50 [EMAIL PROTECTED] -=- http://harry.ulyssis.org Work hard and do your best, it'll make it easier for the rest -- Garfield Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] linux-vserver patch 2.0.x for kernel 2.6.16
Hi there, on Monday, July 3, 2006 at 11:27:32 AM there was posted: BDV Is it possible to maintain a linux-vserver patch for the kernel BDV 2.6.16.x series? BDV - kernel 2.6.16 is the kernel used by some large distributions BDV for there next release (fedora and suse ?) kernel-2.6.16-1.2132_FC5.vs2.0.2.0.rc22.1 for example (Daniels Fedora patched kernel) is considered reasonable stable - so if you want to stay with 2.6.16, you could use this. BDV - kernel 2.6.16 did receive a large number of fixes. Some people BDV will use it as there stable kernel for the next months. (they BDV will skip 2.6.17) 2.6.17 with VServer patches is getting support through Daniel (code) and me (testing / using in two different production environments and one local server which is used mainly for production and only a little for testing) on Fedora, so this can also be consider stable as soon as it is announced on the mailing list - so there's the main question: Why should it be skipped? BDV The vserver-2.0.2-rcXX patches have some very nice fixes. It BDV would be nice to have a 2.6.16.x-vs2.0.2 patch in the near future. For Fedora: What specially do you have in rc24 which is not existent in rc22 (2.6.16 kernel)? ;-) And though: Yes, it would be nice to have a stable (rc's are already quite stable though) 2.0.2 release for 2.6.16 as well, I'm with you. -- regards 'n greez, Guenther Fuchs (aka muh and powerfox) ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] can't terminate OpenVPN tunnel within a vserver?
Setting up openvpn (2.0-1sarge3) ... /bin/mknod: `/dev/net/tun': Operation not permitted I can't have an OpenVPN tunnel terminate in a vserver, can I? -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] can't terminate OpenVPN tunnel within a vserver?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Eugen, Setting up openvpn (2.0-1sarge3) ... /bin/mknod: `/dev/net/tun': Operation not permitted I can't have an OpenVPN tunnel terminate in a vserver, can I? I'm not sure about the exact answer - the error you've got is because you don't have the capability to create devices - there's some information about OpenVPN in Vservers in the following page, maybe that helps: http://linux-vserver.org/some_hints_from_john (Search for openvpn in that page) Baltasar ((( Baltasar Cevc ) World wide web: * http://www.openairkino.net/ (a project for the local youth; German only) * http://technik.juz-kirchheim.de/ (programming and admin projects) * http://baltasar.cevc-topp.de/ (private homepage) ) Phone: +49 176 232 20 822 ) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) iD8DBQFEqO2Zp2YsmzTbIwYRAvI4AKCjuPlUDUc7C3CgBIOW4MqjqLAg/QCfQqMB xok/TPBPPuGXL2aZk08VyoM= =rKKd -END PGP SIGNATURE- ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] linux-vserver patch 2.0.x for kernel 2.6.16
Bert De Vuyst wrote: Dear Herbert, Is it possible to maintain a linux-vserver patch for the kernel 2.6.16.x series? As of right now, the few changes between the last 2.6.16 patch (-rc22) and current (-rc24) were mostly related to the move to a 2.6.17 base kernel. - kernel 2.6.16 is the kernel used by some large distributions for there next release (fedora and suse ?) Fedora is already using 2.6.17 for their current releases, I guess you meant RHEL. -- Daniel Hokka Zakrisson GPG id: 06723412 GPG fingerprint: A455 4DF3 990A 431F FECA 7947 6136 DDA2 0672 3412 ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] can't start a rembo server (solved)
i've created a new vserver and defined (at creation time) interfaces
'eth0' and 'lo'. now the rembo daemon works ok. beautiful.
dmanye wrote:
Herbert Poetzl wrote:
On Fri, Jun 30, 2006 at 01:12:50PM +0200, dmanye wrote:
hi,
i've a debian etch host with kernel 2.6.16-2-vserver-686 original
from debian. util-vserver version is 0.30.210-10 original from
debian also.
i've created some vservers (debian sarge) with no problems but now i
want to build a rembo [v]server on a debian sarge guest. rembo is a
comercial/closed-source (sorry) pxe server from www.rembo.com. all
went fine until i tried to start the daemon:
# ./rembo Rembo Server 2.0 Toolkit (build 058.2)
(c) 1999-2003 Rembo Technology SaRL, Geneva, Switzerland
Error on interface 10.20.102.239
# strace ./rembo -d 21 | tail -n 25
open(./rembo, O_RDONLY) = 3
lseek(3, 0, SEEK_END) = 1238692
lseek(3, 0, SEEK_SET) = 0
mmap2(NULL, 1241088, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7cd6000
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\0\241\4...,
1238692) = 1238692
open(rembo.conf, O_RDONLY)= 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=91, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7f87000
fstat64(4, {st_mode=S_IFREG|0644, st_size=91, ...}) = 0
_llseek(4, 0, [0], SEEK_SET)= 0
read(4, \nBaseDir \/rembo\\n ..., 91) = 91
_llseek(4, 91, [91], SEEK_SET) = 0
close(4)= 0
munmap(0xb7f87000, 4096)= 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
bind(4, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr(127.0.0.1)}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(33007),
it looks like it is looking up 'lo' inside the guest,
you might try to add 127.0.0.1 as a separate 'nodev'
entry to the guest, or to disable the hide_netif flag
this is what i have on the host:
# cd /etc/vservers/alf/interfaces/
mosques:/etc/vservers/alf/interfaces# ls
0 1
mosques:/etc/vservers/alf/interfaces# ls 1/
dev ip mask nodev
mosques:/etc/vservers/alf/interfaces# cat 1/*
lo
127.0.0.1
8
i can ping localhost and 127.0.0.1 inside the vserver but this does
not work: the rembo daemon does not start. also, i've added
CAP_NET_ADMIN and got the same result.
what i think may bring some light is the following:
if i try to execute the server (it is statically linked) on the host
it works!
so i've compared the output of strace and i get:
alf (vserver):
...
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
bind(4, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr(127.0.0.1)}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(33018),
sin_addr=inet_addr(10.20.102.239)}, [16]) = 0
futex(0xb7f5b1f0, FUTEX_WAKE, 2147483647) = 0
write(2, Error on interface 10.20.102.239..., 33Error on interface
10.20.102.239
and it dies.
mosques(host):
...
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
bind(4, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr(127.0.0.1)}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(33018),
sin_addr=inet_addr(127.0.0.1)}, [16]) = 0
close(4) = 0
uname({sys=Linux, node=mosques, ...}) = 0
... and continue ahead.
after the 'bind' call, why does alf execute a getsockname with
10.20.102.239 (just before die) while mosques pass 127.0.0.1 and
continues successfully? is it due to chbind?
once more is clear that not having the source code is like selling
your soul, but we have no other viable alternative.
sin_addr=inet_addr(10.20.102.239)}, [16]) = 0
futex(0xb7f3a1f0, FUTEX_WAKE, 2147483647) = 0
write(2, Error on interface 10.20.102.239..., 33Error on interface
10.20.102.239) = 33
write(1, Rembo Server 2.0 Toolkit (build ..., 96Rembo Server 2.0
Toolkit (build 058.2)
(c) 1999-2003 Rembo Technology SaRL, Geneva, Switzerland) = 96
munmap(0xb7f88000, 4096)= 0
exit_group(0) = ?
i've have a couple of non-vserver servers with sarge+rembo running
perfectly so i think is a rembo-vserver compatibility issue.
you might also try to 'change' the configuration of
that pxe server to _not_ use 127.0.0.1 (and use localhost
or the first assigned ip instead)
don't know why that code looks for 127.0.0.1. on the other 'real'
rembo servers i have there's nothing in the config about the 'lo'
interface.
the vserver has a couple of bcapabilities in order to run also a
dhcp server: CAP_NET_RAW and CAP_NET_BROADCAST.
CAP_NET_BROADCAST is not used, so it's unlikely you need
that one ... but it doesn't hurt either :)
i need it because i run a dhcpd server on the same vserser (as i do in
the 'real' other rembo servers).
thanks in advance.
HTH,
Herbert
begin:vcard
fn;quoted-printable:david many=C3=A9
n;quoted-printable:many=C3=A9;david
org;quoted-printable:Universitat Rovira i Virgili;Departament
d'Enginyeria Inform=C3=A0tica
Re: [Vserver] can't terminate OpenVPN tunnel within a vserver?
On Mon, Jul 03, 2006 at 12:12:34PM +0200, Baltasar Cevc wrote: I can't have an OpenVPN tunnel terminate in a vserver, can I? I'm not sure about the exact answer - the error you've got is because you don't have the capability to create devices - there's some information about OpenVPN in Vservers in the following page, maybe that helps: http://linux-vserver.org/some_hints_from_john (Search for openvpn in that page) Thanks, Baltasar. Followed the procedure, but can't get a pingable IP. /etc/openvpn/openvpn-status.log remains empty. -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] linux-vserver patch 2.0.x for kernel 2.6.16
On Monday 03 July 2006 12:41, Daniel Hokka Zakrisson wrote: Bert De Vuyst wrote: Dear Herbert, Is it possible to maintain a linux-vserver patch for the kernel 2.6.16.x series? As of right now, the few changes between the last 2.6.16 patch (-rc22) and current (-rc24) were mostly related to the move to a 2.6.17 base kernel. OK. - kernel 2.6.16 is the kernel used by some large distributions for there next release (fedora and suse ?) Fedora is already using 2.6.17 for their current releases, I guess you meant RHEL. Yes. Bert ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] localhost oddity on vserver host
Herbert, This problem is on the *host*, not a guest. I've verified that none of the guests on vhost3 (the box with the problem) has anything to do with 127.0.0.1. Also, on vhost3, sshd with explicit "ListenAddress" settings for the host's ip as well as 127.0.0.1 will start and run without complaining that it cannot bind to 127.0.0.1, but netstat doesn't show it listening on localhost. For the life of me, I cant figure this out ... On vhost1 (the working box): [EMAIL PROTECTED] ~]# ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.039 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.018 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.033 ms --- 127.0.0.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2010ms rtt min/avg/max/mdev = 0.018/0.030/0.039/0.008 ms, pipe 2 On vhost3 (the troublesome box): [EMAIL PROTECTED] etc]# ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. hit cntrl-C here --- 127.0.0.1 ping statistics --- 6 packets transmitted, 0 received, 100% packet loss, time 4999ms Any thoughts? Paul Herbert Poetzl wrote: On Fri, Jun 30, 2006 at 08:51:58PM -0400, Paul S. Gumerman wrote: In it's own thread now -- sorry for the unintentional hijack. I have two practically identical vserver hosts, named vhost1 and vhost3. They are both running kernel CentOS (2.6.14.3-vs2.0.1-rc5) x86_64. /etc/hosts on each one is essentially the same, and the routes look good and essentially the same. The ifconfig output for both looks the same, and both show traffic in and out of lo. this suggests that you 'assigned' some loopback ip (probably 127.0.0.1) to both guests, which will them allow to bind to that ip too this very likely results in two guests competing for that address, so some services will be able to bind others will fail ... On vhost1, "ping 127.0.0.1" works as expected, and sshd can listen on the localhost port 22, and can be used there (by freenx). On vhost3, "ping 127.0.0.1" *sends* packets, but shows 100% packet loss. Also, sshd does not complain about listening on localhost, but it doesn't show up in netstat's output, and it doesn't work on localhost (freenx fails). Does anybody have any ideas? Unfortunately, vhost3 is a hundred miles away, and one of the virtual servers is running an important mail server, so I have to be careful. But vhost1 is here, and not so critical, so I can experiment with it. basically I do not see a good reason for assigning 127.x.x.x to a guest, but if you have to, then try to choose different ones, e.g. 127.0.0.2, 127.0.0.3 ... HTH, Herbert Thanks, Paul ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Re: linux-vserver patch 2.0.x for kernel 2.6.16
On Mon, Jul 03, 2006 at 11:27:32AM +0200, Bert De Vuyst wrote: Dear Herbert, Is it possible to maintain a linux-vserver patch for the kernel 2.6.16.x series? I think so, who is going to maintain it? - kernel 2.6.16 is the kernel used by some large distributions for there next release (fedora and suse ?) - kernel 2.6.16 did receive a large number of fixes. Some people will use it as there stable kernel for the next months. (they will skip 2.6.17) well, 2.6.17 should have all that fixes, no? The vserver-2.0.2-rcXX patches have some very nice fixes. It would be nice to have a 2.6.16.x-vs2.0.2 patch in the near future. if there is great demand and/or some good reason to do that, we will probably go that way ... best, Herbert Thanks, Bert. ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] can't start a rembo server
On Mon, Jul 03, 2006 at 11:11:02AM +0200, dmanye wrote:
Herbert Poetzl wrote:
On Fri, Jun 30, 2006 at 01:12:50PM +0200, dmanye wrote:
hi,
i've a debian etch host with kernel 2.6.16-2-vserver-686 original from
debian. util-vserver version is 0.30.210-10 original from debian also.
i've created some vservers (debian sarge) with no problems but now i
want to build a rembo [v]server on a debian sarge guest. rembo is a
comercial/closed-source (sorry) pxe server from www.rembo.com. all went
fine until i tried to start the daemon:
# ./rembo
Rembo Server 2.0 Toolkit (build 058.2)
(c) 1999-2003 Rembo Technology SaRL, Geneva, Switzerland
Error on interface 10.20.102.239
# strace ./rembo -d 21 | tail -n 25
open(./rembo, O_RDONLY) = 3
lseek(3, 0, SEEK_END) = 1238692
lseek(3, 0, SEEK_SET) = 0
mmap2(NULL, 1241088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7cd6000
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\0\241\4...,
1238692) = 1238692
open(rembo.conf, O_RDONLY)= 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=91, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f87000
fstat64(4, {st_mode=S_IFREG|0644, st_size=91, ...}) = 0
_llseek(4, 0, [0], SEEK_SET)= 0
read(4, \nBaseDir \/rembo\\n ..., 91) = 91
_llseek(4, 91, [91], SEEK_SET) = 0
close(4)= 0
munmap(0xb7f87000, 4096)= 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
bind(4, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr(127.0.0.1)}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(33007),
it looks like it is looking up 'lo' inside the guest,
you might try to add 127.0.0.1 as a separate 'nodev'
entry to the guest, or to disable the hide_netif flag
this is what i have on the host:
# cd /etc/vservers/alf/interfaces/
mosques:/etc/vservers/alf/interfaces# ls
0 1
mosques:/etc/vservers/alf/interfaces# ls 1/
dev ip mask nodev
mosques:/etc/vservers/alf/interfaces# cat 1/*
lo
127.0.0.1
8
~~~ looks like a 'prefix' to me, the mask would
be 255.0.0.0, no?
i can ping localhost and 127.0.0.1 inside the vserver but this
does not work: the rembo daemon does not start. also, i've added
CAP_NET_ADMIN and got the same result.
what i think may bring some light is the following:
if i try to execute the server (it is statically linked) on the host
it works!
so i've compared the output of strace and i get:
alf (vserver):
...
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
bind(4, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr(127.0.0.1)}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(33018),
sin_addr=inet_addr(10.20.102.239)}, [16]) = 0
futex(0xb7f5b1f0, FUTEX_WAKE, 2147483647) = 0
write(2, Error on interface 10.20.102.239..., 33Error on interface
10.20.102.239
and it dies.
mosques(host):
...
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
bind(4, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr(127.0.0.1)}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(33018),
sin_addr=inet_addr(127.0.0.1)}, [16]) = 0
close(4) = 0
uname({sys=Linux, node=mosques, ...}) = 0
... and continue ahead.
after the 'bind' call, why does alf execute a getsockname with
10.20.102.239 (just before die) while mosques pass 127.0.0.1 and
continues successfully? is it due to chbind?
probably, the src address rewriting does the expected
thing here, mapping 127.0.0.1 to the first assigned
ip of the guest ...
once more is clear that not having the source code is like selling
your soul, but we have no other viable alternative.
sin_addr=inet_addr(10.20.102.239)}, [16]) = 0
futex(0xb7f3a1f0, FUTEX_WAKE, 2147483647) = 0
write(2, Error on interface 10.20.102.239..., 33Error on interface
10.20.102.239) = 33
write(1, Rembo Server 2.0 Toolkit (build ..., 96Rembo Server 2.0
Toolkit (build 058.2)
(c) 1999-2003 Rembo Technology SaRL, Geneva, Switzerland) = 96
munmap(0xb7f88000, 4096)= 0
exit_group(0) = ?
i've have a couple of non-vserver servers with sarge+rembo running
perfectly so i think is a rembo-vserver compatibility issue.
you might also try to 'change' the configuration of
that pxe server to _not_ use 127.0.0.1 (and use localhost
or the first assigned ip instead)
don't know why that code looks for 127.0.0.1. on the other 'real'
rembo servers i have there's nothing in the config about the 'lo'
interface.
probably because folks there confused 'localhost'
with 127.0.0.1 and simply substituted ... a not
really uncommon lapse
the vserver has a couple of bcapabilities in order to run also a
dhcp server: CAP_NET_RAW and CAP_NET_BROADCAST.
CAP_NET_BROADCAST is not used, so it's unlikely you need
that one ... but it doesn't hurt either :)
i
Re: [Vserver] localhost oddity on vserver host
On Mon, Jul 03, 2006 at 10:35:44AM -0400, Paul S. Gumerman wrote: Herbert, This problem is on the *host*, not a guest. I've verified that none of the guests on vhost3 (the box with the problem) has anything to do with 127.0.0.1. Also, on vhost3, sshd with explicit ListenAddress settings for the host's ip as well as 127.0.0.1 will start and run without complaining that it cannot bind to 127.0.0.1, but netstat doesn't show it listening on localhost. For the life of me, I cant figure this out ... On vhost1 (the working box): [EMAIL PROTECTED] ~]# ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.039 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.018 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.033 ms --- 127.0.0.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2010ms rtt min/avg/max/mdev = 0.018/0.030/0.039/0.008 ms, pipe 2 On vhost3 (the troublesome box): [EMAIL PROTECTED] etc]# ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. hit cntrl-C here --- 127.0.0.1 ping statistics --- 6 packets transmitted, 0 received, 100% packet loss, time 4999ms Any thoughts? the following things come to my mind: - iptables/tc rules blocking 127.0.0.1 - special routing tables (with strange priorities) - loopback itnerface not properly configured - kernel bug (different kernel version) HTH, Herbert Paul Herbert Poetzl wrote: On Fri, Jun 30, 2006 at 08:51:58PM -0400, Paul S. Gumerman wrote: In it's own thread now -- sorry for the unintentional hijack. I have two practically identical vserver hosts, named vhost1 and vhost3. They are both running kernel CentOS (2.6.14.3-vs2.0.1-rc5) x86_64. /etc/hosts on each one is essentially the same, and the routes look good and essentially the same. The ifconfig output for both looks the same, and both show traffic in and out of lo. this suggests that you 'assigned' some loopback ip (probably 127.0.0.1) to both guests, which will them allow to bind to that ip too this very likely results in two guests competing for that address, so some services will be able to bind others will fail ... On vhost1, ping 127.0.0.1 works as expected, and sshd can listen on the localhost port 22, and can be used there (by freenx). On vhost3, ping 127.0.0.1 *sends* packets, but shows 100% packet loss. Also, sshd does not complain about listening on localhost, but it doesn't show up in netstat's output, and it doesn't work on localhost (freenx fails). Does anybody have any ideas? Unfortunately, vhost3 is a hundred miles away, and one of the virtual servers is running an important mail server, so I have to be careful. But vhost1 is here, and not so critical, so I can experiment with it. basically I do not see a good reason for assigning 127.x.x.x to a guest, but if you have to, then try to choose different ones, e.g. 127.0.0.2, 127.0.0.3 ... HTH, Herbert Thanks, Paul ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Stopping a 'noname' guest
Daniel Hokka Zakrisson wrote: Roderick A. Anderson wrote: While playing about I forgot to stop a vserver before deleting it. Homw I have this 'no-name' guest running and can't remember how to stop it other than rebooting the server ( which has worked on other/old vserver kernels ). vkill --xid xid -- -1 ought to do it, but if not, you could always vkill the processes in the context one by one. What a week-end. I tried several things and then I sent the message off and went to do 'other-stuff'. Came back, saw your message, logged in and the guest was gone! Not sure why or how that happened. Anyway thanks for the clue. After reading this I remembered the 'vkill' command from a similar problem many months ago. Rod -- ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] RE: [Devel] Container Test Campaign
Hi Kirill, Thanks for the feedback. Not sure whether you are referring to Clement's work or our paper. I'll assume you are referring to our paper. From what I see just just after 1 minute check of your results: DBench: - different disk I/O schedulers are compared. This makes comparison useless (not virtualization technologies are compared itself). Correct. As you can image, it is not easy to pick benchmarks. The intention was simply to repeat measurements presented by the Xen paper published in 2003 Symposium of Operating Sytems Principles, and show how Vserver compares on those. The point of the paper is to show how container based virtualization compares to hypervisor based systems. We do not have the time nor expertise to show this with OpenVZ. It would be great if someon from the openvz community could step in and show how OpenVZ compares to Xen. - the fact that there is too much difference between measurements (e.g. vserver makes linux faster :lol:) This is an interesting, odd, and likely laughable result. We just reported what we observed. It is quite possible that we made a mistake somewhere. However, I believe that the problem lies more with the dbench benchmark than with our setup. We did try to eliminate as many variables as possible. Please take a peek on the last page of the paper to see our discussion wrt normalizing the configurations. We are open to further suggestions to eliminate further variables. I also noticed that you do the measurements with different HZ settings. This influences the results as well... Of course. My assumption is that it would negatively affect Vserver. Are you suggesting that it can positively affect the benchmark results to run at 1000HZ vs. 100HZ, as the Xen Domains are configured to do? BTW, do you plan to do functional testing in addition to performance? Please clarify what you mean here? From what I gather, the main thing that Vserver lacks is the degree of network virtualization that OpenVZ supports. Is there anything else? From my perspective, the comparison will have to be with Xen/UML rather than, say, a contest between container based systems. I say this because it appears that the majority of the LKML community is believes that container-based systems don't add much above and beyond what Xen/UML/QEMU/VMware already offer today. Best regards, Marc -Original Message- From: Kirill Korotaev [mailto:[EMAIL PROTECTED] Sent: Monday, July 03, 2006 3:50 AM To: ? Calmels Cc: [EMAIL PROTECTED]; vserver@list.linux-vserver.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Devel] Container Test Campaign From what I see just just after 1 minute check of your results: DBench: - different disk I/O schedulers are compared. This makes comparison useless (not virtualization technologies are compared itself). - the fact that there is too much difference between measurements (e.g. vserver makes linux faster :lol:) makes me believe that you use large disk partiion, where data blocks allocation on the disk influence your results. To make these measurements correct the same partition with the size closest to the required max disk space should be used in all DBench tests. TBench: - when running inside VE, please, make sure, that /proc/user_beancounters doesn't show you resource allocation fails (failcnt column). Resource limits set by default can be just too small to finish your test case. And this doesn't mean your conclusion 'Concerning the results, obviously more isolation brings more overhead.'. I'm really suprised to see such statements. I also noticed that you do the measurements with different HZ settings. This influences the results as well... BTW, do you plan to do functional testing in addition to performance? Thanks, Kirill Hi, A first round about virtualisation benchmarks can be found here: http://lxc.sourceforge.net/bench/ These benchmarks run with vanilla kernels and the patched versions of well know virtualisation solutions: VServer and OpenVZ. Some benchs also run inside the virtual 'guest' but we ran into trouble trying to run some of them... probably virtual 'guest' configuration issues... we will trying to fix them... The metacluster migration solution (formely a Meiosys company produt) was added as it seems that the checkpoint/restart topic is close to the virtualisation's one (OpenVZ now provides a checkpoint/restart capability). For the moment, benchmarks only ran on xeon platform but we expect more architecture soon. Besides the 'classic' benchs used, more network oriented benchs will be added. Netpipe between two virtual 'guests' for example. We hope we will be able to provide results concerning the virtual 'guest' scalability, running several 'guest' at the same time. Best regards, Le mercredi 07 juin 2006
