Re: [Users] distro virtuozzo vs proxmox

2019-04-28 Thread Website Solution - George 


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" 
À: "OpenVZ users" 
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 mailto:coolthec...@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 mailto:spame...@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
 mailto:informat...@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
 mailto:informat...@actiu.net>>:

 Does anybody know how can I solve this?

 $ lsb_release -d
 Description:    Devuan GNU/Linux 1.0 (jessie)

 $ uname -a

[Users] distro virtuozzo vs proxmox

2019-04-28 Thread Jehan PROCACCIA 
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" 
À: "OpenVZ users" 
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  > 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  > 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
> mailto:informat...@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
>> mailto:informat...@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
>>

Re: [Users] SSD trim support over a LUKS layer

2019-04-28 Thread spameden 
No. It's impossible to use OpenVZ 6 with kernel 4.x, unless you put lots of
effort to port their patches over the fresh kernel.

The latest OpenVZ 6 kernel is 2.6.32-openvz-042stab136.1-amd64 and there is
an issue with discard (it doesn't work).

The discard issue has been fixed in 3.1-mainline kernel I think, you can
look over newish RHEL kernel and try to port those changes to the old
legacy OpenVZ 6 kernel.

Regarding 4.x kernel:
I'm using Proxmox with 4.x kernel (there is no OpenVZ) - only LXC
containers and KVM - and there is no issue with discards at all.
and what I also meant is: that you can easily migrate your existing OpenVZ
containers to the Proxmox.

Proxmox is based on latest Debian Stretch and specifically designed as a
distro for contrainers.
It has GUI, networking support (including openvswitch and other), KVM/LXC
support and many other things (e.g. ceph/glusterfs support).

Though, reading you again you've mentioned that you need a specific simfs
quota in containers:
most likely that would be impossible for unprivileged containers with
directory storage (simfs analogue), althrough you could use qcow2 or
LVM-based storage for containers.


вс, 28 апр. 2019 г. в 09:47, Narcis Garcia :

> El 27/4/19 a les 22:15, spameden ha escrit:
> >
> > сб, 27 апр. 2019 г. в 20:16, Narcis Garcia  > >:
> >
> > I responded about OpenVZ/6 vs LXC, and Proxmox doesn't solve the
> Discard
> >
> >
> > What do you mean it doesn't solve the issue with discard? It does.
> >
> > Discard is perfectly working on Proxmox kernel 4.15.18-12-pve or even on
> > 4.13 kernel on DM-Crypt/LUKS setup.
> >
> > I'm using on all my servers DM-Crypt/LUKS + LVM so I know what I'm
> > talking about.
>
> Are you really using OpenVZ 6 with Linux kernel 4.x?
> Did you see any difficult with Discard when using other context with
> Linux 4.x ?
> ___
> Users mailing list
> Users@openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] SSD trim support over a LUKS layer

2019-04-28 Thread Narcis Garcia 
El 27/4/19 a les 22:15, spameden ha escrit:
> 
> сб, 27 апр. 2019 г. в 20:16, Narcis Garcia  >:
> 
> I responded about OpenVZ/6 vs LXC, and Proxmox doesn't solve the Discard
> 
> 
> What do you mean it doesn't solve the issue with discard? It does.
> 
> Discard is perfectly working on Proxmox kernel 4.15.18-12-pve or even on
> 4.13 kernel on DM-Crypt/LUKS setup.
> 
> I'm using on all my servers DM-Crypt/LUKS + LVM so I know what I'm
> talking about.

Are you really using OpenVZ 6 with Linux kernel 4.x?
Did you see any difficult with Discard when using other context with
Linux 4.x ?
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users