New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Had the near same issue before. The permissions for our templates were fucked up, yet media sync still "synced" them, despite not even being able to write to the destination.....
Please report it to solusvm
I gave up syncing templates long time ago. Now i just NFS mount the templates directory.
@rds100 Yepp, i using GlusterFS on 4 nodes to provide the templates. We had often problems with the sync function..
I do scp of the template folder from the main node to the slave node.It works great for me
OpenVZ just released new templates on March 15th. I'm running several instances of various distros on my HWN's. The OP's errors generally occur when there are no values set in /proc/user_beancounters on the node itself. If the OP is running RHEL5 these values are required for vzctl to start the container. If you're running RHEL6/VSwap kernel, 90% of the UBC parameters are set as 'unlimited'. I don't see how the templates could be corrupt. It sounds more like your /etc/vz/vz.conf is not specifying the correct path to /vz/template or is not configured with correct default values. That would easily cause all containers on the HWN to crash.
Defaults for containers
VE_ROOT=/vz/root/$VEID
VE_PRIVATE=/vz/private/$VEID
CONFIGFILE="vswap-256m"
DEF_OSTEMPLATE="centos6-x86_64"
Template sync works fine with the addition of forcing a manual sync or at least issuing 'chown root.root /vz/template/cache/*" so that the filesystem is configured with correct UID/GID values when the VE is built. Have you verified your UBC parameters even though the issue is evidently resolved?
What version of SolusVM are you running on your nodes? 1.3.13 has been stable since November. 1.3.12 was pulled almost immediately after an XSS vuln was discovered a week before that. Suggest a /scripts/sysfix from CLI as a precaution -- good luck.
@jarland
?
@shovenose
@AnthonySmith I will be reporting this to them!
@shovenose
He can't hear you, @SimpleNode. He's banned!
lol
You're using the non-Solus version (i.e: Standalone) OVZ and trying to control it with Solus
@Wintereise please explain i thought that the install script from solus would have installed the right one. Although it is working after i added the templates manually I would be interested to know why you think that it is standalone.
Yay! Congrats lol
Happened to me a few weeks ago, a few went corrupt then all of them eventually changed to the same filesize. Kinda annoyed about it as it was difficult enough trying to break through the techs English barrier at Solus.
Usually happens if you have a previous install. The Solus forum has quite a bit of info on it.
(And I actually tried it out once, produces the exact same type of errors)
Templates shouldn't be causing parameter errors though (Templates have nothing to do with VE parameters), seems like something else was broken which the script that syncs templates fixed.
My best guess is that the errors flowed from continuing to attempt to make a container at /vz/private/CTID that didn't exist because the template wouldn't extract. At the CLI level it threw back tar errors saying they weren't valid archives. Sort of a misleading domino effect. Vzctl errors made much more sense than SolusVM's in this case.
I know this is bringing up an old topic, but I am having the same problem as the OP. It seems that when I try and deploy a different template other than the original CentOS template that ships with Solus, the /vz/private/ directory doesn't get created so the server can't function. I've tried downloading templates from the Solus TDN, as well as from outside sources (openvz.org), and none of them will deploy for me. I tried changing the permissions on the /vz/private directory, but that shouldn't be an issue because the original template applies just fine.
The only thing I noticed different between the original template and the uploaded template, was how the ls -l looked:
Original template:
-rw-r--r--.
Uploaded template:
-rw-r--r--
Haven't ever run into that . on the end before, so I am not entirely sure what to search for to try and find the issue. Any thoughts before I try reloading the OS and Solus?
EDIT: Apparently the . after the file permissions denotes something that has an ACL with SELinux, whether it is enabled or not.
What error do you get if you try to create a container from terminal bypassing solusvm entirely?
It seems to work just fine when I do it all in the command line.
vzctl create 100 --ostemplate ubuntu-12.10-x86_64
Creating container private area (ubuntu-12.10-x86_64)
Performing postcreate actions
CT configuration saved to /etc/vz/conf/100.conf
Container private area was created
vzctl start 100
Starting container...
Container is mounted
Went ahead and created a new VM and reinstalled CentOS and Solus, everything seems to be working. Unfortunately didn't find the cause of the problem, most likely messed something up during config.