On 06/06/2016 07:13 PM, Сергей Мамонов wrote:
> 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.
But in irl - get random prodaction node and first container with max delta
(data vs image size) -
ploop-balloon discard /vz/private/93713/root.hdd/DiskDescriptor.xml --stat
Balloon size: 0MB
Data size: 30845MB
Ploop size: 51200MB
Image size: 47546MB
ploop-balloon discard /vz/private/93713/root.hdd/DiskDescriptor.xml --defrag
...
ploop-balloon discard /vz/private/93713/root.hdd/DiskDescriptor.xml --stat
Balloon size: 0MB
Data size: 30845MB
Ploop size: 51200MB
Image size: 47433MB
Sergey, good! You are welcome to upload the image data:
<link sent privately>
We've already done one more step further, interesting to know if it will be big
or small one in your case.
Anyone else?
And already have 17Gb wasted space for 30Gb data after compact with defrag.
( on node openvz 6 - 2.6.32-042stab114.5 kernel, ploop-1.15-1.x86_64 and
e4defrag2 builded from https://github.com/dmonakhov/e2fsprogs/tree/e4defrag2
with commits from 16 May).
In irl we have significan overhead on disk operations on compact ploop images.
In irl we regular have ploop images which we cannot umount -
https://bugs.openvz.org/browse/OVZ-6689 !!!
And from time to time backup and compact failed with strange situations like -
https://bugs.openvz.org/browse/OVZ-6547
And this is a good illustration why Virtuozzo 7 is so different from OpenVZ 6.
Getting free and commercial tools code more and more different lead to issues
we don't face in commercial product.
i believe OpenVZ users will really benefit in stability from Virtuozzo 7, where
the code is exactly same both in commercial and free versions.
--
Konstantin
2016-06-06 18:13 GMT+03:00 Konstantin Khorenko <khore...@virtuozzo.com
<mailto:khore...@virtuozzo.com>>:
On 06/06/2016 02:23 PM, Volker Janzen wrote:
Hi Sergey,
On 14:39 Sun 05 Jun , Volker Janzen wrote:
Unfortunately no. We don't support upgrade from pre-release
version to the final one.
When I use a CentOS 7 as base system and install VZ7 afterward
it's not possible to upgrade, too?
There is only one supported configuration for new installations -
clean Virtuozzo 7 installation.
okay I see. My setup will be unsupported if installed on plain CentOS 7
either way.
It also seems to lack some documentation for my use
cases, but I need to start
with VZ7 sooner or later.
What usecases are you talking about?
My current OpenVZ setup has LVM involved.
I want to be able to use simfs based storage on an underlaying
LVM volume.
Why do you prefer simfs instead of ploop? Did you see comparison
simfs vs ploop?
https://openvz.org/CT_storage_backends
I think you asked me about this some time ago. The matrix states:
Reliability
Low: big amount of files produce ext4 corruption so often
Why should I use something that tells me it's not reliable?
Even according to
https://github.com/pavel-odintsov/OpenVZ_ZFS/blob/master/openvz_storage_backends.md
(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.
i don't want to start a holly war here, i won't tell that ZFS is worse or
whatever,
i just know that we really do power crash testing and know the results.
And i'm certain that our default suggested solution is good and stable.
Yes, there are drawbacks - the most important one now is usage overhead
(sic!, not stability for a long time already), and we improve it.
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.):
# ploop-balloon discard /vz/private/105/root.hdd/DiskDescriptor.xml --defrag
...
# ploop-balloon discard /vz/private/105/root.hdd/DiskDescriptor.xml --stat
Balloon size: 0MB
Data size: 29189MB
Ploop size: 102400MB
Image size: 29057MB
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.
Do you have such an image? Send it to us.
Thank you.
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:
# e2image -r /dev/ploopXXp1 - | bzip2 > image.e2i.bz2
--
Best regards,
Konstantin Khorenko,
Virtuozzo Linux Kernel Team
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.
Also the need to compress the ploop files does not seem to be something
I'm willing to do.
Regards
Volker
And I want to be able to setup KVM based VMs that have a LVM
based disk, too.
In best case KVM VMs can be created from a template, as with
the container VMs.
Den, is it possible in Vz7?
Regards
Volker
_______________________________________________
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users
