Here you go, this is why my initial post likely exists - because I cannot just install a CentOS container image from cloudmin unless it comes from Virtualmin - one of the CentOS 6.0 (outdated) images.
Please explain why this error affects all attempts to install any OpenVZ image (even a backup from a prior Virtualmin/Webmin install) fails instantly. If this issue is resolved, I suspect the weird RAM changing issue will go away. My belief it is because of the insane process of updating a 6.0 image to 6.7 W/OpenVZ kernel.
Creating container private area (cloudmin-10000)
/usr/libexec/vzctl/scripts/vps-create: line 86: [: 0.0498047: integer expression expected
vps-create ERROR: Insufficient disk space in /vz/private/10000.tmp; available: 210892660, needed: 0.0498047
Creation of container private area failed
Thank you in advance, I am attempting an entirely new install once again and this issue always arises. The base OS is Centos 6.7 with OpenVZ kernel tools and all that is required for an OpenVZ host container. Thanks in advance,
Douglas
Howdy,
Hmm, it looks like you're receiving a disk space related error.
What is the output of this command:
df -hAlso, how large is that OpenVZ image that you're trying to install/restore?
-Eric
Well where I am now is I had to give up entirely on installing any prefabed images provided by Cloudmin's list because they are so old that the update process to CentOS 6.7, where yum and such will take it to and the Webmin/Virtualmin update after update surely is what makes even your images fail. Yet they are the only ones that do not give the bogus RAM failure like my .tar.gz backup (useless) and anything from OpenVZ too.
So, lol after purchasing Cloudmin to manage and accelerate things, I have a week in having to entirely install the systems once again. There was and now is nothing strange about df -h:
(This is what things look like right now, but were set up identically before.---> first things I started checking)
Filesystem Size Used Avail Use% Mounted on/dev/sda1 59G 4.2G 52G 8% /
tmpfs 12G 0 12G 0% /dev/shm
/dev/sda3 212G 8.0G 194G 4% /vz
I am not certain what caused the weird instant RAM failure on installs, but while I do not have time now as I am totally down, if you would like I am pretty certain I can replicate the bug easily - just not today. :-)
So how did I move forward? Lucky me knows OpenVZ inside and out and wrote up all the scripts to make containers, install and save them, which was a pain. The issue on your end with cloning has to do with Cloudmin looking for the clone's config file and what it is looking for like xyz1-clone-10001 which never gets made during the clone process and the OpenVZ has a fit and defers to a default file that contains nothing related to the config file needed (regardless its name.)
So I need some time but I will produce the bug for you. This has been very agitating to have to do everything in a terminal as part of OpenVZ's instruction set. Cloning would be the cat's meow if it worked - and as well I still do not understand why the "out of the box" images offered by you of OpenVZ CentOS 6 are of 6.0 and even if updating the OS goes fine as it should, Cloudmin and Virtualmin/Webmin get hosed going through one update after another to bring them current. Anyway, I'll get back with you with a bug report. Sadly I have to post another odd question above here again.
Douglas
This was reason two for having to give up on Cloudmin as no more than a statistics provider. I assume something was getting messed up during all of the updates Cloudmin/Virtualmin/Webmin were having to undergo to become current. This was I won't say the last straw as I am no "angered" as such, frustrated, uhm yes... But after 6 or 8 go arounds with one of the three systems changing container RAM sizes after any reboot, I decided I was going to just have to do everything manually. With an up to date Install of CentOS 6.7 x64, OpenVZ kernel, tools and the like I was able to build and install everything manually. Post link is below. I "think" in the end I found out "why" the RAM was changing, but not what was causing it and how to handle it; a genuine bug in every install I am afraid.. One of the three products was referring to a non-existent config file that I only really noticed the different hierarchy doing everything manually with OpenVZ. I will likely be able to replicate that too later when I have some time on my hands.
https://www.virtualmin.com/node/38496
Douglas