<div dir="ltr"><div>> Yes, i know it's still possible to create an image which will be compacted not that efficiently, but this becomes quite a rare case.</div><div><br></div>But in irl - get random prodaction node and first container with max delta (data vs image size) - <div>ploop-balloon discard /vz/private/93713/root.hdd/DiskDescriptor.xml --stat<br>Balloon size: 0MB<br>Data size: 30845MB<br>Ploop size: 51200MB<br>Image size: 47546MB<br></div><div><br></div><div>ploop-balloon discard /vz/private/93713/root.hdd/DiskDescriptor.xml --defrag<br></div><div>...</div><div><br></div><div><div>ploop-balloon discard /vz/private/93713/root.hdd/DiskDescriptor.xml --stat</div><div>Balloon size: 0MB</div><div>Data size: 30845MB</div><div>Ploop size: 51200MB</div><div>Image size: 47433MB</div></div><div><br></div><div>And already have 17Gb wasted space for 30Gb data after compact with defrag.</div><div>( on node openvz 6 - 2.6.32-042stab114.5 kernel, ploop-1.15-1.x86_64 and e4defrag2 builded from <a href="https://github.com/dmonakhov/e2fsprogs/tree/e4defrag2">https://github.com/dmonakhov/e2fsprogs/tree/e4defrag2</a> with commits from 16 May).</div><div><br></div><div>In irl we have significan overhead on disk operations on compact ploop images.</div><div><br></div><div>In irl we regular have ploop images which we cannot umount - <a href="https://bugs.openvz.org/browse/OVZ-6689">https://bugs.openvz.org/browse/OVZ-6689</a> !!!</div><div><br></div><div>And from time to time backup and compact failed with strange situations like - <a href="https://bugs.openvz.org/browse/OVZ-6547">https://bugs.openvz.org/browse/OVZ-6547</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-06-06 18:13 GMT+03:00 Konstantin Khorenko <span dir="ltr"><<a href="mailto:khorenko@virtuozzo.com" target="_blank">khorenko@virtuozzo.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 06/06/2016 02:23 PM, Volker Janzen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Sergey,<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 14:39 Sun 05 Jun , Volker Janzen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Unfortunately no. We don't support upgrade from pre-release version to the final one.<br>
</blockquote>
<br>
When I use a CentOS 7 as base system and install VZ7 afterward it's not possible to upgrade, too?<br>
</blockquote>
<br>
There is only one supported configuration for new installations -<br>
clean Virtuozzo 7 installation.<br>
</blockquote>
<br>
okay I see. My setup will be unsupported if installed on plain CentOS 7 either way.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It also seems to lack some documentation for my use cases, but I need to start<br>
with VZ7 sooner or later.<br>
</blockquote>
<br>
What usecases are you talking about?<br>
</blockquote>
<br>
My current OpenVZ setup has LVM involved.<br>
I want to be able to use simfs based storage on an underlaying LVM volume.<br>
</blockquote>
<br>
Why do you prefer simfs instead of ploop? Did you see comparison simfs vs ploop?<br>
<a href="https://openvz.org/CT_storage_backends" rel="noreferrer" target="_blank">https://openvz.org/CT_storage_backends</a><br>
</blockquote>
<br>
I think you asked me about this some time ago. The matrix states: Reliability<br>
Low: big amount of files produce ext4 corruption so often<br>
<br>
Why should I use something that tells me it's not reliable?<br>
</blockquote>
<br></span>
Even according to<br>
<a href="https://github.com/pavel-odintsov/OpenVZ_ZFS/blob/master/openvz_storage_backends.md" rel="noreferrer" target="_blank">https://github.com/pavel-odintsov/OpenVZ_ZFS/blob/master/openvz_storage_backends.md</a><br>
(which seems to be used as a source of recent page update) this row is incorrect, this info has just been added by Narcis Garcia and is to be corrected.<br>
<br>
i don't want to start a holly war here, i won't tell that ZFS is worse or whatever,<br>
i just know that we really do power crash testing and know the results.<br>
And i'm certain that our default suggested solution is good and stable.<br>
<br>
Yes, there are drawbacks - the most important one now is usage overhead (sic!, not stability for a long time already), and we improve it.<br>
And gained quite a good progress. Just did a ploop compaction of my personal work Container, created 03.07.2014 (lot of gits, makes, etc.):<br>
<br>
# ploop-balloon discard /vz/private/105/root.hdd/DiskDescriptor.xml --defrag<br>
...<br>
# ploop-balloon discard /vz/private/105/root.hdd/DiskDescriptor.xml --stat<br>
Balloon size: 0MB<br>
Data size: 29189MB<br>
Ploop size: 102400MB<br>
Image size: 29057MB<br>
<br>
Yes, i know it's still possible to create an image which will be compacted not that efficiently, but this becomes quite a rare case.<br>
Do you have such an image? Send it to us.<br>
<br>
Thank you.<br>
<br>
P.S. in fact we don't need full image in most cases, only metadata is essential, so if you worry about data and confidentiality, no problem here:<br>
# e2image -r /dev/ploopXXp1 - | bzip2 > image.e2i.bz2<br>
<br>
--<br>
Best regards,<br>
<br>
Konstantin Khorenko,<br>
Virtuozzo Linux Kernel Team<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The /vz partition has also the big advantage of using LVM snapshots and it allows rsync of the container data to another host with less overhead.<br>
<br>
Also the need to compress the ploop files does not seem to be something I'm willing to do.<br>
<br>
<br>
Regards<br>
Volker<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And I want to be able to setup KVM based VMs that have a LVM based disk, too.<br>
In best case KVM VMs can be created from a template, as with the container VMs.<br>
</blockquote>
<br>
Den, is it possible in Vz7?<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Regards<br>
Volker<br>
</blockquote></blockquote></blockquote>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@openvz.org" target="_blank">Users@openvz.org</a><br>
<a href="https://lists.openvz.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.openvz.org/mailman/listinfo/users</a><br>
</div></div></blockquote></div><br></div>