<div>However I am seeing an issue with the disk size inside the simfs-based CT. </div><div><br></div><div>In the vz conf files, all 3 CTs have the same diskspace setting:</div><div><br></div><div><font face="'courier new', monospace">[root@mrmber ~]# grep -i diskspace /etc/vz/conf/77*conf</font></div>
<div><font face="'courier new', monospace">/etc/vz/conf/771.conf:DISKSPACE="20000000:24000000"</font></div><div><font face="'courier new', monospace">/etc/vz/conf/773.conf:DISKSPACE="20000000:24000000"</font></div>
<div><font face="'courier new', monospace">/etc/vz/conf/775.conf:DISKSPACE="20000000:24000000"</font></div><div><br></div><div>But in the actual CTs the one on simfs reports a significantly smaller disk space than it did under previous kernels:</div>
<div><br></div><div><font face="'courier new', monospace">[root@mrmber ~]# for i in `vzlist -1`; do echo $i; vzctl exec $i df; done</font></div><div><font face="'courier new', monospace">771</font></div><div>
<font face="'courier new', monospace">Filesystem 1K-blocks Used Available Use% Mounted on</font></div><div><font face="'courier new', monospace">/dev/ploop0p1 23621500 939240 21482340 5% /</font></div>
<div><font face="'courier new', monospace">none 262144 4 262140 1% /dev</font></div><div><font face="'courier new', monospace">773</font></div><div><font face="'courier new', monospace">Filesystem 1K-blocks Used Available Use% Mounted on</font></div>
<div><font face="'courier new', monospace">/dev/simfs 6216340 739656 3918464 16% /</font></div><div><font face="'courier new', monospace">none 262144 4 262140 1% /dev</font></div>
<div><font face="'courier new', monospace">775</font></div><div><font face="'courier new', monospace">Filesystem 1K-blocks Used Available Use% Mounted on</font></div><div><font face="'courier new', monospace">/dev/ploop1p1 23628616 727664 21700952 4% /</font></div>
<div><font face="'courier new', monospace">none 262144 4 262140 1% /dev</font></div><div><font face="'courier new', monospace">[root@mrmber ~]# </font></div><div><br></div>
<div>Looking in dmesg shows this:</div><div><br></div><div><div><font face="'courier new', monospace">[ 2864.563423] CT: 773: started</font></div><div><font face="'courier new', monospace">[ 2866.203628] device veth773.0 entered promiscuous mode</font></div>
<div><font face="'courier new', monospace">[ 2866.203719] br0: port 3(veth773.0) entering learning state</font></div><div><font face="'courier new', monospace">[ 2868.302300] ploop1:</font></div><div><font face="'courier new', monospace">[ 2868.329086] GPT:Primary header thinks Alt. header is not at the end of the disk.</font></div>
<div><font face="'courier new', monospace">[ 2868.329099] GPT:47999999 != 48001023</font></div><div><font face="'courier new', monospace">[ 2868.329104] GPT:Alternate GPT header not at the end of the disk.</font></div>
<div><font face="'courier new', monospace">[ 2868.329111] GPT:47999999 != 48001023</font></div><div><font face="'courier new', monospace">[ 2868.329115] GPT: Use GNU Parted to correct GPT errors.</font></div>
<div><font face="'courier new', monospace">[ 2868.329128] p1</font></div><div><font face="'courier new', monospace">[ 2868.333608] ploop1:</font></div><div><font face="'courier new', monospace">[ 2868.337235] GPT:Primary header thinks Alt. header is not at the end of the disk.</font></div>
<div><font face="'courier new', monospace">[ 2868.337247] GPT:47999999 != 48001023</font></div><div><font face="'courier new', monospace">[ 2868.337252] GPT:Alternate GPT header not at the end of the disk.</font></div>
<div><font face="'courier new', monospace">[ 2868.337258] GPT:47999999 != 48001023</font></div><div><font face="'courier new', monospace">[ 2868.337262] GPT: Use GNU Parted to correct GPT errors.</font></div>
</div><div><br></div><div>I'm assuming that this disk damage occurred under the buggy stab54.1 kernel. I could destroy the container and create a replacement but I'd like to make believe, for the time being, that it's valuable. Just out of curiosity, what tools exist to fix this sort of thing? The log entries recommend gparted, but I suspect I may not have much luck from inside the CT with that. If this were PVC, there would obviously be more choices. You thoughts?</div>
<div><br></div><div>Joe</div><div><br></div><div>On Thu, Apr 5, 2012 at 3:17 PM, jjs - mainphrame <span dir="ltr"><<a href="mailto:jjs@mainphrame.com" target="_blank">jjs@mainphrame.com</a>></span> wrote:</div><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>I'm happy to report that stab54.2 fixes the kernel panics I was seeing in stab54.1 - </div><div><br></div><div>Thanks for the serial console reminder, I'll work on setting that up...</div><div><br></div><div>
Joe</div><div><div>
<div><br><div class="gmail_quote">On Thu, Apr 5, 2012 at 3:47 AM, Kir Kolyshkin <span dir="ltr"><<a href="mailto:kir@openvz.org" target="_blank">kir@openvz.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 04/05/2012 08:48 AM, jjs - mainphrame wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Kernel stab53.5 was very stable for me under heavy load but with stab54.1 I'm seeing hard lockups - the Alt-Sysrq keys don't work, only the power or reset button will do the trick.<br>
<br>
I don't have a serial console set up so I'm not able to capture the kernel panic message and backtrace. I think I'll need to get that set up in order to go any further with this.<br>
<br>
</blockquote></div>
054.2 might fix the issue you are having. It is being uploaded at the moment...<br>
<br>
Anyway, it's a good idea to have serial console set up. It greatly improves chances to resolve kernel bugs. <a href="http://wiki.openvz.org/Remote_console_setup" target="_blank">http://wiki.openvz.org/Remote_<u></u>console_setup</a> just in case.<br>
______________________________<u></u>_________________<br>
Users mailing list<br>
<a href="mailto:Users@openvz.org" target="_blank">Users@openvz.org</a><br>
<a href="https://openvz.org/mailman/listinfo/users" target="_blank">https://openvz.org/mailman/<u></u>listinfo/users</a><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br>