Re: [Users] error using vi in VE but no beans?
Steve Hodges wrote: On 27/08/2007 9:16 AM, Gregor Mosheh wrote: Steve Hodges wrote: E297: Write error in swap file E303: Unable to open swap file for rc.local, recovery impossible rc.local 17 lines, 387 characters That's vi saying that it can't save a backup of the file (yeah, swap file really intuitive) That's probably just a permissions issue. Are you able to manually create and then delete a fake swap file named .rc.local.swp ? It turned out to be a disk quota issue. GOOD: the VE didn't chew up all the available disk space (as it would have in a couple of hours) BAD: the violation of the disk quota doesn't show up in user_beancounters It shows in df (or df -i) -- standard UNIX/Linux tool; it is all described in http://wiki.openvz.org/Resource_shortage (which I guess I should add to must read category. See, ff there is a standard way of seeing something, why invent something new and unique? For disk space there is such a tool, for beancounters there was no, since beancounters only appeared in OpenVZ. From the host system though there is a way to see all per-VE disk quotas and their usage -- cat /proc/vz/vzquota ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
Re: [Users] Routing problems using SMP kernel
Steve, Sure, SMP shouldn't affect your routing and it is very strange. I guess 90% of people are running SMP kernels. From your report it is totally unclear what OVZ kernel version is (e.g. something like 028stab039) and where this kernel was got from. Have you built it yourself? Can you please provide a bit more details on what is working and what not? Why have you decided that it is rounting to blame to? Thanks, Kirill Steve Hodges wrote: After getting most of my problems solved I decided to move my test environment onto the production server. The server is a dual xeon which, with hyperthreading, appears (to Linux) to have 4 processors. So, when I built this machine I decided to use the ovzkernel-2.6.18-smp The rebuild caused me all sorts of routing problems which I have managed to track down to being caused by the kernel. I just replaced the kernel with ovzkernel-2.6.18 aptitude install ovzkernel-2.6.18 aptitude remove ovzkernel-2.6.18-smp shutdown -r now problem solvered! It seems pretty odd that the smp kernel sould cause this, but I really don't know what is different about that kernel. The symptoms were similar to the ones I had before I set the netmask of the venets correctly, but more extreme. Whereas the netmask issue seemed to cause packets to go out of the wrong interface, this problem seemed to stop packets getting out of the server at all. If there are any questions about the symptoms, I will be able to swap back to that kernel for the next day or so to test things out. What will the impact be of running the non-smp kernel on a multi-processir machine? Will I only effectively use a single processor? Steve ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
Re: [Users] error using vi in VE but no beans?
Since we're on the topic, I thought I'd pipe up for Steve's benefit about a small matter which I found baffling for a few days... If you run df -k in a VE, you will often get a different answer than vzquota. This is because vzquota doesn't keep to-the-moment statistics in its cache file. You must run vzquota stat VEID in order to have the cache updated; then vzquota will report the correct usage. This is in the Wiki, but I thought to save you some time. :) -- Gregor Mosheh / Greg Allensworth System Administrator, HostGIS cartographic development hosting services http://www.HostGIS.com/ Remember that no one cares if you can back up, only if you can restore. - AMANDA ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
Re: [Users] error using vi in VE but no beans?
On 28/08/2007 12:14 AM, Gregor Mosheh wrote: Since we're on the topic, I thought I'd pipe up for Steve's benefit about a small matter which I found baffling for a few days... If you run df -k in a VE, you will often get a different answer than vzquota. This is because vzquota doesn't keep to-the-moment statistics in its cache file. You must run vzquota stat VEID in order to have the cache updated; then vzquota will report the correct usage. This is in the Wiki, but I thought to save you some time. :) Thanks :-) And for the benefit of Kir, I wasn't intending the GOOD/BAD thing wasn't intended as a criticism of openvz. It was really only bad because I had become fixated on the user_beancounters as a diagnostic and had forgotten about all the other good tools :-) The error from vi sort of pointed me at a memory issue which didn't help much either. However I was extremely grateful that my silly error in causing the VE to consume about 8 GB per hour had stopped at the quota limit of 40 GB rather than consuming all free space on that partition. Steve ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
