[Users] New setup - deploy OpenVZ or wait for VZ7?

[Konstantin Khorenko]

On 06/06/2016 06:13 PM, Konstantin Khorenko wrote:
> 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

Sorry, better in qcow2 format, much less in size:
# e2image -Q /dev/ploopXXp1 - | bzip2 > image.qcow2.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 at openvz.org
> https://lists.openvz.org/mailman/listinfo/users
> .
>