Re: [Users] simfs with ploop?
QUOTAUGIDLIMIT is set to 3000 in the containers where it is set at all. It
doesn't seem to have any bearing on the problem though - some containers
with this problem have QUOTAUGIDLIMIT set, others don't.
2201 probably doesn't have second -level quota, 2202 does - and has a
number of /dev/ploop* devices, but /proc/mounts doesn't list the correct
one.
On Wed, Jan 21, 2015 at 5:51 PM, Kir Kolyshkin k...@openvz.org wrote:
On 01/21/2015 08:27 AM, Rene C. wrote:
The reason I became aware of the problem was that a cpanel servers started
sending this message every morning:
repquota: Can't stat() mounted device /dev/ploop50951p1: No such file or
directory
All containers on another hardware node and several on this have the
devices working correctly within the containers.
What's the setting of QUOTAUGIDLIMIT for a given container?
Note ploop device is only created inside the container if second-level
quota is enabled.
On Wed, Jan 21, 2015 at 5:11 PM, Devon B. devo...@virtualcomplete.com
wrote:
I can't speak as to how to address the issue, but why do you consider it
messed up? I logged in to a few nodes and saw the same thing on all of
them and I don't remember this being any different in the past. The ploop
device only exists outside of the container (when mounted). Inside the
container is just a reference, no actual device exists.
I don't know enough about the original issue, what are you trying to
accomplish with the ploop device inside the container?
Rene C. ope...@dokbua.com
Wednesday, January 21, 2015 6:47 AM
I've gone through all containers and actually some of them work
correctly, only some are messed up like this.
Take for example this one:
[root@server22 ~]# vzctl restart 2201
Restarting container
Stopping container ...
Container was stopped
Unmounting file system at /vz/root/2201
Unmounting device /dev/ploop27939
Container is unmounted
Starting container...
Opening delta /vz/private/2201/root.hdd/root.hdd
Adding delta dev=/dev/ploop27939 img=/vz/private/2201/root.hdd/root.hdd
(ro)
Adding delta dev=/dev/ploop27939
img=/vz/private/2201/root.hdd/root.hdd.{7a09b730-f2d6-4b21-b856-0bd6ca420a6e}
(rw)
Mounting /dev/ploop27939p1 at /vz/root/2201 fstype=ext4
data='balloon_ino=12,'
Container is mounted
Adding IP address(es): (redacted)
Setting CPU limit: 400
Setting CPU units: 50
Setting CPUs: 4
Container start in progress...
So apparently the ploop device should be /dev/ploop/27939. Everything
seems to work, inside the container this device is referred by /proc/mounts
[root@server22 ~]# vzctl exec 2201 cat /proc/mounts
/dev/ploop27939p1 / ext4
rw,relatime,barrier=1,data=ordered,balloon_ino=12 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /dev tmpfs rw,relatime,mode=755 0 0
none /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
But the device is actually missing:
[root@server22 ~]# vzctl exec 2201 ls -l /dev/ploop27939p1
ls: /dev/ploop27939p1: No such file or directory
In fact, there doesn't seem to be ANY /dev/ploop devices in this
container
[root@server22 ~]# vzctl exec 2201 ls -l /dev/ploop*
ls: /dev/ploop18940: No such file or directory
ls: /dev/ploop18940p1: No such file or directory
ls: /dev/ploop26517: No such file or directory
ls: /dev/ploop26517p1: No such file or directory
ls: /dev/ploop27379: No such file or directory
ls: /dev/ploop27379p1: No such file or directory
ls: /dev/ploop27939: No such file or directory
ls: /dev/ploop27939p1: No such file or directory
ls: /dev/ploop50951: No such file or directory
ls: /dev/ploop50951p1: No such file or directory
ls: /dev/ploop52860: No such file or directory
ls: /dev/ploop52860p1: No such file or directory
ls: /dev/ploop58415: No such file or directory
ls: /dev/ploop58415p1: No such file or directory
Why does it shows devices when there are none present? Obviously
something is messed up, how can we fix this?
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users
Rene C. ope...@dokbua.com
Tuesday, January 20, 2015 12:04 PM
No takers?
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users
Rene C. ope...@dokbua.com
Tuesday, January 13, 2015 12:00 PM
Hm, well I removed the scripts, now I get the error:
repquota: Can't stat() mounted device /dev/ploop50951p1: No such file
or directory
I don't know if this is related at all, it kinda started after a recent
update to the latest kernel 2.6.32-042stab102.9
Now if I go into any container on this hardware node, the /dev/ploopXXX
devices listed in /proc/mount doesn't exist.
For example:
root@vps2202 [~]# cat /proc/mounts
/dev/ploop50951p1 / ext4
Re: [Users] simfs with ploop?
I can't speak as to how to address the issue, but why do you consider it
messed up? I logged in to a few nodes and saw the same thing on all of
them and I don't remember this being any different in the past. The
ploop device only exists outside of the container (when mounted).
Inside the container is just a reference, no actual device exists.
I don't know enough about the original issue, what are you trying to
accomplish with the ploop device inside the container?
Rene C. mailto:ope...@dokbua.com
Wednesday, January 21, 2015 6:47 AM
I've gone through all containers and actually some of them work
correctly, only some are messed up like this.
Take for example this one:
[root@server22 ~]# vzctl restart 2201
Restarting container
Stopping container ...
Container was stopped
Unmounting file system at /vz/root/2201
Unmounting device /dev/ploop27939
Container is unmounted
Starting container...
Opening delta /vz/private/2201/root.hdd/root.hdd
Adding delta dev=/dev/ploop27939
img=/vz/private/2201/root.hdd/root.hdd (ro)
Adding delta dev=/dev/ploop27939
img=/vz/private/2201/root.hdd/root.hdd.{7a09b730-f2d6-4b21-b856-0bd6ca420a6e}
(rw)
Mounting /dev/ploop27939p1 at /vz/root/2201 fstype=ext4
data='balloon_ino=12,'
Container is mounted
Adding IP address(es): (redacted)
Setting CPU limit: 400
Setting CPU units: 50
Setting CPUs: 4
Container start in progress...
So apparently the ploop device should be /dev/ploop/27939. Everything
seems to work, inside the container this device is referred by
/proc/mounts
[root@server22 ~]# vzctl exec 2201 cat /proc/mounts
/dev/ploop27939p1 / ext4
rw,relatime,barrier=1,data=ordered,balloon_ino=12 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /dev tmpfs rw,relatime,mode=755 0 0
none /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
But the device is actually missing:
[root@server22 ~]# vzctl exec 2201 ls -l /dev/ploop27939p1
ls: /dev/ploop27939p1: No such file or directory
In fact, there doesn't seem to be ANY /dev/ploop devices in this container
[root@server22 ~]# vzctl exec 2201 ls -l /dev/ploop*
ls: /dev/ploop18940: No such file or directory
ls: /dev/ploop18940p1: No such file or directory
ls: /dev/ploop26517: No such file or directory
ls: /dev/ploop26517p1: No such file or directory
ls: /dev/ploop27379: No such file or directory
ls: /dev/ploop27379p1: No such file or directory
ls: /dev/ploop27939: No such file or directory
ls: /dev/ploop27939p1: No such file or directory
ls: /dev/ploop50951: No such file or directory
ls: /dev/ploop50951p1: No such file or directory
ls: /dev/ploop52860: No such file or directory
ls: /dev/ploop52860p1: No such file or directory
ls: /dev/ploop58415: No such file or directory
ls: /dev/ploop58415p1: No such file or directory
Why does it shows devices when there are none present? Obviously
something is messed up, how can we fix this?
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users
Rene C. mailto:ope...@dokbua.com
Tuesday, January 20, 2015 12:04 PM
No takers?
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users
Rene C. mailto:ope...@dokbua.com
Tuesday, January 13, 2015 12:00 PM
Hm, well I removed the scripts, now I get the error:
repquota: Can't stat() mounted device /dev/ploop50951p1: No such file
or directory
I don't know if this is related at all, it kinda started after a
recent update to the latest kernel 2.6.32-042stab102.9
Now if I go into any container on this hardware node, the
/dev/ploopXXX devices listed in /proc/mount doesn't exist.
For example:
root@vps2202 [~]# cat /proc/mounts
/dev/ploop50951p1 / ext4
rw,relatime,barrier=1,stripe=256,data=ordered,balloon_ino=12,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group
0 0
/dev/simfs /backup simfs rw,relatime 0 0
proc /proc proc rw,relatime 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /dev tmpfs rw,relatime,size=7992992k,nr_inodes=1998248 0 0
none /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
root@vps2202 [~]# ll /dev/ploop50951p1
/bin/ls: /dev/ploop50951p1: No such file or directory
There are quite a few /dev/ploop* devices under /dev, but not the one
linked in /proc/mounts.
This goes for all containers on this hardware node. Other nodes not
yet upgraded to the latest kernel do not have this problem.
Any ideas?
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users
Kir Kolyshkin mailto:k...@openvz.org
Friday, December 26, 2014 6:31 PM
No, the script (and its appropriate symlinks) is (re)created on every
start (actually mount)
of a simfs-based container. It is a
Re: [Users] simfs with ploop?
I looked at a few more containers. A couple have the ploop device and a
couple do. I'm not sure why. Most that do have the ploop devices have
a bunch of stale ones. For instance:
# vzctl exec ls -l /dev/ploop*
b-x--- 1 root root 182, 300625 Jan 18 22:57 /dev/ploop18789p1
b-x--- 1 root root 182, 355073 Jan 18 22:57 /dev/ploop22192p1
b-x--- 1 root root 182, 371265 Jan 18 22:57 /dev/ploop23204p1
b-x--- 1 root root 182, 428529 Jan 18 22:57 /dev/ploop26783p1
b-x--- 1 root root 182, 525073 Jan 18 22:57 /dev/ploop32817p1
b-x--- 1 root root 182, 655857 Jan 18 22:57 /dev/ploop40991p1
b-x--- 1 root root 182, 727537 Jan 18 22:57 /dev/ploop45471p1
brw-rw---T 1 root disk 182, 749697 Jan 18 22:57 /dev/ploop46856p1
b-x--- 1 root root 182, 773185 Jan 18 22:57 /dev/ploop48324p1
b-x--- 1 root root 182, 864529 Jan 18 22:57 /dev/ploop54033p1
b-x--- 1 root root 182, 897201 Jan 18 22:57 /dev/ploop56075p1
The active one is pretty obvious (/dev/ploop46856p1).It doesn't seem
to be specific to node or kernel, the containers are split on the same
system.
Have you filed a bug report?
Rene C. mailto:ope...@dokbua.com
Wednesday, January 21, 2015 11:27 AM
The reason I became aware of the problem was that a cpanel servers
started sending this message every morning:
repquota: Can't stat() mounted device /dev/ploop50951p1: No such file
or directory
All containers on another hardware node and several on this have the
devices working correctly within the containers.
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users
Devon B. mailto:devo...@virtualcomplete.com
Wednesday, January 21, 2015 11:11 AM
I can't speak as to how to address the issue, but why do you consider
it messed up? I logged in to a few nodes and saw the same thing on
all of them and I don't remember this being any different in the
past. The ploop device only exists outside of the container (when
mounted). Inside the container is just a reference, no actual device
exists.
I don't know enough about the original issue, what are you trying to
accomplish with the ploop device inside the container?
Rene C. mailto:ope...@dokbua.com
Wednesday, January 21, 2015 6:47 AM
I've gone through all containers and actually some of them work
correctly, only some are messed up like this.
Take for example this one:
[root@server22 ~]# vzctl restart 2201
Restarting container
Stopping container ...
Container was stopped
Unmounting file system at /vz/root/2201
Unmounting device /dev/ploop27939
Container is unmounted
Starting container...
Opening delta /vz/private/2201/root.hdd/root.hdd
Adding delta dev=/dev/ploop27939
img=/vz/private/2201/root.hdd/root.hdd (ro)
Adding delta dev=/dev/ploop27939
img=/vz/private/2201/root.hdd/root.hdd.{7a09b730-f2d6-4b21-b856-0bd6ca420a6e}
(rw)
Mounting /dev/ploop27939p1 at /vz/root/2201 fstype=ext4
data='balloon_ino=12,'
Container is mounted
Adding IP address(es): (redacted)
Setting CPU limit: 400
Setting CPU units: 50
Setting CPUs: 4
Container start in progress...
So apparently the ploop device should be /dev/ploop/27939. Everything
seems to work, inside the container this device is referred by
/proc/mounts
[root@server22 ~]# vzctl exec 2201 cat /proc/mounts
/dev/ploop27939p1 / ext4
rw,relatime,barrier=1,data=ordered,balloon_ino=12 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /dev tmpfs rw,relatime,mode=755 0 0
none /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
But the device is actually missing:
[root@server22 ~]# vzctl exec 2201 ls -l /dev/ploop27939p1
ls: /dev/ploop27939p1: No such file or directory
In fact, there doesn't seem to be ANY /dev/ploop devices in this container
[root@server22 ~]# vzctl exec 2201 ls -l /dev/ploop*
ls: /dev/ploop18940: No such file or directory
ls: /dev/ploop18940p1: No such file or directory
ls: /dev/ploop26517: No such file or directory
ls: /dev/ploop26517p1: No such file or directory
ls: /dev/ploop27379: No such file or directory
ls: /dev/ploop27379p1: No such file or directory
ls: /dev/ploop27939: No such file or directory
ls: /dev/ploop27939p1: No such file or directory
ls: /dev/ploop50951: No such file or directory
ls: /dev/ploop50951p1: No such file or directory
ls: /dev/ploop52860: No such file or directory
ls: /dev/ploop52860p1: No such file or directory
ls: /dev/ploop58415: No such file or directory
ls: /dev/ploop58415p1: No such file or directory
Why does it shows devices when there are none present? Obviously
something is messed up, how can we fix this?
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users
Rene C. mailto:ope...@dokbua.com
Tuesday, January 20, 2015 12:04 PM
No takers?
Re: [Users] simfs with ploop?
A couple have the ploop device and a couple don't*
Devon B. mailto:devo...@virtualcomplete.com
Wednesday, January 21, 2015 11:52 AM
I looked at a few more containers. A couple have the ploop device and
a couple do. I'm not sure why. Most that do have the ploop devices
have a bunch of stale ones. For instance:
# vzctl exec ls -l /dev/ploop*
b-x--- 1 root root 182, 300625 Jan 18 22:57 /dev/ploop18789p1
b-x--- 1 root root 182, 355073 Jan 18 22:57 /dev/ploop22192p1
b-x--- 1 root root 182, 371265 Jan 18 22:57 /dev/ploop23204p1
b-x--- 1 root root 182, 428529 Jan 18 22:57 /dev/ploop26783p1
b-x--- 1 root root 182, 525073 Jan 18 22:57 /dev/ploop32817p1
b-x--- 1 root root 182, 655857 Jan 18 22:57 /dev/ploop40991p1
b-x--- 1 root root 182, 727537 Jan 18 22:57 /dev/ploop45471p1
brw-rw---T 1 root disk 182, 749697 Jan 18 22:57 /dev/ploop46856p1
b-x--- 1 root root 182, 773185 Jan 18 22:57 /dev/ploop48324p1
b-x--- 1 root root 182, 864529 Jan 18 22:57 /dev/ploop54033p1
b-x--- 1 root root 182, 897201 Jan 18 22:57 /dev/ploop56075p1
The active one is pretty obvious (/dev/ploop46856p1).It doesn't
seem to be specific to node or kernel, the containers are split on the
same system.
Have you filed a bug report?
Rene C. mailto:ope...@dokbua.com
Wednesday, January 21, 2015 11:27 AM
The reason I became aware of the problem was that a cpanel servers
started sending this message every morning:
repquota: Can't stat() mounted device /dev/ploop50951p1: No such file
or directory
All containers on another hardware node and several on this have the
devices working correctly within the containers.
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users
Devon B. mailto:devo...@virtualcomplete.com
Wednesday, January 21, 2015 11:11 AM
I can't speak as to how to address the issue, but why do you consider
it messed up? I logged in to a few nodes and saw the same thing on
all of them and I don't remember this being any different in the
past. The ploop device only exists outside of the container (when
mounted). Inside the container is just a reference, no actual device
exists.
I don't know enough about the original issue, what are you trying to
accomplish with the ploop device inside the container?
Rene C. mailto:ope...@dokbua.com
Wednesday, January 21, 2015 6:47 AM
I've gone through all containers and actually some of them work
correctly, only some are messed up like this.
Take for example this one:
[root@server22 ~]# vzctl restart 2201
Restarting container
Stopping container ...
Container was stopped
Unmounting file system at /vz/root/2201
Unmounting device /dev/ploop27939
Container is unmounted
Starting container...
Opening delta /vz/private/2201/root.hdd/root.hdd
Adding delta dev=/dev/ploop27939
img=/vz/private/2201/root.hdd/root.hdd (ro)
Adding delta dev=/dev/ploop27939
img=/vz/private/2201/root.hdd/root.hdd.{7a09b730-f2d6-4b21-b856-0bd6ca420a6e}
(rw)
Mounting /dev/ploop27939p1 at /vz/root/2201 fstype=ext4
data='balloon_ino=12,'
Container is mounted
Adding IP address(es): (redacted)
Setting CPU limit: 400
Setting CPU units: 50
Setting CPUs: 4
Container start in progress...
So apparently the ploop device should be /dev/ploop/27939. Everything
seems to work, inside the container this device is referred by
/proc/mounts
[root@server22 ~]# vzctl exec 2201 cat /proc/mounts
/dev/ploop27939p1 / ext4
rw,relatime,barrier=1,data=ordered,balloon_ino=12 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /dev tmpfs rw,relatime,mode=755 0 0
none /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
But the device is actually missing:
[root@server22 ~]# vzctl exec 2201 ls -l /dev/ploop27939p1
ls: /dev/ploop27939p1: No such file or directory
In fact, there doesn't seem to be ANY /dev/ploop devices in this container
[root@server22 ~]# vzctl exec 2201 ls -l /dev/ploop*
ls: /dev/ploop18940: No such file or directory
ls: /dev/ploop18940p1: No such file or directory
ls: /dev/ploop26517: No such file or directory
ls: /dev/ploop26517p1: No such file or directory
ls: /dev/ploop27379: No such file or directory
ls: /dev/ploop27379p1: No such file or directory
ls: /dev/ploop27939: No such file or directory
ls: /dev/ploop27939p1: No such file or directory
ls: /dev/ploop50951: No such file or directory
ls: /dev/ploop50951p1: No such file or directory
ls: /dev/ploop52860: No such file or directory
ls: /dev/ploop52860p1: No such file or directory
ls: /dev/ploop58415: No such file or directory
ls: /dev/ploop58415p1: No such file or directory
Why does it shows devices when there are none present? Obviously
something is messed up, how can we fix this?
___
Users mailing list
Users@openvz.org
Re: [Users] simfs with ploop?
I've gone through all containers and actually some of them work correctly,
only some are messed up like this.
Take for example this one:
[root@server22 ~]# vzctl restart 2201
Restarting container
Stopping container ...
Container was stopped
Unmounting file system at /vz/root/2201
Unmounting device /dev/ploop27939
Container is unmounted
Starting container...
Opening delta /vz/private/2201/root.hdd/root.hdd
Adding delta dev=/dev/ploop27939 img=/vz/private/2201/root.hdd/root.hdd (ro)
Adding delta dev=/dev/ploop27939
img=/vz/private/2201/root.hdd/root.hdd.{7a09b730-f2d6-4b21-b856-0bd6ca420a6e}
(rw)
Mounting /dev/ploop27939p1 at /vz/root/2201 fstype=ext4
data='balloon_ino=12,'
Container is mounted
Adding IP address(es): (redacted)
Setting CPU limit: 400
Setting CPU units: 50
Setting CPUs: 4
Container start in progress...
So apparently the ploop device should be /dev/ploop/27939. Everything seems
to work, inside the container this device is referred by /proc/mounts
[root@server22 ~]# vzctl exec 2201 cat /proc/mounts
/dev/ploop27939p1 / ext4 rw,relatime,barrier=1,data=ordered,balloon_ino=12
0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /dev tmpfs rw,relatime,mode=755 0 0
none /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
But the device is actually missing:
[root@server22 ~]# vzctl exec 2201 ls -l /dev/ploop27939p1
ls: /dev/ploop27939p1: No such file or directory
In fact, there doesn't seem to be ANY /dev/ploop devices in this container
[root@server22 ~]# vzctl exec 2201 ls -l /dev/ploop*
ls: /dev/ploop18940: No such file or directory
ls: /dev/ploop18940p1: No such file or directory
ls: /dev/ploop26517: No such file or directory
ls: /dev/ploop26517p1: No such file or directory
ls: /dev/ploop27379: No such file or directory
ls: /dev/ploop27379p1: No such file or directory
ls: /dev/ploop27939: No such file or directory
ls: /dev/ploop27939p1: No such file or directory
ls: /dev/ploop50951: No such file or directory
ls: /dev/ploop50951p1: No such file or directory
ls: /dev/ploop52860: No such file or directory
ls: /dev/ploop52860p1: No such file or directory
ls: /dev/ploop58415: No such file or directory
ls: /dev/ploop58415p1: No such file or directory
Why does it shows devices when there are none present? Obviously
something is messed up, how can we fix this?
On Tue, Jan 20, 2015 at 6:04 PM, Rene C. ope...@dokbua.com wrote:
No takers?
On Tue, Jan 13, 2015 at 6:00 PM, Rene C. ope...@dokbua.com wrote:
Hm, well I removed the scripts, now I get the error:
repquota: Can't stat() mounted device /dev/ploop50951p1: No such file or
directory
I don't know if this is related at all, it kinda started after a recent
update to the latest kernel 2.6.32-042stab102.9
Now if I go into any container on this hardware node, the /dev/ploopXXX
devices listed in /proc/mount doesn't exist.
For example:
root@vps2202 [~]# cat /proc/mounts
/dev/ploop50951p1 / ext4
rw,relatime,barrier=1,stripe=256,data=ordered,balloon_ino=12,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group
0 0
/dev/simfs /backup simfs rw,relatime 0 0
proc /proc proc rw,relatime 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /dev tmpfs rw,relatime,size=7992992k,nr_inodes=1998248 0 0
none /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
root@vps2202 [~]# ll /dev/ploop50951p1
/bin/ls: /dev/ploop50951p1: No such file or directory
There are quite a few /dev/ploop* devices under /dev, but not the one
linked in /proc/mounts.
This goes for all containers on this hardware node. Other nodes not yet
upgraded to the latest kernel do not have this problem.
Any ideas?
On Sat, Dec 27, 2014 at 12:31 AM, Kir Kolyshkin k...@openvz.org wrote:
On 12/26/2014 09:46 AM, Scott Dowdle wrote:
Greetings,
- Original Message -
I'm still waiting to hear what is the PROPER way of discarding this
script. Just deleting the base file will cause a large number of
symlinks to become orphans.
What I understood Kir to say was that the script was created as part of
the conversion process and should have been automatically removed (like it
was automaically created) after the conversion was complete. Why it wasn't
removed I don't know... but you can back up the file somewhere else... and
remove it... and if you have problems... you could copy it back. I don't
think any of that would be necessary but who knows.
No, the script (and its appropriate symlinks) is (re)created on every
start (actually mount)
of a simfs-based container. It is a conversion process that should get
rid of it, unfortunately
vzctl doesn't do it currently, so has to be done manually. Feel free to
file a bug for vzctl.
Kir.
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users
Re: [Users] simfs with ploop?
Hm, well I removed the scripts, now I get the error: repquota: Can't stat() mounted device /dev/ploop50951p1: No such file or directory I don't know if this is related at all, it kinda started after a recent update to the latest kernel 2.6.32-042stab102.9 Now if I go into any container on this hardware node, the /dev/ploopXXX devices listed in /proc/mount doesn't exist. For example: root@vps2202 [~]# cat /proc/mounts /dev/ploop50951p1 / ext4 rw,relatime,barrier=1,stripe=256,data=ordered,balloon_ino=12,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group 0 0 /dev/simfs /backup simfs rw,relatime 0 0 proc /proc proc rw,relatime 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0 sysfs /sys sysfs rw,relatime 0 0 none /dev tmpfs rw,relatime,size=7992992k,nr_inodes=1998248 0 0 none /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0 root@vps2202 [~]# ll /dev/ploop50951p1 /bin/ls: /dev/ploop50951p1: No such file or directory There are quite a few /dev/ploop* devices under /dev, but not the one linked in /proc/mounts. This goes for all containers on this hardware node. Other nodes not yet upgraded to the latest kernel do not have this problem. Any ideas? On Sat, Dec 27, 2014 at 12:31 AM, Kir Kolyshkin k...@openvz.org wrote: On 12/26/2014 09:46 AM, Scott Dowdle wrote: Greetings, - Original Message - I'm still waiting to hear what is the PROPER way of discarding this script. Just deleting the base file will cause a large number of symlinks to become orphans. What I understood Kir to say was that the script was created as part of the conversion process and should have been automatically removed (like it was automaically created) after the conversion was complete. Why it wasn't removed I don't know... but you can back up the file somewhere else... and remove it... and if you have problems... you could copy it back. I don't think any of that would be necessary but who knows. No, the script (and its appropriate symlinks) is (re)created on every start (actually mount) of a simfs-based container. It is a conversion process that should get rid of it, unfortunately vzctl doesn't do it currently, so has to be done manually. Feel free to file a bug for vzctl. Kir. ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
Re: [Users] simfs with ploop?
I'm still waiting to hear what is the PROPER way of discarding this
script. Just deleting the base file will cause a large number of symlinks
to become orphans.
rpm reports that the script isn't owned by any package -
# rpm -qf /etc/rc.d/init.d/vzquota
file /etc/rc.d/init.d/vzquota is not owned by any package
- so how did it get installed in the first place? If I understand you
right it might be created by vzctl? Is there a command in vzctl to remove
it? Should vzctl convert --layout ploop not automatically remove it? If
it doesn't, is that a bug that should be reported somewhere?
On Fri, Dec 5, 2014 at 1:36 AM, Kir Kolyshkin k...@openvz.org wrote:
I think the script left after conversion. It is no longer needed,
you can remove it (and as far as I can tell it won't be recreated
by vzctl if ploop is used).
On 12/04/2014 02:22 PM, Rene C. wrote:
It seems /etc/rc.d/init.d/vzquota somehow is responsible for this
problem:
# cat -n /etc/rc.d/init.d/vzquota
1 #!/bin/sh
2 # chkconfig: 2345 10 90
3 # description: prepare container to use OpenVZ 2nd-level disk
quotas
4
5 ### BEGIN INIT INFO
6 # Provides: vzquota
7 # Required-Start: $local_fs $time $syslog
8 # Required-Stop: $local_fs
9 # Default-Start: 2 3 4 5
10 # Default-Stop: 0 1 6
11 # Short-Description: Start vzquota at the end of boot
12 # Description: Configure OpenVZ disk quota for a container.
13 ### END INIT INFO
14
15 start() {
16 if [ ! -L /etc/mtab ]; then
17 rm -f /etc/mtab /dev/null 21
18 ln -sf /proc/mounts /etc/mtab
19 fi
20 dev=$(awk '($2 == /) ($4 ~ /usrquota/) ($4 ~
/grpquota/) {print $1}' /etc/mtab)
21 if test -z $dev; then
22 dev=/dev/simfs
23 rm -f /etc/mtab /dev/null 21
24 echo /dev/simfs / reiserfs rw,usrquota,grpquota 0
0 /etc/mtab
25 grep -v / /proc/mounts /etc/mtab 2/dev/null
26 chmod 644 /etc/mtab
27 fi
28 [ -e $dev ] || mknod $dev b 0 60
29 quotaon -aug
30 }
31
32 case $1 in
33start)
34 start
35 ;;
36*)
37 exit
38 esac
So it seems in line 16-19 first the symlink from /proc/mounts to
/etc/mtab is made correctly, but then in line 20 the '/' partition is
checked for keywords /usrquota/ and /grpquota/, and if they're missing it
then overwrites the symlink again. AFAICS this is what is breaking the
symlink.
Whats the problem with this? Should this script be changed for ploop
containers?
On Sun, Nov 30, 2014 at 12:07 PM, Rene C. ope...@dokbua.com wrote:
I've just noticed this happen also in a Plesk container, so it's not just
limited to Cpanel. The date seems to correspond to a restore that was made
so it may be related to the vzpbackup/vzprestore scripts.
On Sat, Jan 4, 2014 at 8:34 AM, Rene C. ope...@dokbua.com wrote:
Oddly enough this problem has returned - it now shows simfs again.
Nobody has explicitly changed anything. The container runs Cpanel,
could that have messed things up? It actually looks like cpanel
overrides the symlink when they add their jailshell. Have you noticed
this before?
/proc/mounts looks correct.
On Wed, Dec 18, 2013 at 10:25 AM, Rene C. ope...@dokbua.com wrote:
Thanks, now I understand.
So after deleting /etc/mtab I need to make as symlink from
/proc/mounts (ln -s /proc/mounts /etc/mtab). That was the bit I was
missing.
On Wed, Dec 18, 2013 at 1:36 AM, Kir Kolyshkin k...@openvz.org wrote:
On 12/17/2013 12:27 AM, Rene C. wrote:
Sure
# ls -l /vza1/private/1703
total 16
drwxr-xr-x 2 root root 4096 Dec 15 04:10 dump
drwx-- 3 root root 4096 Dec 15 04:10 root.hdd
-rw-r--r-- 1 root root 443 Dec 15 04:09 Snapshots.xml
-rw-r--r-- 1 root root 37 Dec 15 03:06 vzpbackup_snapshot
# vzlist -o layout 1703
LAYOUT
ploop
#
Surely deleting the mount table isn't healthy, isn't it needed by
something?
This is how it should look like:
[host] # vzctl enter 1018
entered into CT 1018
[CT1018] # ls -l /etc/mtab
lrwxrwxrwx 1 root root 12 Nov 7 21:20 /etc/mtab - /proc/mounts
And /proc/mounts is showing info from the kernel which can't be wrong:
[CT1018]# cat /proc/mounts
/dev/ploop51540p1 / ext4
rw,relatime,barrier=1,data=ordered,balloon_ino=12 0
0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /dev devtmpfs rw,relatime,mode=755 0 0
none /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0
none /dev/shm tmpfs rw,relatime 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
On Tue, Dec 17, 2013 at 9:41 AM, Kir Kolyshkin k...@openvz.org
wrote:
On 12/16/2013 04:51 PM, Rene C. wrote:
I tried just
Re: [Users] simfs with ploop?
Greetings, - Original Message - I'm still waiting to hear what is the PROPER way of discarding this script. Just deleting the base file will cause a large number of symlinks to become orphans. What I understood Kir to say was that the script was created as part of the conversion process and should have been automatically removed (like it was automaically created) after the conversion was complete. Why it wasn't removed I don't know... but you can back up the file somewhere else... and remove it... and if you have problems... you could copy it back. I don't think any of that would be necessary but who knows. TYL, -- Scott Dowdle 704 Church Street Belgrade, MT 59714 (406)388-0827 [home] (406)994-3931 [work] ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
Re: [Users] simfs with ploop?
On 12/26/2014 09:46 AM, Scott Dowdle wrote: Greetings, - Original Message - I'm still waiting to hear what is the PROPER way of discarding this script. Just deleting the base file will cause a large number of symlinks to become orphans. What I understood Kir to say was that the script was created as part of the conversion process and should have been automatically removed (like it was automaically created) after the conversion was complete. Why it wasn't removed I don't know... but you can back up the file somewhere else... and remove it... and if you have problems... you could copy it back. I don't think any of that would be necessary but who knows. No, the script (and its appropriate symlinks) is (re)created on every start (actually mount) of a simfs-based container. It is a conversion process that should get rid of it, unfortunately vzctl doesn't do it currently, so has to be done manually. Feel free to file a bug for vzctl. Kir. ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
Re: [Users] simfs with ploop?
It seems /etc/rc.d/init.d/vzquota somehow is responsible for this problem:
# cat -n /etc/rc.d/init.d/vzquota
1 #!/bin/sh
2 # chkconfig: 2345 10 90
3 # description: prepare container to use OpenVZ 2nd-level disk quotas
4
5 ### BEGIN INIT INFO
6 # Provides: vzquota
7 # Required-Start: $local_fs $time $syslog
8 # Required-Stop: $local_fs
9 # Default-Start: 2 3 4 5
10 # Default-Stop: 0 1 6
11 # Short-Description: Start vzquota at the end of boot
12 # Description: Configure OpenVZ disk quota for a container.
13 ### END INIT INFO
14
15 start() {
16 if [ ! -L /etc/mtab ]; then
17 rm -f /etc/mtab /dev/null 21
18 ln -sf /proc/mounts /etc/mtab
19 fi
20 dev=$(awk '($2 == /) ($4 ~ /usrquota/) ($4 ~
/grpquota/) {print $1}' /etc/mtab)
21 if test -z $dev; then
22 dev=/dev/simfs
23 rm -f /etc/mtab /dev/null 21
24 echo /dev/simfs / reiserfs rw,usrquota,grpquota 0
0 /etc/mtab
25 grep -v / /proc/mounts /etc/mtab 2/dev/null
26 chmod 644 /etc/mtab
27 fi
28 [ -e $dev ] || mknod $dev b 0 60
29 quotaon -aug
30 }
31
32 case $1 in
33start)
34 start
35 ;;
36*)
37 exit
38 esac
So it seems in line 16-19 first the symlink from /proc/mounts to /etc/mtab
is made correctly, but then in line 20 the '/' partition is checked for
keywords /usrquota/ and /grpquota/, and if they're missing it then
overwrites the symlink again. AFAICS this is what is breaking the symlink.
Whats the problem with this? Should this script be changed for ploop
containers?
On Sun, Nov 30, 2014 at 12:07 PM, Rene C. ope...@dokbua.com wrote:
I've just noticed this happen also in a Plesk container, so it's not just
limited to Cpanel. The date seems to correspond to a restore that was made
so it may be related to the vzpbackup/vzprestore scripts.
On Sat, Jan 4, 2014 at 8:34 AM, Rene C. ope...@dokbua.com wrote:
Oddly enough this problem has returned - it now shows simfs again.
Nobody has explicitly changed anything. The container runs Cpanel,
could that have messed things up? It actually looks like cpanel
overrides the symlink when they add their jailshell. Have you noticed
this before?
/proc/mounts looks correct.
On Wed, Dec 18, 2013 at 10:25 AM, Rene C. ope...@dokbua.com wrote:
Thanks, now I understand.
So after deleting /etc/mtab I need to make as symlink from
/proc/mounts (ln -s /proc/mounts /etc/mtab). That was the bit I was
missing.
On Wed, Dec 18, 2013 at 1:36 AM, Kir Kolyshkin k...@openvz.org wrote:
On 12/17/2013 12:27 AM, Rene C. wrote:
Sure
# ls -l /vza1/private/1703
total 16
drwxr-xr-x 2 root root 4096 Dec 15 04:10 dump
drwx-- 3 root root 4096 Dec 15 04:10 root.hdd
-rw-r--r-- 1 root root 443 Dec 15 04:09 Snapshots.xml
-rw-r--r-- 1 root root 37 Dec 15 03:06 vzpbackup_snapshot
# vzlist -o layout 1703
LAYOUT
ploop
#
Surely deleting the mount table isn't healthy, isn't it needed by
something?
This is how it should look like:
[host] # vzctl enter 1018
entered into CT 1018
[CT1018] # ls -l /etc/mtab
lrwxrwxrwx 1 root root 12 Nov 7 21:20 /etc/mtab - /proc/mounts
And /proc/mounts is showing info from the kernel which can't be wrong:
[CT1018]# cat /proc/mounts
/dev/ploop51540p1 / ext4
rw,relatime,barrier=1,data=ordered,balloon_ino=12 0
0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /dev devtmpfs rw,relatime,mode=755 0 0
none /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0
none /dev/shm tmpfs rw,relatime 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
On Tue, Dec 17, 2013 at 9:41 AM, Kir Kolyshkin k...@openvz.org
wrote:
On 12/16/2013 04:51 PM, Rene C. wrote:
I tried just removing it, does not seem to fix anything. Need to do
anything else? Remount, restart, anything?
Would be great if you can copy-paste some output from the terminal,
otherwise it's more complicated to debug.
Maybe your CT was not really converted.
Please show output of
ls -l /vz/private/1703/
vzlist -o layout 1703
On Thu, Dec 12, 2013 at 11:43 AM, Rene C. ope...@dokbua.com wrote:
Ok thanks. Just remove it, nothing else? Need to restart the
container or anything?
On Thu, Dec 12, 2013 at 10:02 AM, Kir Kolyshkin k...@openvz.org
wrote:
On 12/11/2013 06:28 PM, Rene C. wrote:
I just noticed there is a contaner on one of our hardware nodes
that
appears to have been changed to ploop, but the filesystem is
still
simfs:
# vzctl exec 1703 df -h
FilesystemSize Used Avail Use% Mounted on
/dev/simfs 99G 65G 29G 70% /
none
Re: [Users] simfs with ploop?
I've just noticed this happen also in a Plesk container, so it's not just limited to Cpanel. The date seems to correspond to a restore that was made so it may be related to the vzpbackup/vzprestore scripts. On Sat, Jan 4, 2014 at 8:34 AM, Rene C. ope...@dokbua.com wrote: Oddly enough this problem has returned - it now shows simfs again. Nobody has explicitly changed anything. The container runs Cpanel, could that have messed things up? It actually looks like cpanel overrides the symlink when they add their jailshell. Have you noticed this before? /proc/mounts looks correct. On Wed, Dec 18, 2013 at 10:25 AM, Rene C. ope...@dokbua.com wrote: Thanks, now I understand. So after deleting /etc/mtab I need to make as symlink from /proc/mounts (ln -s /proc/mounts /etc/mtab). That was the bit I was missing. On Wed, Dec 18, 2013 at 1:36 AM, Kir Kolyshkin k...@openvz.org wrote: On 12/17/2013 12:27 AM, Rene C. wrote: Sure # ls -l /vza1/private/1703 total 16 drwxr-xr-x 2 root root 4096 Dec 15 04:10 dump drwx-- 3 root root 4096 Dec 15 04:10 root.hdd -rw-r--r-- 1 root root 443 Dec 15 04:09 Snapshots.xml -rw-r--r-- 1 root root 37 Dec 15 03:06 vzpbackup_snapshot # vzlist -o layout 1703 LAYOUT ploop # Surely deleting the mount table isn't healthy, isn't it needed by something? This is how it should look like: [host] # vzctl enter 1018 entered into CT 1018 [CT1018] # ls -l /etc/mtab lrwxrwxrwx 1 root root 12 Nov 7 21:20 /etc/mtab - /proc/mounts And /proc/mounts is showing info from the kernel which can't be wrong: [CT1018]# cat /proc/mounts /dev/ploop51540p1 / ext4 rw,relatime,barrier=1,data=ordered,balloon_ino=12 0 0 proc /proc proc rw,relatime 0 0 sysfs /sys sysfs rw,relatime 0 0 none /dev devtmpfs rw,relatime,mode=755 0 0 none /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0 none /dev/shm tmpfs rw,relatime 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0 On Tue, Dec 17, 2013 at 9:41 AM, Kir Kolyshkin k...@openvz.org wrote: On 12/16/2013 04:51 PM, Rene C. wrote: I tried just removing it, does not seem to fix anything. Need to do anything else? Remount, restart, anything? Would be great if you can copy-paste some output from the terminal, otherwise it's more complicated to debug. Maybe your CT was not really converted. Please show output of ls -l /vz/private/1703/ vzlist -o layout 1703 On Thu, Dec 12, 2013 at 11:43 AM, Rene C. ope...@dokbua.com wrote: Ok thanks. Just remove it, nothing else? Need to restart the container or anything? On Thu, Dec 12, 2013 at 10:02 AM, Kir Kolyshkin k...@openvz.org wrote: On 12/11/2013 06:28 PM, Rene C. wrote: I just noticed there is a contaner on one of our hardware nodes that appears to have been changed to ploop, but the filesystem is still simfs: # vzctl exec 1703 df -h FilesystemSize Used Avail Use% Mounted on /dev/simfs 99G 65G 29G 70% / none 1.0G 4.0K 1.0G 1% /dev # vzctl convert 1703 CT is already on ploop All other containers use a /dev/ploop device. Is this a problem? Should it be fixed? How? I guess this is caused by a record in CT's /etc/mtab. This should be harmful. If you want to fix it, just remove CT's /etc/mtab ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
Re: [Users] simfs with ploop?
On 01/03/2014 11:34 PM, Rene C. wrote: Oddly enough this problem has returned - it now shows simfs again. Nobody has explicitly changed anything. The container runs Cpanel, could that have messed things up? It actually looks like cpanel overrides the symlink when they add their jailshell. Have you noticed this before? /proc/mounts looks correct. Yes it is probably CPanel. You should ask them about it directly I guess. ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
Re: [Users] simfs with ploop?
Oddly enough this problem has returned - it now shows simfs again. Nobody has explicitly changed anything. The container runs Cpanel, could that have messed things up? It actually looks like cpanel overrides the symlink when they add their jailshell. Have you noticed this before? /proc/mounts looks correct. On Wed, Dec 18, 2013 at 10:25 AM, Rene C. ope...@dokbua.com wrote: Thanks, now I understand. So after deleting /etc/mtab I need to make as symlink from /proc/mounts (ln -s /proc/mounts /etc/mtab). That was the bit I was missing. On Wed, Dec 18, 2013 at 1:36 AM, Kir Kolyshkin k...@openvz.org wrote: On 12/17/2013 12:27 AM, Rene C. wrote: Sure # ls -l /vza1/private/1703 total 16 drwxr-xr-x 2 root root 4096 Dec 15 04:10 dump drwx-- 3 root root 4096 Dec 15 04:10 root.hdd -rw-r--r-- 1 root root 443 Dec 15 04:09 Snapshots.xml -rw-r--r-- 1 root root 37 Dec 15 03:06 vzpbackup_snapshot # vzlist -o layout 1703 LAYOUT ploop # Surely deleting the mount table isn't healthy, isn't it needed by something? This is how it should look like: [host] # vzctl enter 1018 entered into CT 1018 [CT1018] # ls -l /etc/mtab lrwxrwxrwx 1 root root 12 Nov 7 21:20 /etc/mtab - /proc/mounts And /proc/mounts is showing info from the kernel which can't be wrong: [CT1018]# cat /proc/mounts /dev/ploop51540p1 / ext4 rw,relatime,barrier=1,data=ordered,balloon_ino=12 0 0 proc /proc proc rw,relatime 0 0 sysfs /sys sysfs rw,relatime 0 0 none /dev devtmpfs rw,relatime,mode=755 0 0 none /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0 none /dev/shm tmpfs rw,relatime 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0 On Tue, Dec 17, 2013 at 9:41 AM, Kir Kolyshkin k...@openvz.org wrote: On 12/16/2013 04:51 PM, Rene C. wrote: I tried just removing it, does not seem to fix anything. Need to do anything else? Remount, restart, anything? Would be great if you can copy-paste some output from the terminal, otherwise it's more complicated to debug. Maybe your CT was not really converted. Please show output of ls -l /vz/private/1703/ vzlist -o layout 1703 On Thu, Dec 12, 2013 at 11:43 AM, Rene C. ope...@dokbua.com wrote: Ok thanks. Just remove it, nothing else? Need to restart the container or anything? On Thu, Dec 12, 2013 at 10:02 AM, Kir Kolyshkin k...@openvz.org wrote: On 12/11/2013 06:28 PM, Rene C. wrote: I just noticed there is a contaner on one of our hardware nodes that appears to have been changed to ploop, but the filesystem is still simfs: # vzctl exec 1703 df -h FilesystemSize Used Avail Use% Mounted on /dev/simfs 99G 65G 29G 70% / none 1.0G 4.0K 1.0G 1% /dev # vzctl convert 1703 CT is already on ploop All other containers use a /dev/ploop device. Is this a problem? Should it be fixed? How? I guess this is caused by a record in CT's /etc/mtab. This should be harmful. If you want to fix it, just remove CT's /etc/mtab ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
Re: [Users] simfs with ploop?
On 12/17/2013 12:27 AM, Rene C. wrote: Sure # ls -l /vza1/private/1703 total 16 drwxr-xr-x 2 root root 4096 Dec 15 04:10 dump drwx-- 3 root root 4096 Dec 15 04:10 root.hdd -rw-r--r-- 1 root root 443 Dec 15 04:09 Snapshots.xml -rw-r--r-- 1 root root 37 Dec 15 03:06 vzpbackup_snapshot # vzlist -o layout 1703 LAYOUT ploop # Surely deleting the mount table isn't healthy, isn't it needed by something? This is how it should look like: [host] # vzctl enter 1018 entered into CT 1018 [CT1018] # ls -l /etc/mtab lrwxrwxrwx 1 root root 12 Nov 7 21:20 /etc/mtab - /proc/mounts And /proc/mounts is showing info from the kernel which can't be wrong: [CT1018]# cat /proc/mounts /dev/ploop51540p1 / ext4 rw,relatime,barrier=1,data=ordered,balloon_ino=12 0 0 proc /proc proc rw,relatime 0 0 sysfs /sys sysfs rw,relatime 0 0 none /dev devtmpfs rw,relatime,mode=755 0 0 none /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0 none /dev/shm tmpfs rw,relatime 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0 On Tue, Dec 17, 2013 at 9:41 AM, Kir Kolyshkin k...@openvz.org wrote: On 12/16/2013 04:51 PM, Rene C. wrote: I tried just removing it, does not seem to fix anything. Need to do anything else? Remount, restart, anything? Would be great if you can copy-paste some output from the terminal, otherwise it's more complicated to debug. Maybe your CT was not really converted. Please show output of ls -l /vz/private/1703/ vzlist -o layout 1703 On Thu, Dec 12, 2013 at 11:43 AM, Rene C. ope...@dokbua.com wrote: Ok thanks. Just remove it, nothing else? Need to restart the container or anything? On Thu, Dec 12, 2013 at 10:02 AM, Kir Kolyshkin k...@openvz.org wrote: On 12/11/2013 06:28 PM, Rene C. wrote: I just noticed there is a contaner on one of our hardware nodes that appears to have been changed to ploop, but the filesystem is still simfs: # vzctl exec 1703 df -h FilesystemSize Used Avail Use% Mounted on /dev/simfs 99G 65G 29G 70% / none 1.0G 4.0K 1.0G 1% /dev # vzctl convert 1703 CT is already on ploop All other containers use a /dev/ploop device. Is this a problem? Should it be fixed? How? I guess this is caused by a record in CT's /etc/mtab. This should be harmful. If you want to fix it, just remove CT's /etc/mtab ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
Re: [Users] simfs with ploop?
Thanks, now I understand. So after deleting /etc/mtab I need to make as symlink from /proc/mounts (ln -s /proc/mounts /etc/mtab). That was the bit I was missing. On Wed, Dec 18, 2013 at 1:36 AM, Kir Kolyshkin k...@openvz.org wrote: On 12/17/2013 12:27 AM, Rene C. wrote: Sure # ls -l /vza1/private/1703 total 16 drwxr-xr-x 2 root root 4096 Dec 15 04:10 dump drwx-- 3 root root 4096 Dec 15 04:10 root.hdd -rw-r--r-- 1 root root 443 Dec 15 04:09 Snapshots.xml -rw-r--r-- 1 root root 37 Dec 15 03:06 vzpbackup_snapshot # vzlist -o layout 1703 LAYOUT ploop # Surely deleting the mount table isn't healthy, isn't it needed by something? This is how it should look like: [host] # vzctl enter 1018 entered into CT 1018 [CT1018] # ls -l /etc/mtab lrwxrwxrwx 1 root root 12 Nov 7 21:20 /etc/mtab - /proc/mounts And /proc/mounts is showing info from the kernel which can't be wrong: [CT1018]# cat /proc/mounts /dev/ploop51540p1 / ext4 rw,relatime,barrier=1,data=ordered,balloon_ino=12 0 0 proc /proc proc rw,relatime 0 0 sysfs /sys sysfs rw,relatime 0 0 none /dev devtmpfs rw,relatime,mode=755 0 0 none /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0 none /dev/shm tmpfs rw,relatime 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0 On Tue, Dec 17, 2013 at 9:41 AM, Kir Kolyshkin k...@openvz.org wrote: On 12/16/2013 04:51 PM, Rene C. wrote: I tried just removing it, does not seem to fix anything. Need to do anything else? Remount, restart, anything? Would be great if you can copy-paste some output from the terminal, otherwise it's more complicated to debug. Maybe your CT was not really converted. Please show output of ls -l /vz/private/1703/ vzlist -o layout 1703 On Thu, Dec 12, 2013 at 11:43 AM, Rene C. ope...@dokbua.com wrote: Ok thanks. Just remove it, nothing else? Need to restart the container or anything? On Thu, Dec 12, 2013 at 10:02 AM, Kir Kolyshkin k...@openvz.org wrote: On 12/11/2013 06:28 PM, Rene C. wrote: I just noticed there is a contaner on one of our hardware nodes that appears to have been changed to ploop, but the filesystem is still simfs: # vzctl exec 1703 df -h FilesystemSize Used Avail Use% Mounted on /dev/simfs 99G 65G 29G 70% / none 1.0G 4.0K 1.0G 1% /dev # vzctl convert 1703 CT is already on ploop All other containers use a /dev/ploop device. Is this a problem? Should it be fixed? How? I guess this is caused by a record in CT's /etc/mtab. This should be harmful. If you want to fix it, just remove CT's /etc/mtab ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
