OpenVZ Forum - RDF feed
type: channel
items: VPS not isolated
items: Re: VPS not isolated
items: Re: Re: VPS not isolated

VPS not isolated
type: item
description: Hello! I've encountered a rather strange behaviour of OpenVZ: The host is a Debian Sarge system running a vanilla 2.6.18 kernel that I've patched with patch-ovz028test010.1-combined. The guest system is a minimal Debian Sarge image, the config file is below. When I vzctl start the VPS, I had expected that the VPS is started in the background and the command then returns to the shell, but that's not what happens: Instead I am logged out from the console I just used, I see messages from init, just like they appear on boot ("starting sshd... done, starting inetd... done", and so on) and finally get another login prompt for the HN. When I then vzctl enter the VPS (which sometimes fails with the error "cannot open PTY") and do a "ps aux", I see all processes from the HN, not only those of the VPS. When I vzctl stop the VPS, I again see messages from init which end in "sending KILL signal to all processes" -- and then the machine freezes. Examining the syslog is not very enlightening, but there are a few totally garbled entries like this Jan 19 15:22:29 amun2 kernel: 2: I6 rours esent (I think that was supposed read "no IPv6 routers present") The same guest image and vz-configuration work fine on another machine (which is Debian Testing instead of Sarge, and runs a Debian kernel instead of a vanilla one). To me, the whole thing looks like the VPS is not properly isolated from the HN, and its init somehow instead is started on the HN or something. But that's of course just a guess. I am rather stumped on how to debug this issue and would greatly appreciate any help. Thanks very much, Wolfgang # VPS config file, based on ve-vps.basic.conf-sample ONBOOT="no" # UBC parameters (in form of barrier:limit) # Primary parameters AVNUMPROC="40:40" NUMPROC="65:65" NUMTCPSOCK="80:80" NUMOTHERSOCK="80:80" VMGUARPAGES="6144:2147483647" # Secondary parameters KMEMSIZE="2752512:2936012" TCPSNDBUF="319488:524288" TCPRCVBUF="319488:524288" OTHERSOCKBUF="132096:336896" DGRAMRCVBUF="132096:13…
creator: Wolfgang Schnerring
date: 2007-01-20T07:32:08-00:00

Re: VPS not isolated
type: item
description: Hi Wolfgang, Wolfgang Schnerring wrote: > Hello! > > I've encountered a rather strange behaviour of OpenVZ: > The host is a Debian Sarge system running a vanilla 2.6.18 kernel that > I've patched with patch-ovz028test010.1-combined. The guest system is > a minimal Debian Sarge image, the config file is below. > > When I vzctl start the VPS, I had expected that the VPS is started in > the background and the command then returns to the shell, but that's > not what happens: Instead I am logged out from the console I just > used, I see messages from init, just like they appear on boot > ("starting sshd... done, starting inetd... done", and so on) and > finally get another login prompt for the HN. > When I then vzctl enter the VPS (which sometimes fails with the error > "cannot open PTY") and do a "ps aux", I see all processes from the HN, > not only those of the VPS. > When I vzctl stop the VPS, I again see messages from init which end in > "sending KILL signal to all processes" -- and then the machine > freezes. > Examining the syslog is not very enlightening, but there are a few > totally garbled entries like this > Jan 19 15:22:29 amun2 kernel: 2: I6 rours esent > (I think that was supposed read "no IPv6 routers present") > > The same guest image and vz-configuration work fine on another machine > (which is Debian Testing instead of Sarge, and runs a Debian kernel > instead of a vanilla one). > To me, the whole thing looks like the VPS is not properly isolated > from the HN, and its init somehow instead is started on the HN or > something. But that's of course just a guess. > > I am rather stumped on how to debug this issue and would greatly > appreciate any help. > > Thanks very much, > Wolfgang > > > # VPS config file, based on ve-vps.basic.conf-sample > ONBOOT="no" > > # UBC parameters (in form of barrier:limit) > # Primary parameters > AVNUMPROC="40:40" > NUMPROC="65:65" > NUMTCPSOCK="80:80" > NUMOTHERSOCK="80:80" > VMGUARPAGES="6144:2147483647" > # Secondary par…
creator: Thorsten Schifferdeck[1]
date: 2007-01-20T11:28:32-00:00

Re: VPS not isolated
type: item
description: * Thorsten Schifferdecker <ts@systs.org>: > Wolfgang Schnerring wrote: >> I've encountered a rather strange behaviour of OpenVZ: >> The host is a Debian Sarge system running a vanilla 2.6.18 kernel that >> I've patched with patch-ovz028test010.1-combined. The guest system is >> a minimal Debian Sarge image, the config file is below. >> >> When I vzctl start the VPS, I had expected that the VPS is started in >> the background and the command then returns to the shell, but that's >> not what happens: Instead I am logged out from the console I just >> used, I see messages from init, just like they appear on boot >> ("starting sshd... done, starting inetd... done", and so on) and >> finally get another login prompt for the HN. > > Did you self-create your debian-sarge os-template ? Yes, I've created that template myself. And "unfortunately" it works perfectly fine on another machine. I've just tried to use a precreated Sarge template (from http://download.openvz.org/template/precreated/debian-3.1-i3 86-minimal.tar.gz) but it shows the exact same behaviour. > Still exist in this ve some tty dev-files (ls -l > /vm/vm25710/private/dev/tty*) Yes, there are lots of tty dev-files in the template. Could that be a problem? As an experiment, I've removed them, but this did not change the behaviour at all. > Can you execute a ps in your VE, like > # vzctl exec <VEID> ps axf > and only the VE process are shown ? No, this shows all processes. I'm grateful for any hints on how to debug this issue. Thanks, Wolfgang
creator: Wolfgang Schnerring
date: 2007-01-22T09:11:28-00:00

Re: Re: VPS not isolated
type: item
description: Wolfgang Schnerring wrote: >> Can you execute a ps in your VE, like >> # vzctl exec <VEID> ps axf >> and only the VE process are shown ? >> > > No, this shows all processes. > The only reason I know why it could happen is if somebody mounted VE's /proc from the host system. Try to do the following: umount /path/to/VEroot/proc [usually it is /vz/root/VEID/proc] vzctl exec VEID mount /proc and see what the following command will show you vzctl exec VEID ps ax
creator: kir
date: 2007-01-22T11:19:05-00:00

Re: VPS not isolated
type: item
description: * Kir Kolyshkin <kir@openvz.org>: > Wolfgang Schnerring wrote: >>> Can you execute a ps in your VE, like >>> # vzctl exec <VEID> ps axf >>> and only the VE process are shown ? >> >> No, this shows all processes. >> > The only reason I know why it could happen is if somebody mounted VE's /proc > from the host system. I don't actually understand what's going on, but the reason for this odd behaviour is that the VPS private area was lying on an NFS-mount. I don't know whether that should work or whether that's a known issue, anyways it doesn't work, and it fails in colorful ways, as I've described. I've now moved the private area to a "real" disk, and everything's fine. Thanks, Wolfgang
creator: Wolfgang Schnerring
date: 2007-01-23T15:58:16-00:00

Re: Re: VPS not isolated
type: item
description: Wolfgang, > I don't actually understand what's going on, but the reason for this odd > behaviour is that the VPS private area was lying on an NFS-mount. > I don't know whether that should work or whether that's a known issue, anyways > it doesn't work, and it fails in colorful ways, as I've described. > I've now moved the private area to a "real" disk, and everything's fine. Ouch, this is a good important piece of additional information! Can you please post a bug in bugzilla with this information, or even better provide an access (via private email) for onsite quick debug/resolving? Thanks, Kirill
creator: dev
date: 2007-01-23T16:07:59-00:00

Re: VPS not isolated
type: item
description: * Kirill Korotaev <dev@sw.ru>: >> I don't actually understand what's going on, but the reason for this odd >> behaviour is that the VPS private area was lying on an NFS-mount. >> I don't know whether that should work or whether that's a known issue, anyways >> it doesn't work, and it fails in colorful ways, as I've described. >> I've now moved the private area to a "real" disk, and everything's fine. > Ouch, this is a good important piece of additional information! > Can you please post a bug in bugzilla with this information, Sure, it's http://bugzilla.openvz.org/show_bug.cgi?id=456 > or even better provide an access (via private email) > for onsite quick debug/resolving? I'm afraid that won't be possible, those are university machines and the regulations are strict. But it is easy to reproduce, just do a NFS mount of the private area from localhost to localhost. Wolfgang
creator: Wolfgang Schnerring
date: 2007-01-24T09:41:05-00:00

Re: Re: VPS not isolated
type: item
description: >>>I don't actually understand what's going on, but the reason for this odd >>>behaviour is that the VPS private area was lying on an NFS-mount. >>>I don't know whether that should work or whether that's a known issue, anyways >>>it doesn't work, and it fails in colorful ways, as I've described. >>>I've now moved the private area to a "real" disk, and everything's fine. >> >>Ouch, this is a good important piece of additional information! >>Can you please post a bug in bugzilla with this information, > > > Sure, it's http://bugzilla.openvz.org/show_bug.cgi?id=456 > > >>or even better provide an access (via private email) >>for onsite quick debug/resolving? > > > I'm afraid that won't be possible, those are university machines and the > regulations are strict. But it is easy to reproduce, just do a NFS mount of the > private area from localhost to localhost. ok. let's communicate through the bugzilla for better tracking. I proposed you to try the same w/o vzquota. Thanks, Kirill
creator: dev
date: 2007-01-24T09:51:29-00:00