On 07/22/2014 02:44 PM, Kevin Holly wrote:
> Hi again,
>
> I just tried to reinstall this container...
> The log of that can be found here:
> https://ezcrypt.it/Hd9n#SiP14ajsc8sV0SLiGm1diEc1
The only strange thing I see is "Killing container", perhaps you use an
incorrect
sequence for vzctl set --
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi again,
I just tried to reinstall this container...
The log of that can be found here:
https://ezcrypt.it/Hd9n#SiP14ajsc8sV0SLiGm1diEc1
There is not much difference with the ploop filesystem now. Same size
(2TB but only 219GiB/235GB available) and
This might be of some help, in the sense of how CPU usage is
calculated. It seems to be accurate from the testing I have done, but
I don't claim to be a professional programmer or have covered all test
cases.
https://gist.github.com/microlinux/0b3f47cb657cb61bb89b
On Tue, Jul 22, 2014 at 12:30 AM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I have a customer complaining about his filesystem being too small
(product FS size: 250GB, his FS size: 219GiB / 235GB).
After further debugging this issue I am now here:
Creation of the containers filesystem (I can provide more logs, by
defau
Pablo Silva writes:
> Hi CoolCold!
> Risk is: for example, I'm upgrading a 6.x server centos having a openvz
> kernel, for some reason when I do yum update shows me an update of the
> native kernel centos 6.x + openvz kernel update, my question is : who
> wins, if he wins the upgrade kernel cen
Hi,
On Mon, Jul 21, 2014 at 05:06:04PM +0200, Pavel Snajdr wrote:
> We were trying to figure this out from /proc/vz/vestat, first try was to
> divide used/idle, but idle seems to be accounted for all available
> hwnode CPUs and used seems to be accounted for CPUs available to the CT;
It's a bug -
