[Users] distro virtuozzo vs proxmox
Website Solution - George
ccto at website-solution.net
Mon Apr 29 05:16:51 MSK 2019
From my understanding, Virtuozzo 7 (or OpenVZ 7) supports user quota
inside guest container.
However, for unprivileged LXC guest, it does not support quota inside
container natively.
It is important if we run the guest container for multiple end-users.
(Privileged LXC guests support user quota inside container, but they
share the same root UID between guest and host, which implies some kind
of potential security)
On 29-Apr-19 3:55 AM, Jehan PROCACCIA wrote:
> regarding distros and virtuozzo vs proxmox (reason I modified the subject, orig: SSD trim support over a LUKS layer)
> I understand that it could be frustrating to rely on a dedidcated distro (virtuozzo 7), but I guess it comes with simplicity and consistency regarding set of packages and updates
> after all it's very similar to centos/rhel 7 as it is based on it, and if you wish , you could add openvz7 feature to native centos7 : https://enjoyko.blogspot.com/2018/05/how-to-install-openvz-7-to-centos-7.html
>
> I guess that https://wiki.openvz.org/Comparison is quite up to date as it dates from jan/2019
> but i am still wondering what technology virtuozzo 7 uses for containers if not LXC ?
>
> I'll be glad to know as I have regularly discussions between sysadmins around proxmox and virtuozzo , and finally it ends on debian vs centos/rhel !
>
> ----- Mail original -----
> De: "Narcis Garcia" <informatica at actiu.net>
> À: "OpenVZ users" <users at openvz.org>
> Envoyé: Samedi 27 Avril 2019 19:19:43
> Objet: Re: [Users] SSD trim support over a LUKS layer
>
> The problem of Virtuozzo 7 for me is that this is a distro.
> I prefer to use general purpose distros, for many reasons around
> packaged software, community support, future plans and others.
>
>
> El 27/4/19 a les 19:09, Paulo Coghi - Coghi IT ha escrit:
>> LXC is far to be an option, IMHO.
>>
>> I'm happily using Virtuozzo 7 with multiple NVMe storages with zero
>> issues for more than a year.
>>
>> On Sat, Apr 27, 2019 at 4:28 PM CoolCold <coolthecold at gmail.com
>> <mailto:coolthecold at gmail.com>> wrote:
>>
>> I believe to have fixes and backports like this in to legacy version
>> of product will not happen, and you should consider upgrading.
>> Personally, I've upgraded to lxc.. it's quite primitive comparing to
>> ovz 6, but it's enough for my needs.
>>
>> On Sat, Apr 27, 2019, 17:49 spameden <spameden at gmail.com
>> <mailto:spameden at gmail.com>> wrote:
>>
>> Yes, it's an issue in kernel.
>>
>> As dm-crypt/luks layer isn't passing TRIM to the underlying device.
>>
>> /boot is not encrypted that's why it works for you.
>>
>> сб, 27 апр. 2019 г. в 11:11, Narcis Garcia
>> <informatica at actiu.net <mailto:informatica at actiu.net>>:
>>
>> See in the case that /dev/sda1 (Directly mounted as Ext4 on
>> /boot) works with Trim/Discard.
>> It's the sda2_crypt (layer over sda2) that is not detected
>> to be trimmable. Devuan's stock kernel does.
>>
>> CentOS issue #6548 may not be this same bug; I've tested now
>> with CentOS 6.8 with a similar (but not same) result*:*
>>
>> $ lsb_release -d
>> Description: CentOS release 6.8 (Final)
>>
>> $ uname -a
>> Linux localhost.localdomain 2.6.32-642.el6.x86_64 #1 SMP Tue
>> May 10 17:27:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>>
>> $ lsblk --discard /dev/sda
>> NAME
>> DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
>> sda
>> 0 512B 2G 0
>> ├─sda1
>> 0 512B 2G 0
>> └─sda2
>> 0 512B 2G 0
>> └─luks-f691f48b-8556-487d-ac64-50daa99ed4c9 (dm-0)
>> 0 512B 2G 0
>>
>> $ cat /etc/crypttab
>> luks-f691f48b-8556-487d-ac64-50daa99ed4c9
>> UUID=f691f48b-8556-487d-ac64-50daa99ed4c9 none luks,discard
>>
>> $ mount | grep -e discard
>> /dev/mapper/luks-f691f48b-8556-487d-ac64-50daa99ed4c9 on /
>> type ext4 (rw,discard)
>> /dev/sda1 on /boot type ext4 (rw,discard)
>>
>> $ sudo fstrim /boot
>> # (same result as Devuan/1 and OpenVZ/6 kernel: success)
>>
>> $ sudo fstrim /
>> fstrim: /: FITRIM ioctl failed: Operation not supported
>>
>>
>> El 26/4/19 a les 21:36, spameden ha escrit:
>>> Hi.
>>>
>>> I've asked this question years ago (in
>>> 2013): https://lists.openvz.org/pipermail/users/2013-August/005250.html
>>>
>>> Let me know if it helps, but this bug should have been
>>> fixed in CentOS and RHEL at
>>> least: https://bugs.centos.org/view.php?id=6548
>>>
>>> Maybe OpenVZ maintainers didn't pick up this fix in the
>>> openvz6 legacy kernel?
>>>
>>> Thanks.
>>>
>>> ср, 10 апр. 2019 г. в 10:45, Narcis Garcia
>>> <informatica at actiu.net <mailto:informatica at actiu.net>>:
>>>
>>> Does anybody know how can I solve this?
>>>
>>> $ lsb_release -d
>>> Description: Devuan GNU/Linux 1.0 (jessie)
>>>
>>> $ uname -a
>>> Linux bell1 2.6.32-openvz-042stab134.8-amd64 #1 SMP
>>> Fri Dec 7 17:18:40
>>> MSK 2018 x86_64 GNU/Linux
>>>
>>> $ lsblk --discard /dev/sda
>>> NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
>>> sda 0 512B 2G 0
>>> ├─sda1 0 512B 2G 0
>>> └─sda2 0 512B 2G 0
>>> └─sda2_crypt 0 0B 0B 0
>>>
>>> $ cat /etc/crypttab
>>> sda2_crypt UUID=***** none luks,discard
>>>
>>> $ mount | grep -e discard
>>> /dev/mapper/sda2_crypt on / type ext4
>>> (rw,noatime,errors=remount-ro,barrier=1,data=ordered,discard)
>>> /dev/sda1 on /boot type ext4
>>> (rw,relatime,barrier=1,data=ordered,discard)
>>>
>>> $ sudo fstrim /
>>> fstrim: /: the discard operation is not supported
>>>
>>> Thank you.
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at openvz.org <mailto:Users at openvz.org>
>>> https://lists.openvz.org/mailman/listinfo/users
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at openvz.org <mailto:Users at openvz.org>
>>> https://lists.openvz.org/mailman/listinfo/users
>> _______________________________________________
>> Users mailing list
>> Users at openvz.org <mailto:Users at openvz.org>
>> https://lists.openvz.org/mailman/listinfo/users
>>
>> _______________________________________________
>> Users mailing list
>> Users at openvz.org <mailto:Users at openvz.org>
>> https://lists.openvz.org/mailman/listinfo/users
>>
>> _______________________________________________
>> Users mailing list
>> Users at openvz.org <mailto:Users at openvz.org>
>> https://lists.openvz.org/mailman/listinfo/users
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://lists.openvz.org/mailman/listinfo/users
More information about the Users
mailing list