OpenVZ Forum


Home » Mailing lists » Users » Problems encountered increasing CT diskspace with layout=ploop
Problems encountered increasing CT diskspace with layout=ploop [message #45626] Fri, 23 March 2012 18:27 Go to next message
jjs - mainphrame is currently offline  jjs - mainphrame
Messages: 44
Registered: January 2012
Member
Running kernel 2.6.32-042stab053.3, vzctl-3.1 and ploop-1.1 on centos-6.2
32 bit, I created 2 similar vswap-256 CTs running debian-5.0-x86.

The only appreciable difference between the CTs is the layout: CT 777 is
simfs, CT 779 is ploop

[root@mrmber conf]# for i in `vzlist -1`; do ech0 $i; vzctl exec $i df -T;
done
777
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/simfs simfs 2097152 376820 1720332 18% /
tmpfs tmpfs 131072 0 131072 0% /lib/init/rw
tmpfs tmpfs 131072 0 131072 0% /dev/shm
779
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/ploop0p1 ext4 2268760 445756 1707756 21% /
tmpfs tmpfs 131072 0 131072 0% /lib/init/rw
tmpfs tmpfs 131072 0 131072 0% /dev/shm

We can successfully resize the simfs-based CT 777:

[root@mrmber conf]# vzctl set 777 --diskspace=20000000:24000000 --save
CT configuration saved to /etc/vz/conf/777.conf

But attempting to resize ploop-based CT 779 results in an error:

[root@mrmber conf]# vzctl set 779 --diskspace=20000000:24000000 --save
Can't ioctl mount_point: No such file or directory
Failed to resize image: Can't ioctl mount_point: No such file or directory
[3]
CT configuration saved to /etc/vz/conf/779.conf

[root@mrmber conf]# for i in `vzlist -1`; do echo $i; vzctl exec $i df -T ;
done
777
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/simfs simfs 20000000 376820 18532204 2% /
tmpfs tmpfs 131072 0 131072 0% /lib/init/rw
tmpfs tmpfs 131072 0 131072 0% /dev/shm
779
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/ploop0p1 ext4 2268760 445756 1707756 21% /
tmpfs tmpfs 131072 0 131072 0% /lib/init/rw
tmpfs tmpfs 131072 0 131072 0% /dev/shm
[root@mrmber conf]#

Any advice on where to look for more info? dmesg had nothing to say about
it, and vzctl.log says only what the command reported above.

Regards,

Joe


http://static.openvz.org/userbars/openvz-user.png
Re: Problems encountered increasing CT diskspace with layout=ploop [message #45627 is a reply to message #45626] Fri, 23 March 2012 18:46 Go to previous messageGo to next message
jjs - mainphrame is currently offline  jjs - mainphrame
Messages: 44
Registered: January 2012
Member
Just an added data point to follow up my earlier post -

Although the online re-size of the ploop-based disk CT fails, creating a CT
with the desired disk size using "layout=ploop
--diskspace=20000000:24000000" works.

Thanks for your work on this, hope to see it in PVC one day.

Joe

On Fri, Mar 23, 2012 at 11:27 AM, jjs - mainphrame <jjs@mainphrame.com>wrote:

> Running kernel 2.6.32-042stab053.3, vzctl-3.1 and ploop-1.1 on centos-6.2
> 32 bit, I created 2 similar vswap-256 CTs running debian-5.0-x86.
>
> The only appreciable difference between the CTs is the layout: CT 777 is
> simfs, CT 779 is ploop
>
> [root@mrmber conf]# for i in `vzlist -1`; do ech0 $i; vzctl exec $i df
> -T; done
> 777
> Filesystem Type 1K-blocks Used Available Use% Mounted on
> /dev/simfs simfs 2097152 376820 1720332 18% /
> tmpfs tmpfs 131072 0 131072 0% /lib/init/rw
> tmpfs tmpfs 131072 0 131072 0% /dev/shm
> 779
> Filesystem Type 1K-blocks Used Available Use% Mounted on
> /dev/ploop0p1 ext4 2268760 445756 1707756 21% /
> tmpfs tmpfs 131072 0 131072 0% /lib/init/rw
> tmpfs tmpfs 131072 0 131072 0% /dev/shm
>
> We can successfully resize the simfs-based CT 777:
>
> [root@mrmber conf]# vzctl set 777 --diskspace=20000000:24000000 --save
> CT configuration saved to /etc/vz/conf/777.conf
>
> But attempting to resize ploop-based CT 779 results in an error:
>
> [root@mrmber conf]# vzctl set 779 --diskspace=20000000:24000000 --save
> Can't ioctl mount_point: No such file or directory
> Failed to resize image: Can't ioctl mount_point: No such file or directory
> [3]
> CT configuration saved to /etc/vz/conf/779.conf
>
> [root@mrmber conf]# for i in `vzlist -1`; do echo $i; vzctl exec $i df -T
> ; done
> 777
> Filesystem Type 1K-blocks Used Available Use% Mounted on
> /dev/simfs simfs 20000000 376820 18532204 2% /
> tmpfs tmpfs 131072 0 131072 0% /lib/init/rw
> tmpfs tmpfs 131072 0 131072 0% /dev/shm
> 779
> Filesystem Type 1K-blocks Used Available Use% Mounted on
> /dev/ploop0p1 ext4 2268760 445756 1707756 21% /
> tmpfs tmpfs 131072 0 131072 0% /lib/init/rw
> tmpfs tmpfs 131072 0 131072 0% /dev/shm
> [root@mrmber conf]#
>
> Any advice on where to look for more info? dmesg had nothing to say about
> it, and vzctl.log says only what the command reported above.
>
> Regards,
>
> Joe
>
>


http://static.openvz.org/userbars/openvz-user.png
Re: Problems encountered increasing CT diskspace with layout=ploop [message #45629 is a reply to message #45626] Fri, 23 March 2012 20:47 Go to previous messageGo to next message
kir is currently offline  kir
Messages: 1645
Registered: August 2005
Location: Moscow, Russia
Senior Member

On 03/23/2012 10:27 PM, jjs - mainphrame wrote:
> We can successfully resize the simfs-based CT 777:
>
> [root@mrmber conf]# vzctl set 777 --diskspace=20000000:24000000 --save
> CT configuration saved to /etc/vz/conf/777.conf

For simfs case, this is not a real resize, but change of vzquota values.
That is why you have two values for quota -- soft and hard (and
--quotatime to set a grace period).
>
> But attempting to resize ploop-based CT 779 results in an error:
>
> [root@mrmber conf]# vzctl set 779 --diskspace=20000000:24000000 --save

This is irrelevant to the bug report, but just in case:
1 there's no need to specify two values for ploop disk size
2 you can use suffixes (like --diskspace 24G).

> Can't ioctl mount_point: No such file or directory
> Failed to resize image: Can't ioctl mount_point: No such file or
> directory [3]

This means ploop can't find the balloon file. That's pretty strange.

1 Have you created this CT using the same version of vzctl and ploop?
2 Do you have anything strange in dmesg?
3 Are you able to stop/start/mount/umount this CT?

In the meantime, I have tried to do the same as you did on my box
(running the same version of kernel, vzctl, and ploop):

[root@dhcp-10-30-21-127 ~]# vzctl set 200 --diskspace=20000000:24000000
--save
Growing dev=/dev/ploop0 size=4613734 sectors (new size=48000000)
Storing GPT
Executing: /sbin/resize2fs -p /dev/ploop0p1
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/ploop0p1 is mounted on /vz/root/200; on-line resizing
required
old desc_blocks = 1, new_desc_blocks = 2
Performing an on-line resize of /dev/ploop0p1 to 5999739 (4k) blocks.
The filesystem on /dev/ploop0p1 is now 5999739 blocks long.

Executing: /sbin/tune2fs -r 300000 /dev/ploop0p1
tune2fs 1.41.12 (17-May-2010)
Setting reserved blocks count to 300000
CT configuration saved to /etc/vz/conf/200.conf
[root@dhcp-10-30-21-127 ~]# vzctl exec 200 df -h
Filesystem Size Used Avail Use% Mounted on
/dev/ploop0p1 23G 674M 21G 4% /


> CT configuration saved to /etc/vz/conf/779.conf
>
> [root@mrmber conf]# for i in `vzlist -1`; do echo $i; vzctl exec $i df
> -T ; done
> 777
> Filesystem Type 1K-blocks Used Available Use% Mounted on
> /dev/simfs simfs 20000000 376820 18532204 2% /
> tmpfs tmpfs 131072 0 131072 0% /lib/init/rw
> tmpfs tmpfs 131072 0 131072 0% /dev/shm
> 779
> Filesystem Type 1K-blocks Used Available Use% Mounted on
> /dev/ploop0p1 ext4 2268760 445756 1707756 21% /
> tmpfs tmpfs 131072 0 131072 0% /lib/init/rw
> tmpfs tmpfs 131072 0 131072 0% /dev/shm
> [root@mrmber conf]#
>
> Any advice on where to look for more info? dmesg had nothing to say
> about it, and vzctl.log says only what the command reported above.
>
> Regards,
>
> Joe
>


Kir Kolyshkin
http://static.openvz.org/userbars/openvz-developer.png
Re: Problems encountered increasing CT diskspace with layout=ploop [message #45630 is a reply to message #45629] Fri, 23 March 2012 21:37 Go to previous message
jjs - mainphrame is currently offline  jjs - mainphrame
Messages: 44
Registered: January 2012
Member
Hi Kir,

In trying to duplicate the problem with a newly created CT, I found that
resize is working as expected. It may be that I was using a CT created with
the earlier version of vzctl and ploop installed. I'll chalk it up
to senile dementia and keep testing, thanks for the sanity check.

Joe

On Fri, Mar 23, 2012 at 1:47 PM, Kir Kolyshkin <kir@openvz.org> wrote:

> On 03/23/2012 10:27 PM, jjs - mainphrame wrote:
>
>> We can successfully resize the simfs-based CT 777:
>>
>> [root@mrmber conf]# vzctl set 777 --diskspace=20000000:24000000 --save
>> CT configuration saved to /etc/vz/conf/777.conf
>>
>
> For simfs case, this is not a real resize, but change of vzquota values.
> That is why you have two values for quota -- soft and hard (and --quotatime
> to set a grace period).
>
>
>> But attempting to resize ploop-based CT 779 results in an error:
>>
>> [root@mrmber conf]# vzctl set 779 --diskspace=20000000:24000000 --save
>>
>
> This is irrelevant to the bug report, but just in case:
> 1 there's no need to specify two values for ploop disk size
> 2 you can use suffixes (like --diskspace 24G).
>
>
> Can't ioctl mount_point: No such file or directory
>> Failed to resize image: Can't ioctl mount_point: No such file or
>> directory [3]
>>
>
> This means ploop can't find the balloon file. That's pretty strange.
>
> 1 Have you created this CT using the same version of vzctl and ploop?
> 2 Do you have anything strange in dmesg?
> 3 Are you able to stop/start/mount/umount this CT?
>
> In the meantime, I have tried to do the same as you did on my box (running
> the same version of kernel, vzctl, and ploop):
>
> [root@dhcp-10-30-21-127 ~]# vzctl set 200 --diskspace=20000000:24000000
> --save
> Growing dev=/dev/ploop0 size=4613734 sectors (new size=48000000)
> Storing GPT
> Executing: /sbin/resize2fs -p /dev/ploop0p1
> resize2fs 1.41.12 (17-May-2010)
> Filesystem at /dev/ploop0p1 is mounted on /vz/root/200; on-line resizing
> required
> old desc_blocks = 1, new_desc_blocks = 2
> Performing an on-line resize of /dev/ploop0p1 to 5999739 (4k) blocks.
> The filesystem on /dev/ploop0p1 is now 5999739 blocks long.
>
> Executing: /sbin/tune2fs -r 300000 /dev/ploop0p1
> tune2fs 1.41.12 (17-May-2010)
> Setting reserved blocks count to 300000
> CT configuration saved to /etc/vz/conf/200.conf
> [root@dhcp-10-30-21-127 ~]# vzctl exec 200 df -h
> Filesystem Size Used Avail Use% Mounted on
> /dev/ploop0p1 23G 674M 21G 4% /
>
>
>
> CT configuration saved to /etc/vz/conf/779.conf
>>
>> [root@mrmber conf]# for i in `vzlist -1`; do echo $i; vzctl exec $i df
>> -T ; done
>> 777
>> Filesystem Type 1K-blocks Used Available Use% Mounted on
>> /dev/simfs simfs 20000000 376820 18532204 2% /
>> tmpfs tmpfs 131072 0 131072 0% /lib/init/rw
>> tmpfs tmpfs 131072 0 131072 0% /dev/shm
>> 779
>> Filesystem Type 1K-blocks Used Available Use% Mounted on
>> /dev/ploop0p1 ext4 2268760 445756 1707756 21% /
>> tmpfs tmpfs 131072 0 131072 0% /lib/init/rw
>> tmpfs tmpfs 131072 0 131072 0% /dev/shm
>> [root@mrmber conf]#
>>
>> Any advice on where to look for more info? dmesg had nothing to say about
>> it, and vzctl.log says only what the command reported above.
>>
>> Regards,
>>
>> Joe
>>
>>
> ______________________________**_________________
> Users mailing list
> Users@openvz.org
> https://openvz.org/mailman/**listinfo/users<https://openvz.org/mailman/listinfo/users>
>


http://static.openvz.org/userbars/openvz-user.png
Previous Topic: adventures with layout=ploop
Next Topic: Some observations from ploop testing
Goto Forum:
  


Current Time: Sun Nov 10 22:03:08 GMT 2024

Total time taken to generate the page: 0.04760 seconds