Hardware: dual Opteron 242
Kernel: linux-2.6.18-openvz-028.049
Host OS: Gentoo
Guest OS: ubuntu-7.10-i386-minimal

Both host and VE are fresh installs.

I noticed that "vzctl stop 101" would fail with

Stopping VPS ...
Unable to stop VPS, operation timed out


This of course also prevented me from properly shutting down the system
(power off required).

I found a post [1] that seemed related, which led to investigating halt
commands:

vps1 ~ # vzctl enter 101
root@localhost:/# halt -p
shutdown: Unable to send message: Connection refused
root@localhost:/# halt
shutdown: Unable to send message: Connection refused 
root@localhost:/dev# halt -fp
got signal 9
exited from VE 101
vps1 ~ #


Does this appear to be a problem with OVZ or with the guest template?



[1] http://forum.openvz.org/index.php?t=msg&goto=6354&

On Mon, 2007-12-10 at 17:20 -0800, Cliff Wells wrote:

> Guest OS: ubuntu-7.10-i386-minimal
> 

> Does this appear to be a problem with OVZ or with the guest template?
> 

Answering my own question: it appears that the template is broken.
centos-5-i386-minimal works fine.

Cliff

Ubuntu 7.10 requires the latest vzctl (check http://git.openvz.org to compile it)
otherwise init does busy loop on VE start (plz check it),
so it can hang and not stop.
(`kill -KILL <VE-init-pid` from host system will kill the whole VE
very quickly :@) still)

Kirill


Cliff Wells wrote:
> Hardware: dual Opteron 242
> Kernel: linux-2.6.18-openvz-028.049
> Host OS: Gentoo
> Guest OS: ubuntu-7.10-i386-minimal
> 
> Both host and VE are fresh installs.
> 
> I noticed that "vzctl stop 101" would fail with
> 
> Stopping VPS ...
> Unable to stop VPS, operation timed out
> 
> 
> This of course also prevented me from properly shutting down the system
> (power off required).
> 
> I found a post [1] that seemed related, which led to investigating halt
> commands:
> 
> vps1 ~ # vzctl enter 101
> root@localhost:/# halt -p
> shutdown: Unable to send message: Connection refused
> root@localhost:/# halt
> shutdown: Unable to send message: Connection refused 
> root@localhost:/dev# halt -fp
> got signal 9
> exited from VE 101
> vps1 ~ #
> 
> 
> Does this appear to be a problem with OVZ or with the guest template?
> 
> 
> 
> [1] http://forum.openvz.org/index.php?t=msg&goto=6354&
> 
> 
>

This is probably a problem with VE start, not stop. VE started badly and 
can not stop.

This is known issue (a bad interaction of Ubuntu's upstart (init 
replacement) and vzctl) which is fixed in upcoming vzctl release, see 
http://bugzilla.openvz.org/662

Now you have three options:
1. Wait for next vzctl release (should happen real soon now).
2. Replace upstart with init (sysvinit) inside a VE
3. Rebuild vzctl either from GIT or just adding the patch from git 
linked from bug #622.

Cliff Wells wrote:
> Hardware: dual Opteron 242
> Kernel: linux-2.6.18-openvz-028.049
> Host OS: Gentoo
> Guest OS: ubuntu-7.10-i386-minimal
>
> Both host and VE are fresh installs.
>
> I noticed that "vzctl stop 101" would fail with
>
> Stopping VPS ...
> Unable to stop VPS, operation timed out
>
>
> This of course also prevented me from properly shutting down the system
> (power off required).
>
> I found a post [1] that seemed related, which led to investigating halt
> commands:
>
> vps1 ~ # vzctl enter 101
> root@localhost:/# halt -p
> shutdown: Unable to send message: Connection refused
> root@localhost:/# halt
> shutdown: Unable to send message: Connection refused 
> root@localhost:/dev# halt -fp
> got signal 9
> exited from VE 101
> vps1 ~ #
>
>
> Does this appear to be a problem with OVZ or with the guest template?
>
>
>
> [1] http://forum.openvz.org/index.php?t=msg&goto=6354&
>
>
>

On Tue, 2007-12-11 at 16:58 +0300, vaverin wrote:
> 
> Could You please check that You using init from upstart package?
> In this case You can work-around this issue by switching to sysvinit

For the moment, I deleted the VE in question, but what I'll probably do
is use vzctl from git as suggested by Kir.

Regards,
Cliff

On Tue, 2007-12-11 at 19:35 +0300, Kir Kolyshkin wrote:
> This is probably a problem with VE start, not stop. VE started badly and 
> can not stop.
> 
> This is known issue (a bad interaction of Ubuntu's upstart (init 
> replacement) and vzctl) which is fixed in upcoming vzctl release, see 
> http://bugzilla.openvz.org/662
> 
> Now you have three options:
> 1. Wait for next vzctl release (should happen real soon now).
> 2. Replace upstart with init (sysvinit) inside a VE
> 3. Rebuild vzctl either from GIT or just adding the patch from git 
> linked from bug #622.

I installed vzctl from git.  This seems to solve the problem with the VE
starting and stopping.  However, after the VE is run once, the network
refuses to come up unless I delete the VE's IP address and add it again:


vps1 ~ # vzctl start 106
Starting VE ...
VE is mounted
Adding IP address(es): 10.10.10.106
Setting CPU units: 1584
Configure meminfo: 72498
Set hostname: vz106
File resolv.conf was modified
VE start in progress...
vps1 ~ # vzctl enter 106
entered into VE 106
id: cannot find name for group ID 11
root@vz106:/# ip addr
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
3: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,10000> mtu 1500 qdisc
noqueue 
    link/void 
    inet 127.0.0.1/32 scope host venet0
    inet 10.10.10.106/32 scope global venet0:0
root@vz106:/# ping google.com
PING google.com (72.14.207.99) 56(84) bytes of data.
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=1 ttl=238
time=98.8 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=2 ttl=238
time=99.1 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=3 ttl=238
time=98.1 ms

--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 98.106/98.696/99.138/0.504 ms
root@vz106:/# logout
exited from VE 106
vps1 ~ # vzctl stop 106
Stopping VE ...
VE was stopped
VE is unmounted
vps1 ~ # vzctl start 106
Starting VE ...
VE is mounted
Adding IP address(es): 10.10.10.106
Setting CPU units: 1584
Configure meminfo: 72498
Set hostname: vz106
File resolv.conf was modified
VE start in progress...
vps1 ~ # vzctl enter 106
entered into VE 106
id: cannot find name for group ID 11
root@vz106:/# ping google.com
ping: unknown host google.com
root@vz106:/# ip addr
1: lo: <LOOPBACK> mtu 16436 qdisc noop 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: venet0: <BROADCAST,POINTOPOINT,NOARP> mtu 1500 qdisc noop 
    link/void 
root@vz106:/# 

If I exit the VE and delete/re-add the IP address it starts working
again:

vps1 ~ # vzctl set 106 --ipdel all --save
Deleting IP address(es): 
Adding IP address(es): 
Saved parameters for VE 106
vps1 ~ # vzctl set 106 --ipadd 10.10.10.106 --save
Adding IP address(es): 10.10.10.106
Saved parameters for VE 106
vps1 ~ # vzctl enter 106
entered into VE 106
id: cannot find name for group ID 11
root@vz106:/# ping google.com
PING google.com (64.233.187.99) 56(84) bytes of data.
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=1 ttl=237
time=76.8 ms



Could this be another problem with upstart?

The five CentOS 5 VE's I setup prior to this work perfectly.
It's also worth noting I'm using 2.6.22 ovz005.

Regards,
Cliff

On Tue, 2007-12-11 at 23:10 -0800, Cliff Wells wrote:

> 
> Could this be another problem with upstart?

Apparently not.  Switching to sysvinit didn't have any effect.


Cliff

On Wed, 2007-12-12 at 10:36 +0300, vaverin wrote:

> as far as I see even loopback device is not configured. It looks like network service has not been started.
> Probably some scripts inside your VE hangs and blocks the the following network configuration.
> IMHO it makes sense to look at 'ps ax' inside VE -- it should show You stalled process.

Thanks for the reply.  In the interim I tried the
contrib/ubuntu-7.10-i386 template and it appears to work fine.

Maybe that one should replace the official ubuntu-7.10-i386 template?

Regards,
Cliff

On Wed, 2007-12-12 at 11:54 +0300, kir wrote:
> 
> The only problem with official ubuntu 7.10 is it comes with upstart,
> ubuntu replacement for sysvinit. Upstart in VE requires a little
> change from vzctl to work properly. This will be released soon in
> vzctl-3.0.20.
> 

Actually, I was already running vzctl from git (as of a few hours ago),
so there's apparently other issues with the official ubuntu.

Regards,
Cliff

Cliff Wells wrote:
> On Tue, 2007-12-11 at 19:35 +0300, Kir Kolyshkin wrote:
>   
>> This is probably a problem with VE start, not stop. VE started badly and 
>> can not stop.
>>
>> This is known issue (a bad interaction of Ubuntu's upstart (init 
>> replacement) and vzctl) which is fixed in upcoming vzctl release, see 
>> http://bugzilla.openvz.org/662
>>
>> Now you have three options:
>> 1. Wait for next vzctl release (should happen real soon now).
>> 2. Replace upstart with init (sysvinit) inside a VE
>> 3. Rebuild vzctl either from GIT or just adding the patch from git 
>> linked from bug #622.
>>     
>
> I installed vzctl from git.  This seems to solve the problem with the VE
> starting and stopping.  However, after the VE is run once, the network
> refuses to come up unless I delete the VE's IP address and add it again:
>
>
> vps1 ~ # vzctl start 106
> Starting VE ...
> VE is mounted
> Adding IP address(es): 10.10.10.106
> Setting CPU units: 1584
> Configure meminfo: 72498
> Set hostname: vz106
> File resolv.conf was modified
> VE start in progress...
> vps1 ~ # vzctl enter 106
> entered into VE 106
> id: cannot find name for group ID 11
> root@vz106:/# ip addr
> 1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue 
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>     inet6 ::1/128 scope host 
>        valid_lft forever preferred_lft forever
> 3: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,10000> mtu 1500 qdisc
> noqueue 
>     link/void 
>     inet 127.0.0.1/32 scope host venet0
>     inet 10.10.10.106/32 scope global venet0:0
> root@vz106:/# ping google.com
> PING google.com (72.14.207.99) 56(84) bytes of data.
> 64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=1 ttl=238
> time=98.8 ms
> 64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=2 ttl=238
> time=99.1 ms
> 64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=3 ttl=238
> time=98.1 ms
>
> --- google.com ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2000ms
> rtt min/avg/max/mdev = 98.106/98.696/99.138/0.504 ms
> root@vz106:/# logout
> exited from VE 106
> vps1 ~ # vzctl stop 106
> Stopping VE ...
> VE was stopped
> VE is unmounted
> vps1 ~ # vzctl start 106
> Starting VE ...
> VE is mounted
> Adding IP address(es): 10.10.10.106
> Setting CPU units: 1584
> Configure meminfo: 72498
> Set hostname: vz106
> File resolv.conf was modified
> VE start in progress...
> vps1 ~ # vzctl enter 106
> entered into VE 106
> id: cannot find name for group ID 11
> root@vz106:/# ping google.com
> ping: unknown host google.com
> root@vz106:/# ip addr
> 1: lo: <LOOPBACK> mtu 16436 qdisc noop 
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 3: venet0: <BROADCAST,POINTOPOINT,NOARP> mtu 1500 qdisc noop 
>     link/void 
> root@vz106:/# 
>
> If I exit the VE and delete/re-add the IP address it starts working
> again:
>
> vps1 ~ # vzctl set 106 --ipdel all --save
> Deleting IP address(es): 
> Adding IP address(es): 
> Saved parameters for VE 106
> vps1 ~ # vzctl set 106 --ipadd 10.10.10.106 --save
> Adding IP address(es): 10.10.10.106
> Saved parameters for VE 106
> vps1 ~ # vzctl enter 106
> entered into VE 106
> id: cannot find name for group ID 11
> root@vz106:/# ping google.com
> PING google.com (64.233.187.99) 56(84) bytes of data.
> 64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=1 ttl=237
> time=76.8 ms
>
>
>
> Could this be another problem with upstart?
>   

I am investigating the problem right now, will keep you updated.

OK, here's what I found concerning ubuntu-7.10 VE vs. OpenVZ.

0. (just repeating) Ubuntu-7.10 template with upstart instead of init 
requires vzctl > 3.0.18. An updated vzctl (apparently it will have 
version of 3.0.21) is not yet released.

1. There was an obscure bug in not-yet-released vzctl, which fires when 
a Debian/Ubuntu based VE has more than one IP address. The bug is now 
fixed in GIT (see http://tinyurl.com/2w68ch) and will be included into 
next vzctl release. Note that released vzctl version (i.e. 3.0.18) is 
not affected.

2. Ubuntu 7.10 initscripts (including netscripts) relied on the fact 
that /var/run is resides on a tmpfs partition, so it would be empty 
after reboot. Because of that they don't care about stopping some 
services, cleaning state files etc. It only became a problem when I 
optimized Ubuntu template to not use tmpfs (because tmpfs eats some 
physical memory, which might not be desired then there are a lot of VEs 
on a system). Networking was not up on VE restart just because of that 
-- ifup script saved interface state in /var/run/network/ifstate, while 
ifdown was never called on VE stop, so next ifup (after VE reboot) was 
not taking care of interfaces which according to ifstate were already up.

This was fixed in an updated ubuntu templates that I just uploaded to 
http://download.openvz.org/template/precreated/. These templates are now 
back to using tmpfs for some directories. Other changes I made are: 
removal of a few more packages (ntpdate eject libasound2 pciutils 
tasksel tasksel-data laptop-detect), log files cleanup.

Also, while at it, I have modified Ubuntu Gutsy template creation 
document in wiki.
Latest version: http://wiki.openvz.org/Ubuntu_Gutsy_template_creation
My changes: http://tinyurl.com/2u2oxj

Hope that helps.

PS I appreciate if somebody can help with testing a new vzctl from git.
**
Kir Kolyshkin wrote:
> Cliff Wells wrote:
>> On Tue, 2007-12-11 at 19:35 +0300, Kir Kolyshkin wrote:
>>  
>>> This is probably a problem with VE start, not stop. VE started badly 
>>> and can not stop.
>>>
>>> This is known issue (a bad interaction of Ubuntu's upstart (init 
>>> replacement) and vzctl) which is fixed in upcoming vzctl release, 
>>> see http://bugzilla.openvz.org/662
>>>
>>> Now you have three options:
>>> 1. Wait for next vzctl release (should happen real soon now).
>>> 2. Replace upstart with init (sysvinit) inside a VE
>>> 3. Rebuild vzctl either from GIT or just adding the patch from git 
>>> linked from bug #622.
>>>     
>>
>> I installed vzctl from git.  This seems to solve the problem with the VE
>> starting and stopping.  However, after the VE is run once, the network
>> refuses to come up unless I delete the VE's IP address and add it again:
>>
>>
>> vps1 ~ # vzctl start 106
>> Starting VE ...
>> VE is mounted
>> Adding IP address(es): 10.10.10.106
>> Setting CPU units: 1584
>> Configure meminfo: 72498
>> Set hostname: vz106
>> File resolv.conf was modified
>> VE start in progress...
>> vps1 ~ # vzctl enter 106
>> entered into VE 106
>> id: cannot find name for group ID 11
>> root@vz106:/# ip addr
>> 1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue     link/loopback 
>> 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>     inet 127.0.0.1/8 scope host lo
>>     inet6 ::1/128 scope host        valid_lft forever preferred_lft 
>> forever
>> 3: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,10000> mtu 1500 qdisc
>> noqueue     link/void     inet 127.0.0.1/32 scope host venet0
>>     inet 10.10.10.106/32 scope global venet0:0
>> root@vz106:/# ping google.com
>> PING google.com (72.14.207.99) 56(84) bytes of data.
>> 64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=1 ttl=238
>> time=98.8 ms
>> 64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=2 ttl=238
>> time=99.1 ms
>> 64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=3 ttl=238
>> time=98.1 ms
>>
>> --- google.com ping statistics ---
>> 3 packets transmitted, 3 received, 0% packet loss, time 2000ms
>> rtt min/avg/max/mdev = 98.106/98.696/99.138/0.504 ms
>> root@vz106:/# logout
>> exited from VE 106
>> vps1 ~ # vzctl stop 106
>> Stopping VE ...
>> VE was stopped
>> VE is unmounted
>> vps1 ~ # vzctl start 106
>> Starting VE ...
>> VE is mounted
>> Adding IP address(es): 10.10.10.106
>> Setting CPU units: 1584
>> Configure meminfo: 72498
>> Set hostname: vz106
>> File resolv.conf was modified
>> VE start in progress...
>> vps1 ~ # vzctl enter 106
>> entered into VE 106
>> id: cannot find name for group ID 11
>> root@vz106:/# ping google.com
>> ping: unknown host google.com
>> root@vz106:/# ip addr
>> 1: lo: <LOOPBACK> mtu 16436 qdisc noop     link/loopback 
>> 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> 3: venet0: <BROADCAST,POINTOPOINT,NOARP> mtu 1500 qdisc noop     
>> link/void root@vz106:/#
>> If I exit the VE and delete/re-add the IP address it starts working
>> again:
>>
>> vps1 ~ # vzctl set 106 --ipdel all --save
>> Deleting IP address(es): Adding IP address(es): Saved parameters for 
>> VE 106
>> vps1 ~ # vzctl set 106 --ipadd 10.10.10.106 --save
>> Adding IP address(es): 10.10.10.106
>> Saved parameters for VE 106
>> vps1 ~ # vzctl enter 106
>> entered into VE 106
>> id: cannot find name for group ID 11
>> root@vz106:/# ping google.com
>> PING google.com (64.233.187.99) 56(84) bytes of data.
>> 64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=1 ttl=237
>> time=76.8 ms
>>
>>
>>
>> Could this be another problem with upstart?
>>   
>
> I am investigating the problem right now, will keep you updated.

On Thu, 2007-12-13 at 19:02 +0300, Kir Kolyshkin wrote:
> OK, here's what I found concerning ubuntu-7.10 VE vs. OpenVZ.

> This was fixed in an updated ubuntu templates that I just uploaded to 
> http://download.openvz.org/template/precreated/. These templates are now 
> back to using tmpfs for some directories. Other changes I made are: 
> removal of a few more packages (ntpdate eject libasound2 pciutils 
> tasksel tasksel-data laptop-detect), log files cleanup.
> 
> Also, while at it, I have modified Ubuntu Gutsy template creation 
> document in wiki.
> Latest version: http://wiki.openvz.org/Ubuntu_Gutsy_template_creation
> My changes: http://tinyurl.com/2u2oxj
> 
> Hope that helps.
> 
> PS I appreciate if somebody can help with testing a new vzctl from git.


I'll give this a go and report back.  Thanks for tackling this.

Regards,
Cliff

On Thu, 2007-12-13 at 19:02 +0300, Kir Kolyshkin wrote:
> OK, here's what I found concerning ubuntu-7.10 VE vs. OpenVZ.

Seems to work fine.  Minor nit would be the unknown group 11.  I did a
'find -gid 11' and it turned up a bunch of /dev/fd* stuff with that GID,
but chowning them to root didn't get rid of the message.

Networking now seems to work fine.

I was a bit curious about the results of 'mount':

vps1 ~ # vzctl enter 108
entered into VE 108
id: cannot find name for group ID 11
root@vz108:/# mount
simfs on / type simfs (rw,noatime)
proc on /proc type proc (rw,nosuid,nodev,noexec)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)
tmpfs on /var/run type tmpfs (rw,nosuid,nodev,noexec)
tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,noexec)
tmpfs on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw)
tmpfs on /var/run type tmpfs (rw,nosuid,nodev,noexec)
tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,noexec)
root@vz108:/# 

It looks as if perhaps the tmpfs's are being mounted twice now?


Overall this is much better than it was before.

Regards,
Cliff

Cliff Wells wrote:
> On Thu, 2007-12-13 at 19:02 +0300, Kir Kolyshkin wrote:
>   
>> OK, here's what I found concerning ubuntu-7.10 VE vs. OpenVZ.
>>     
>
> Seems to work fine.  Minor nit would be the unknown group 11.  I did a
> 'find -gid 11' and it turned up a bunch of /dev/fd* stuff with that GID,
> but chowning them to root didn't get rid of the message.
>   

This message ("id: cannot find name for group ID 11") comes from id 
binary which is executed from /etc/profile during user login (or vzctl 
enter). Since root belongs to group 11, "id" tries to get the name of 
the group.

The line about group with ID of 11 is absent from /etc/group. I'm not 
sure why. Since you found out some /dev/fd* files belong to the group, I 
guess group name should be something like 'floppy'. I guess that adding 
something like
floppy:x:11:
to /etc/group should fix the issue.

I will file a bug to ubuntu about that, but generally it should be 
harmless as it is.

> Networking now seems to work fine.
>
> I was a bit curious about the results of 'mount':
>
> vps1 ~ # vzctl enter 108
> entered into VE 108
> id: cannot find name for group ID 11
> root@vz108:/# mount
> simfs on / type simfs (rw,noatime)
> proc on /proc type proc (rw,nosuid,nodev,noexec)
> sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)
> tmpfs on /var/run type tmpfs (rw,nosuid,nodev,noexec)
> tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,noexec)
> tmpfs on /dev/shm type tmpfs (rw)
> devpts on /dev/pts type devpts (rw)
> tmpfs on /var/run type tmpfs (rw,nosuid,nodev,noexec)
> tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,noexec)
> root@vz108:/# 
>
> It looks as if perhaps the tmpfs's are being mounted twice now?
>   
Yep, first time they do it in /etc/init.d/mountkernfs.sh, then in 
/etc/init.d/mountall.sh (calling pre_mountall function from sourced 
/lib/init/mount-functions.sh) they bind-mount both /var/run and 
/var/lock to under /dev/shm. That is why we see what we see.

I am not touching that stuff now because I already learned they assume a 
lot of things (like /var/run is clean after reboot) and one can open a 
can of worms breaking their assumptions.

Still I don't understand why they mount twice and I will file a bug 
about it.
> Overall this is much better than it was before.
>   

Hope so :)

Kir Kolyshkin wrote:
> Cliff Wells wrote:
>> On Thu, 2007-12-13 at 19:02 +0300, Kir Kolyshkin wrote:
>>  
>>> OK, here's what I found concerning ubuntu-7.10 VE vs. OpenVZ.
>>>     
>>
>> Seems to work fine.  Minor nit would be the unknown group 11.  I did a
>> 'find -gid 11' and it turned up a bunch of /dev/fd* stuff with that GID,
>> but chowning them to root didn't get rid of the message.
>>   
>
> This message ("id: cannot find name for group ID 11") comes from id 
> binary which is executed from /etc/profile during user login (or vzctl 
> enter). Since root belongs to group 11, "id" tries to get the name of 
> the group.
>
> The line about group with ID of 11 is absent from /etc/group. I'm not 
> sure why. Since you found out some /dev/fd* files belong to the group, 
> I guess group name should be something like 'floppy'. I guess that 
> adding something like
> floppy:x:11:
> to /etc/group should fix the issue.
>
> I will file a bug to ubuntu about that, but generally it should be 
> harmless as it is.
Well, apparently the problem is way different. They do have floppy 
group, but with a different GID. The problem is it looks like MAKEDEV 
script used by debootstrap to create devices is using host system's 
/etc/groups, thus /dev/fd* has a group ID of 11, which is 'floppy' on my 
host Gentoo system I use to bootstrap this template.

So, this looks like a bug in debootstrap.
>
>>
>> It looks as if perhaps the tmpfs's are being mounted twice now?
>>   
> Yep, first time they do it in /etc/init.d/mountkernfs.sh, then in 
> /etc/init.d/mountall.sh (calling pre_mountall function from sourced 
> /lib/init/mount-functions.sh) they bind-mount both /var/run and 
> /var/lock to under /dev/shm. That is why we see what we see.
>
> I am not touching that stuff now because I already learned they assume 
> a lot of things (like /var/run is clean after reboot) and one can open 
> a can of worms breaking their assumptions.
>
> Still I don't understand why they mount twice and I will file a bug 
> about it.
Apparently they do want it that way
https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/163956

vzctl –cpus causes strange load metering:

top - 09:40:02 up 9 days, 7:32, 0 users, load average: 864.89, 938.24, 
675.41
Tasks: 124 total, 2 running, 121 sleeping, 0 stopped, 1 zombie
Cpu(s): 13.7%us, 0.6%sy, 0.0%ni, 84.6%id, 1.1%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 16099800k total, 15962272k used, 137528k free, 271512k buffers
Swap: 3911816k total, 6920k used, 3904896k free, 11216460k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14004 apache 25 0 14336 10m 9772 R 100 0.1 0:06.79 convert
14015 apache 15 0 6988 3276 1588 S 1 0.0 0:00.04 proftpd
13732 apache 15 0 41744 24m 2840 S 0 0.2 0:06.36 apache2
13826 apache 18 0 41908 24m 2836 S 0 0.2 0:04.76 apache2
13990 root 15 0 2240 1132 836 R 0 0.0 0:00.04 top
1 root 18 0 1596 540 476 S 0 0.0 0:01.84 init
25736 root 18 0 2076 816 504 S 0 0.0 0:05.91 syslog-ng
26150 root 18 0 4096 932 616 S 0 0.0 0:00.00 sshd
28340 mysql 18 0 550m 368m 4152 S 0 2.3 118:43.82 mysqld
32152 ftp 18 0 6192 1380 612 S 0 0.0 0:01.76 proftpd
32246 root 18 0 1652 464 384 S 0 0.0 0:00.23 cron
1515 root 17 0 6360 1668 1256 S 0 0.0 0:07.12 master
1522 postfix 15 0 6404 1712 1284 S 0 0.0 0:04.30 qmgr
17834 root 18 0 1980 668 532 S 0 0.0 0:00.00 vzctl
17835 root 18 0 2736 1516 1236 S 0 0.0 0:00.00 bash
32323 root 18 0 2180 832 664 S 0 0.0 0:00.14 cron
32325 root 18 0 0 0 0 Z 0 0.0 0:00.00 bash <defunct>
1406 root 18 0 1500 288 236 S 0 0.0 0:00.01 cronolog
1423 root 15 0 22932 10m 4020 S 0 0.1 0:00.11 apache2-php5
1424 root 18 0 1640 424 360 S 0 0.0 0:00.00 cronolog
1552 apache 18 0 22932 8060 1820 S 0 0.1 0:00.00 apache2-php5
1553 apache 18 0 22932 8060 1820 S 0 0.1 0:00.00 apache2-php5
3549 root 18 0 6484 1696 1292 S 0 0.0 0:00.00 sendmail
3551 root 25 0 6456 1656 1256 S 0 0.0 0:00.02 postdrop
2018 root 18 0 1508 292 236 S 0 0.0 0:00.00 cronolog
3133 root 18 0 29504 13m 4048 S 0 0.1 0:00.87 apache2
3134 root 18 0 1636 428 360 S 0 0.0 0:00.01 cronolog
3138 root 18 0 1636 428 360 S 0 0.0 0:00.04 cronolog
3139 root 18 0 1644 432 360 S 0 0.0 0:00.00 cronolog
3141 root 18 0 1644 428 360 S 0 0.0 0:00.01 cronolog
3143 root 18 0 1644 428 360 S 0 0.0 0:00.00 cronolog
3145 root 18 0 1636 424 360 S 0 0.0 0:00.00 cronolog
3148 root 18 0 1512 292 236 S 0 0.0 0:00.01 cronolog
3150 root 18 0 1644 428 360 S 0 0.0 0:00.04 cronolog
3151 root 18 0 1508 292 236 S 0 0.0 0:00.00 cronolog
3152 root 18 0 1504 292 236 S 0 0.0 0:00.01 cronolog
3153 root 25 0 1512 296 236 S 0 0.0 0:00.00 cronolog
3154 root 18 0 1632 424 360 S 0 0.0 0:00.37 cronolog
3155 root 18 0 1644 432 360 S 0 0.0 0:00.00 cronolog
3156 root 18 0 1644 432 360 S 0 0.0 0:00.01 cronolog
3157 root 18 0 1632 420 360 S 0 0.0 0:00.01 cronolog
3158 root 18 0 1636 428 360 S 0 0.0 0:00.01 cronolog
ggh1-vps / # cat /proc/user_beancounters
Version: 2.5
uid resource held maxheld barrier limit failcnt
501: kmemsize 12957612 23959066 59436509 65380159 0
lockedpages 0 5 2902 2902 0
privvmpages 202365 491934 1200000 1200000 2673511
shmpages 2330 19000 62209 62209 0
dummy 0 0 0 0 0
numproc 127 199 32000 32000 0
physpages 137440 361644 0 2147483647 0
vmguarpages 0 0 622098 2147483647 0
oomguarpages 139149 363498 1000000 2147483647 0
numtcpsock 15 137 2666 2666 0
numflock 2 77 1000 1100 0
numpty 2 3 16 16 0
numsiginfo 0 104 1024 1024 0
tcpsndbuf 2574336 13694864 100000000 100000000 0
tcprcvbuf 2430288 7808832 100000000 100000000 0
othersockbuf 162352 1219296 6000000 15366053 96438
dgramrcvbuf 0 8368 4446117 4446117 0
numothersock 104 128 2666 2666 0
dcachesize 1612456 1791880 12973980 13363200 0
numfile 3471 4270 100000 100000 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
numiptent 57 57 512 512 0


Have fun, regards, Guido

Keep up the good work!

System: Gentoo + stable openvz kernel -> runs fine so far

stepken wrote:
>
> vzctl –cpus causes strange load metering:
>
> <...skipped...>
> System: Gentoo + stable openvz kernel -> runs fine so far

As Vasily points out, this bug is fixed in 051 kernel. On a Gentoo 
system if you want to upgrade to 051, you have to do the following (as 
root):

# To enable ebuilds not marked as unstable
echo "sys-kernel/openvz-sources" >> /etc/portage/package.keywords
# To emerge this kernel (they have changed numbering)
emerge --oneshot =sys-kernel/openvz-sources-2.6.18.028.051