From informatica at actiu.net  Wed Apr 10 10:42:46 2019
From: informatica at actiu.net (Narcis Garcia)
Date: Wed, 10 Apr 2019 09:42:46 +0200
Subject: [Users] SSD trim support over a LUKS layer
Message-ID: <bbc70961-38c4-26e4-ba06-760d4acfcd3f@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.



From khorenko at virtuozzo.com  Thu Apr 25 19:22:54 2019
From: khorenko at virtuozzo.com (Konstantin Khorenko)
Date: Thu, 25 Apr 2019 16:22:54 +0000
Subject: [Users] [Update] Virtuozzo/OpenVZ 7.0 Update 10 (7.0.10-252)
Message-ID: <02281fbc-65b6-fb72-32c1-d02b0618c291@virtuozzo.com>

Hi All,

Virtuozzo 7 has got an Update 10 published:
https://virtuozzosupport.force.com/s/article/VZA-2019-028

And corresponding update has been published to OpenVZ 7 as well:
https://download.openvz.org/virtuozzo/releases/openvz-7.0.10-252/

The update contains new kernel: 3.10.0-957.10.1.vz7.85.17,
the list of bugs fixed in the update is in the link for Virtuozzo update above.

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team


From jehan.procaccia at tem-tsp.eu  Thu Apr 25 20:12:20 2019
From: jehan.procaccia at tem-tsp.eu (Jehan PROCACCIA)
Date: Thu, 25 Apr 2019 19:12:20 +0200
Subject: [Users] [Update] Virtuozzo/OpenVZ 7.0 Update 10 (7.0.10-252)
In-Reply-To: <02281fbc-65b6-fb72-32c1-d02b0618c291@virtuozzo.com>
References: <02281fbc-65b6-fb72-32c1-d02b0618c291@virtuozzo.com>
Message-ID: <473451218.11559364.1556212340844.JavaMail.zimbra@imtbs-tsp.eu>

Hello,

this quite a big update, + 200 packages on my servers , i'll give it a try .

thanks .

----- Mail original -----
De: "Konstantin Khorenko" <khorenko at virtuozzo.com>
?: "OpenVZ users" <users at openvz.org>
Envoy?: Jeudi 25 Avril 2019 18:22:54
Objet: [Users] [Update] Virtuozzo/OpenVZ 7.0 Update 10 (7.0.10-252)

Hi All,

Virtuozzo 7 has got an Update 10 published:
https://virtuozzosupport.force.com/s/article/VZA-2019-028

And corresponding update has been published to OpenVZ 7 as well:
https://download.openvz.org/virtuozzo/releases/openvz-7.0.10-252/

The update contains new kernel: 3.10.0-957.10.1.vz7.85.17,
the list of bugs fixed in the update is in the link for Virtuozzo update above.

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team

_______________________________________________
Users mailing list
Users at openvz.org
https://lists.openvz.org/mailman/listinfo/users


From bkb at virtuozzo.com  Thu Apr 25 22:38:02 2019
From: bkb at virtuozzo.com (Konstantin Bukharov)
Date: Thu, 25 Apr 2019 19:38:02 +0000
Subject: [Users] Virtuozzo/OpenVZ 7.0 Update 10 (7.0.10-252)
In-Reply-To: <473451218.11559364.1556212340844.JavaMail.zimbra@imtbs-tsp.eu>
References: <02281fbc-65b6-fb72-32c1-d02b0618c291@virtuozzo.com>
	<473451218.11559364.1556212340844.JavaMail.zimbra@imtbs-tsp.eu>
Message-ID: <HE1PR0802MB2395AE95EEC74DD99A8B9FFEB23D0@HE1PR0802MB2395.eurprd08.prod.outlook.com>

Hello,

It's a rebase update.

What were updated:
Linux kernel ? now based on RHEL 7.6 kernel 3.10.0-957.10.1.el7
QEMU ? - 2.12 (was 2.10 in Update 9)
Libvirt ? 4.5.0 (was 3.9.0)
CRIU ? 3.11 (was 3.10)
QEMU-GA ? 3.0.91 (was 2.90)

All linux user space packages correspond now to RHEL 7.6

Best regards,

-----Original Message-----
From: users-bounces at openvz.org <users-bounces at openvz.org> On Behalf Of Jehan PROCACCIA
Sent: Thursday, April 25, 2019 20:12
To: OpenVZ users <users at openvz.org>
Subject: Re: [Users] [Update] Virtuozzo/OpenVZ 7.0 Update 10 (7.0.10-252)

Hello,

this quite a big update, + 200 packages on my servers , i'll give it a try .

thanks .

----- Mail original -----
De: "Konstantin Khorenko" <khorenko at virtuozzo.com>
?: "OpenVZ users" <users at openvz.org>
Envoy?: Jeudi 25 Avril 2019 18:22:54
Objet: [Users] [Update] Virtuozzo/OpenVZ 7.0 Update 10 (7.0.10-252)

Hi All,

Virtuozzo 7 has got an Update 10 published:
https://virtuozzosupport.force.com/s/article/VZA-2019-028

And corresponding update has been published to OpenVZ 7 as well:
https://download.openvz.org/virtuozzo/releases/openvz-7.0.10-252/

The update contains new kernel: 3.10.0-957.10.1.vz7.85.17,
the list of bugs fixed in the update is in the link for Virtuozzo update above.

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team

_______________________________________________
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


From jehan.procaccia at tem-tsp.eu  Thu Apr 25 23:37:14 2019
From: jehan.procaccia at tem-tsp.eu (Jehan Procaccia)
Date: Thu, 25 Apr 2019 22:37:14 +0200
Subject: [Users] 100.000 openVZ hosts with contaienrs
In-Reply-To: <HE1PR08MB1162EE65DDCBAF8E8742A11BB8B50@HE1PR08MB1162.eurprd08.prod.outlook.com>
References: <2b942a73-309c-57d7-eb6c-397f6d70ba6c@virtuozzo.com>
	<290781389.1812973.1545659460054.JavaMail.zimbra@imtbs-tsp.eu>
	<ed9081ba-27f9-553c-fe58-3daf70b87e80@virtuozzo.com>
	<HE1PR08MB1162AA6AB4C63F8395BCBACFB8BB0@HE1PR08MB1162.eurprd08.prod.outlook.com>
	<243129534.2084247.1545818977636.JavaMail.zimbra@imtbs-tsp.eu>
	<HE1PR08MB1162EE65DDCBAF8E8742A11BB8B50@HE1PR08MB1162.eurprd08.prod.outlook.com>
Message-ID: <e618c174-0f45-3621-dbef-fc713b2aa81b@tem-tsp.eu>

By the way , do you confirm that there is still no equivalent to 
https://stats.openvz.org/ for kernels 3.x / vz7 ?
I was told :

In OpenVZ7 and VZ7 this functionality is managed by disp-helper, https://docs.virtuozzo.com/virtuozzo_7_users_guide/advanced-tasks/participating-in-customer-experience-program.html

but:
# systemctl status disp-helper
Unit disp-helper.service could not be found.

although there is a /etc/vz/disp_helper.json , the files it points to 
are note existing
/var/log/collector.log
/var/log/vz-events.log

How can I participate in CEP ?
Can you give us stats regarding VZ7 usage ?

regards .


Le 26/12/2018 ? 11:14, Ivan Loginovskikh a ?crit?:
> There's no such equivalent.
>
>> -----Original Message-----
>> From: Jehan PROCACCIA <jehan.procaccia at tem-tsp.eu>
>> Sent: December 26, 2018 1:10 PM
>> To: Ivan Loginovskikh <iloginovskikh at virtuozzo.com>
>> Cc: OpenVZ users <users at openvz.org>; Kirill Kolyshkin (Gmail)
>> <kolyshkin at gmail.com>
>> Subject: Re: [Users] 100.000 openVZ hosts with contaienrs
>>
>> thanks , I will keep my vz7 reporting, it helps increase the stats ...
>> but is there a https://stats.openvz.org/ equivalent for kernels 3.x / vz7 ?
>>
>> thanks .
>>
>> Jehan PROCACCIA
>> Ing?nieur Infrastructures Num?riques
>> Membre du comit? de pilotage REVE:
>> R?seau d??vry Val d'Essonne
>> +33160764436
>>
>> 9 rue Charles Fourier - 91011 Evry Cedex [ https://www.imt-bs.eu/ |
>> www.imt-bs.eu ] - [ https://www.telecom-sudparis.eu/ | www.telecom-
>> sudparis.eu ]
>>
>> ----- Mail original -----
>> De: "Ivan Loginovskikh" <iloginovskikh at virtuozzo.com>
>> ?: "OpenVZ users" <users at openvz.org>, "Jehan PROCACCIA"
>> <jehan.procaccia at tem-tsp.eu>
>> Cc: "Kirill Kolyshkin" <kolyshkin at gmail.com>
>> Envoy?: Lundi 24 D?cembre 2018 17:46:02
>> Objet: RE: [Users] 100.000 openVZ hosts with contaienrs
>>
>> The previous answer is valid for VZ6. In OpenVZ7 and VZ7 this functionality is
>> managed by disp-helper,
>> https://docs.virtuozzo.com/virtuozzo_7_users_guide/advanced-
>> tasks/participating-in-customer-experience-program.html
>>
>>> -----Original Message-----
>>> From: users-bounces at openvz.org <users-bounces at openvz.org> On
>> Behalf Of
>>> Vasily Averin
>>> Sent: December 24, 2018 5:41 PM
>>> To: OpenVZ users <users at openvz.org>; Jehan PROCACCIA
>>> <jehan.procaccia at tem-tsp.eu>
>>> Cc: Kirill Kolyshkin (Gmail) <kolyshkin at gmail.com>
>>> Subject: Re: [Users] 100.000 openVZ hosts with contaienrs
>>>
>>> On 12/24/18 4:51 PM, Jehan PROCACCIA wrote:
>>>> hello
>>>>
>>>> very interesting and complete stats !
>>>> do you have the equivalent for openvz/virtuozzo 7 ?
>>>> I do use vz6 and vz7, but I can't remember how to enable sending
>>>> stats
>>> from the host server ? I would like to check if enable or not.
>>>> thanks.
>>> As kernel maintainer I'm not 100% sure, however it seems you can use
>>> prlsrvctl set --set off
>>>
>>> https://src.openvz.org/projects/OVZ/repos/prlctl/browse/src/CmdParam.c
>>> p
>>> p#37
>>>
>>>> ----- Mail original -----
>>>> De: "Vasily Averin" <vvs at virtuozzo.com>
>>>> ?: "OpenVZ users" <users at openvz.org>, "Kirill Kolyshkin"
>>> <kolyshkin at gmail.com>
>>>> Envoy?: Lundi 24 D?cembre 2018 13:40:49
>>>> Objet: [Users] 100.000 openVZ hosts with contaienrs
>>>>
>>>> OpenVz statistic shows that number of OpenVz6 hosts with containers
>>> reached 100.000
>>>> https://stats.openvz.org/
>>>>
>>>> Hosts with CTs:	100140
>>>> _______________________________________________
>>>> 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





From bkb at virtuozzo.com  Fri Apr 26 00:49:14 2019
From: bkb at virtuozzo.com (Konstantin Bukharov)
Date: Thu, 25 Apr 2019 21:49:14 +0000
Subject: [Users] 100.000 openVZ hosts with contaienrs
In-Reply-To: <e618c174-0f45-3621-dbef-fc713b2aa81b@tem-tsp.eu>
References: <2b942a73-309c-57d7-eb6c-397f6d70ba6c@virtuozzo.com>
	<290781389.1812973.1545659460054.JavaMail.zimbra@imtbs-tsp.eu>
	<ed9081ba-27f9-553c-fe58-3daf70b87e80@virtuozzo.com>
	<HE1PR08MB1162AA6AB4C63F8395BCBACFB8BB0@HE1PR08MB1162.eurprd08.prod.outlook.com>
	<243129534.2084247.1545818977636.JavaMail.zimbra@imtbs-tsp.eu>
	<HE1PR08MB1162EE65DDCBAF8E8742A11BB8B50@HE1PR08MB1162.eurprd08.prod.outlook.com>
	<e618c174-0f45-3621-dbef-fc713b2aa81b@tem-tsp.eu>
Message-ID: <HE1PR0802MB2395148FF9F6241C4D3EC5F9B23D0@HE1PR0802MB2395.eurprd08.prod.outlook.com>

Will check this.

-----Original Message-----
From: users-bounces at openvz.org <users-bounces at openvz.org> On Behalf Of Jehan Procaccia
Sent: Thursday, April 25, 2019 23:37
To: Ivan Loginovskikh <iloginovskikh at virtuozzo.com>
Cc: OpenVZ users <users at openvz.org>; Kirill Kolyshkin (Gmail) <kolyshkin at gmail.com>
Subject: Re: [Users] 100.000 openVZ hosts with contaienrs

By the way , do you confirm that there is still no equivalent to 
https://stats.openvz.org/ for kernels 3.x / vz7 ?
I was told :

In OpenVZ7 and VZ7 this functionality is managed by disp-helper, https://docs.virtuozzo.com/virtuozzo_7_users_guide/advanced-tasks/participating-in-customer-experience-program.html

but:
# systemctl status disp-helper
Unit disp-helper.service could not be found.

although there is a /etc/vz/disp_helper.json , the files it points to 
are note existing
/var/log/collector.log
/var/log/vz-events.log

How can I participate in CEP ?
Can you give us stats regarding VZ7 usage ?

regards .


Le 26/12/2018 ? 11:14, Ivan Loginovskikh a ?crit?:
> There's no such equivalent.
>
>> -----Original Message-----
>> From: Jehan PROCACCIA <jehan.procaccia at tem-tsp.eu>
>> Sent: December 26, 2018 1:10 PM
>> To: Ivan Loginovskikh <iloginovskikh at virtuozzo.com>
>> Cc: OpenVZ users <users at openvz.org>; Kirill Kolyshkin (Gmail)
>> <kolyshkin at gmail.com>
>> Subject: Re: [Users] 100.000 openVZ hosts with contaienrs
>>
>> thanks , I will keep my vz7 reporting, it helps increase the stats ...
>> but is there a https://stats.openvz.org/ equivalent for kernels 3.x / vz7 ?
>>
>> thanks .
>>
>> Jehan PROCACCIA
>> Ing?nieur Infrastructures Num?riques
>> Membre du comit? de pilotage REVE:
>> R?seau d??vry Val d'Essonne
>> +33160764436
>>
>> 9 rue Charles Fourier - 91011 Evry Cedex [ https://www.imt-bs.eu/ |
>> www.imt-bs.eu ] - [ https://www.telecom-sudparis.eu/ | www.telecom-
>> sudparis.eu ]
>>
>> ----- Mail original -----
>> De: "Ivan Loginovskikh" <iloginovskikh at virtuozzo.com>
>> ?: "OpenVZ users" <users at openvz.org>, "Jehan PROCACCIA"
>> <jehan.procaccia at tem-tsp.eu>
>> Cc: "Kirill Kolyshkin" <kolyshkin at gmail.com>
>> Envoy?: Lundi 24 D?cembre 2018 17:46:02
>> Objet: RE: [Users] 100.000 openVZ hosts with contaienrs
>>
>> The previous answer is valid for VZ6. In OpenVZ7 and VZ7 this functionality is
>> managed by disp-helper,
>> https://docs.virtuozzo.com/virtuozzo_7_users_guide/advanced-
>> tasks/participating-in-customer-experience-program.html
>>
>>> -----Original Message-----
>>> From: users-bounces at openvz.org <users-bounces at openvz.org> On
>> Behalf Of
>>> Vasily Averin
>>> Sent: December 24, 2018 5:41 PM
>>> To: OpenVZ users <users at openvz.org>; Jehan PROCACCIA
>>> <jehan.procaccia at tem-tsp.eu>
>>> Cc: Kirill Kolyshkin (Gmail) <kolyshkin at gmail.com>
>>> Subject: Re: [Users] 100.000 openVZ hosts with contaienrs
>>>
>>> On 12/24/18 4:51 PM, Jehan PROCACCIA wrote:
>>>> hello
>>>>
>>>> very interesting and complete stats !
>>>> do you have the equivalent for openvz/virtuozzo 7 ?
>>>> I do use vz6 and vz7, but I can't remember how to enable sending
>>>> stats
>>> from the host server ? I would like to check if enable or not.
>>>> thanks.
>>> As kernel maintainer I'm not 100% sure, however it seems you can use
>>> prlsrvctl set --set off
>>>
>>> https://src.openvz.org/projects/OVZ/repos/prlctl/browse/src/CmdParam.c
>>> p
>>> p#37
>>>
>>>> ----- Mail original -----
>>>> De: "Vasily Averin" <vvs at virtuozzo.com>
>>>> ?: "OpenVZ users" <users at openvz.org>, "Kirill Kolyshkin"
>>> <kolyshkin at gmail.com>
>>>> Envoy?: Lundi 24 D?cembre 2018 13:40:49
>>>> Objet: [Users] 100.000 openVZ hosts with contaienrs
>>>>
>>>> OpenVz statistic shows that number of OpenVz6 hosts with containers
>>> reached 100.000
>>>> https://stats.openvz.org/
>>>>
>>>> Hosts with CTs:	100140
>>>> _______________________________________________
>>>> 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




_______________________________________________
Users mailing list
Users at openvz.org
https://lists.openvz.org/mailman/listinfo/users


From jehan.procaccia at imtbs-tsp.eu  Thu Apr 25 23:30:06 2019
From: jehan.procaccia at imtbs-tsp.eu (Jehan PROCACCIA)
Date: Thu, 25 Apr 2019 22:30:06 +0200
Subject: [Users] Virtuozzo/OpenVZ 7.0 Update 10 (7.0.10-252)
In-Reply-To: <HE1PR0802MB2395AE95EEC74DD99A8B9FFEB23D0@HE1PR0802MB2395.eurprd08.prod.outlook.com>
References: <02281fbc-65b6-fb72-32c1-d02b0618c291@virtuozzo.com>
	<473451218.11559364.1556212340844.JavaMail.zimbra@imtbs-tsp.eu>
	<HE1PR0802MB2395AE95EEC74DD99A8B9FFEB23D0@HE1PR0802MB2395.eurprd08.prod.outlook.com>
Message-ID: <1975644318.11597912.1556224206315.JavaMail.zimbra@imtbs-tsp.eu>

OK, i did upgraded one of my servers, everything looks fine 

# uname -a 
Linux myhostname.domain.fr 3.10.0-957.10.1.vz7.85.17 #1 SMP Thu Apr 11 18:11:44 MSK 2019 x86_64 x86_64 x86_64 GNU/Linux
it was on 3.10.0-862.20.2.vz7.73.29 #1 SMP Thu Feb 21 bebore .
thanks .

Jehan PROCACCIA 
Ing?nieur syst?mes et r?seaux 
Membre du comit? de pilotage REVE : 
R?seau d??vry Val d'Essonne et THD 
+33160764436 
9 rue Charles Fourier - 91011 Evry Cedex 
[ https://www.imt-bs.eu/ | www.imt-bs.eu ] - [ https://www.telecom-sudparis.eu/ | www.telecom-sudparis.eu ]

----- Mail original -----
De: "Konstantin Bukharov" <bkb at virtuozzo.com>
?: "OpenVZ users" <users at openvz.org>
Envoy?: Jeudi 25 Avril 2019 21:38:02
Objet: Re: [Users] Virtuozzo/OpenVZ 7.0 Update 10 (7.0.10-252)

Hello,

It's a rebase update.

What were updated:
Linux kernel ? now based on RHEL 7.6 kernel 3.10.0-957.10.1.el7
QEMU ? - 2.12 (was 2.10 in Update 9)
Libvirt ? 4.5.0 (was 3.9.0)
CRIU ? 3.11 (was 3.10)
QEMU-GA ? 3.0.91 (was 2.90)

All linux user space packages correspond now to RHEL 7.6

Best regards,

-----Original Message-----
From: users-bounces at openvz.org <users-bounces at openvz.org> On Behalf Of Jehan PROCACCIA
Sent: Thursday, April 25, 2019 20:12
To: OpenVZ users <users at openvz.org>
Subject: Re: [Users] [Update] Virtuozzo/OpenVZ 7.0 Update 10 (7.0.10-252)

Hello,

this quite a big update, + 200 packages on my servers , i'll give it a try .

thanks .

----- Mail original -----
De: "Konstantin Khorenko" <khorenko at virtuozzo.com>
?: "OpenVZ users" <users at openvz.org>
Envoy?: Jeudi 25 Avril 2019 18:22:54
Objet: [Users] [Update] Virtuozzo/OpenVZ 7.0 Update 10 (7.0.10-252)

Hi All,

Virtuozzo 7 has got an Update 10 published:
https://virtuozzosupport.force.com/s/article/VZA-2019-028

And corresponding update has been published to OpenVZ 7 as well:
https://download.openvz.org/virtuozzo/releases/openvz-7.0.10-252/

The update contains new kernel: 3.10.0-957.10.1.vz7.85.17,
the list of bugs fixed in the update is in the link for Virtuozzo update above.

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team

_______________________________________________
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


From spameden at gmail.com  Fri Apr 26 22:36:35 2019
From: spameden at gmail.com (spameden)
Date: Fri, 26 Apr 2019 22:36:35 +0300
Subject: [Users] SSD trim support over a LUKS layer
In-Reply-To: <bbc70961-38c4-26e4-ba06-760d4acfcd3f@actiu.net>
References: <bbc70961-38c4-26e4-ba06-760d4acfcd3f@actiu.net>
Message-ID: <CAHCALex7pWgnGF8tVGUudqBCucTWsE8qt+2MJ-NsQFbFcONQ9w@mail.gmail.com>

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>:

> 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
> https://lists.openvz.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20190426/f74fece7/attachment.html>

From informatica at actiu.net  Sat Apr 27 11:08:21 2019
From: informatica at actiu.net (Narcis Garcia)
Date: Sat, 27 Apr 2019 10:08:21 +0200
Subject: [Users] SSD trim support over a LUKS layer
In-Reply-To: <CAHCALex7pWgnGF8tVGUudqBCucTWsE8qt+2MJ-NsQFbFcONQ9w@mail.gmail.com>
Message-ID: <41d82b38-4191-1dce-49e7-03d85f4d0772@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
> https://lists.openvz.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20190427/de95fc24/attachment-0001.html>

From bkb at virtuozzo.com  Sat Apr 27 11:51:43 2019
From: bkb at virtuozzo.com (Konstantin Bukharov)
Date: Sat, 27 Apr 2019 08:51:43 +0000
Subject: [Users] 100.000 openVZ hosts with contaienrs
In-Reply-To: <HE1PR0802MB2395148FF9F6241C4D3EC5F9B23D0@HE1PR0802MB2395.eurprd08.prod.outlook.com>
References: <2b942a73-309c-57d7-eb6c-397f6d70ba6c@virtuozzo.com>
	<290781389.1812973.1545659460054.JavaMail.zimbra@imtbs-tsp.eu>
	<ed9081ba-27f9-553c-fe58-3daf70b87e80@virtuozzo.com>
	<HE1PR08MB1162AA6AB4C63F8395BCBACFB8BB0@HE1PR08MB1162.eurprd08.prod.outlook.com>
	<243129534.2084247.1545818977636.JavaMail.zimbra@imtbs-tsp.eu>
	<HE1PR08MB1162EE65DDCBAF8E8742A11BB8B50@HE1PR08MB1162.eurprd08.prod.outlook.com>
	<e618c174-0f45-3621-dbef-fc713b2aa81b@tem-tsp.eu>
	<HE1PR0802MB2395148FF9F6241C4D3EC5F9B23D0@HE1PR0802MB2395.eurprd08.prod.outlook.com>
Message-ID: <HE1PR0802MB23951D29B75223EF3A8F60EFB23F0@HE1PR0802MB2395.eurprd08.prod.outlook.com>

Hi,

To join CEP you can install disp-helper package and check that service become active.
This package is available in OpenVZ distributions, like 
https://download.openvz.org/virtuozzo/releases/openvz-7.0.10-252/x86_64/os/Packages/d/disp-helper-0.0.171-2.vz7.x86_64.rpm

We are going to expose results, but no ETA now.
We have reports from 1791 OpenVZ7 nodes with 23612 CTs and 1015 VMs.

Best regards,

-----Original Message-----
From: users-bounces at openvz.org <users-bounces at openvz.org> On Behalf Of Konstantin Bukharov
Sent: Friday, April 26, 2019 0:49
To: OpenVZ users <users at openvz.org>; Ivan Loginovskikh <iloginovskikh at virtuozzo.com>
Cc: Kirill Kolyshkin (Gmail) <kolyshkin at gmail.com>
Subject: Re: [Users] 100.000 openVZ hosts with contaienrs

Will check this.

-----Original Message-----
From: users-bounces at openvz.org <users-bounces at openvz.org> On Behalf Of Jehan Procaccia
Sent: Thursday, April 25, 2019 23:37
To: Ivan Loginovskikh <iloginovskikh at virtuozzo.com>
Cc: OpenVZ users <users at openvz.org>; Kirill Kolyshkin (Gmail) <kolyshkin at gmail.com>
Subject: Re: [Users] 100.000 openVZ hosts with contaienrs

By the way , do you confirm that there is still no equivalent to 
https://stats.openvz.org/ for kernels 3.x / vz7 ?
I was told :

In OpenVZ7 and VZ7 this functionality is managed by disp-helper, https://docs.virtuozzo.com/virtuozzo_7_users_guide/advanced-tasks/participating-in-customer-experience-program.html

but:
# systemctl status disp-helper
Unit disp-helper.service could not be found.

although there is a /etc/vz/disp_helper.json , the files it points to 
are note existing
/var/log/collector.log
/var/log/vz-events.log

How can I participate in CEP ?
Can you give us stats regarding VZ7 usage ?

regards .


Le 26/12/2018 ? 11:14, Ivan Loginovskikh a ?crit?:
> There's no such equivalent.
>
>> -----Original Message-----
>> From: Jehan PROCACCIA <jehan.procaccia at tem-tsp.eu>
>> Sent: December 26, 2018 1:10 PM
>> To: Ivan Loginovskikh <iloginovskikh at virtuozzo.com>
>> Cc: OpenVZ users <users at openvz.org>; Kirill Kolyshkin (Gmail)
>> <kolyshkin at gmail.com>
>> Subject: Re: [Users] 100.000 openVZ hosts with contaienrs
>>
>> thanks , I will keep my vz7 reporting, it helps increase the stats ...
>> but is there a https://stats.openvz.org/ equivalent for kernels 3.x / vz7 ?
>>
>> thanks .
>>
>> Jehan PROCACCIA
>> Ing?nieur Infrastructures Num?riques
>> Membre du comit? de pilotage REVE:
>> R?seau d??vry Val d'Essonne
>> +33160764436
>>
>> 9 rue Charles Fourier - 91011 Evry Cedex [ https://www.imt-bs.eu/ |
>> www.imt-bs.eu ] - [ https://www.telecom-sudparis.eu/ | www.telecom-
>> sudparis.eu ]
>>
>> ----- Mail original -----
>> De: "Ivan Loginovskikh" <iloginovskikh at virtuozzo.com>
>> ?: "OpenVZ users" <users at openvz.org>, "Jehan PROCACCIA"
>> <jehan.procaccia at tem-tsp.eu>
>> Cc: "Kirill Kolyshkin" <kolyshkin at gmail.com>
>> Envoy?: Lundi 24 D?cembre 2018 17:46:02
>> Objet: RE: [Users] 100.000 openVZ hosts with contaienrs
>>
>> The previous answer is valid for VZ6. In OpenVZ7 and VZ7 this functionality is
>> managed by disp-helper,
>> https://docs.virtuozzo.com/virtuozzo_7_users_guide/advanced-
>> tasks/participating-in-customer-experience-program.html
>>
>>> -----Original Message-----
>>> From: users-bounces at openvz.org <users-bounces at openvz.org> On
>> Behalf Of
>>> Vasily Averin
>>> Sent: December 24, 2018 5:41 PM
>>> To: OpenVZ users <users at openvz.org>; Jehan PROCACCIA
>>> <jehan.procaccia at tem-tsp.eu>
>>> Cc: Kirill Kolyshkin (Gmail) <kolyshkin at gmail.com>
>>> Subject: Re: [Users] 100.000 openVZ hosts with contaienrs
>>>
>>> On 12/24/18 4:51 PM, Jehan PROCACCIA wrote:
>>>> hello
>>>>
>>>> very interesting and complete stats !
>>>> do you have the equivalent for openvz/virtuozzo 7 ?
>>>> I do use vz6 and vz7, but I can't remember how to enable sending
>>>> stats
>>> from the host server ? I would like to check if enable or not.
>>>> thanks.
>>> As kernel maintainer I'm not 100% sure, however it seems you can use
>>> prlsrvctl set --set off
>>>
>>> https://src.openvz.org/projects/OVZ/repos/prlctl/browse/src/CmdParam.c
>>> p
>>> p#37
>>>
>>>> ----- Mail original -----
>>>> De: "Vasily Averin" <vvs at virtuozzo.com>
>>>> ?: "OpenVZ users" <users at openvz.org>, "Kirill Kolyshkin"
>>> <kolyshkin at gmail.com>
>>>> Envoy?: Lundi 24 D?cembre 2018 13:40:49
>>>> Objet: [Users] 100.000 openVZ hosts with contaienrs
>>>>
>>>> OpenVz statistic shows that number of OpenVz6 hosts with containers
>>> reached 100.000
>>>> https://stats.openvz.org/
>>>>
>>>> Hosts with CTs:	100140
>>>> _______________________________________________
>>>> 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




_______________________________________________
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


From spameden at gmail.com  Sat Apr 27 13:47:08 2019
From: spameden at gmail.com (spameden)
Date: Sat, 27 Apr 2019 13:47:08 +0300
Subject: [Users] SSD trim support over a LUKS layer
In-Reply-To: <41d82b38-4191-1dce-49e7-03d85f4d0772@actiu.net>
References: <CAHCALex7pWgnGF8tVGUudqBCucTWsE8qt+2MJ-NsQFbFcONQ9w@mail.gmail.com>
	<41d82b38-4191-1dce-49e7-03d85f4d0772@actiu.net>
Message-ID: <CAHCALez-+CfAXN=w8jj==m++qkQuaVHepqQSFx31B6i0Bzh45A@mail.gmail.com>

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>:

> 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>:
>
>> 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
>> https://lists.openvz.org/mailman/listinfo/users
>>
>
> _______________________________________________
> Users mailing listUsers at openvz.orghttps://lists.openvz.org/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20190427/f83e478e/attachment.html>

From coolthecold at gmail.com  Sat Apr 27 17:25:37 2019
From: coolthecold at gmail.com (CoolCold)
Date: Sat, 27 Apr 2019 21:25:37 +0700
Subject: [Users] SSD trim support over a LUKS layer
In-Reply-To: <CAHCALez-+CfAXN=w8jj==m++qkQuaVHepqQSFx31B6i0Bzh45A@mail.gmail.com>
References: <CAHCALex7pWgnGF8tVGUudqBCucTWsE8qt+2MJ-NsQFbFcONQ9w@mail.gmail.com>
	<41d82b38-4191-1dce-49e7-03d85f4d0772@actiu.net>
	<CAHCALez-+CfAXN=w8jj==m++qkQuaVHepqQSFx31B6i0Bzh45A@mail.gmail.com>
Message-ID: <CAGqmV7pRBp07Yp7a=Ke98ZKLDu+a9nUVKMY_ct83Vir=hcp05A@mail.gmail.com>

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> 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>:
>
>> 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>:
>>
>>> 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
>>> https://lists.openvz.org/mailman/listinfo/users
>>>
>>
>> _______________________________________________
>> Users mailing listUsers at openvz.orghttps://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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20190427/acb163fe/attachment-0001.html>

From informatica at actiu.net  Sat Apr 27 17:38:30 2019
From: informatica at actiu.net (Narcis Garcia)
Date: Sat, 27 Apr 2019 16:38:30 +0200
Subject: [Users] SSD trim support over a LUKS layer
In-Reply-To: <CAGqmV7pRBp07Yp7a=Ke98ZKLDu+a9nUVKMY_ct83Vir=hcp05A@mail.gmail.com>
Message-ID: <99688df6-9fae-1fb4-9308-2daf36f782d9@actiu.net>

Thank you for recommendation; it's in my plans.
I hope sometime LXC allows to manage simfs/dir disk quotas, same as
vzquota. This is a very important matter for scenarios I have.

In the meanwhile, I administrer many OpenVZ/6 hosts without upgrade
calendar in short, and not all decisions (and time dedication) depend on
me. This is the reason to still be polishing OpenVZ/6 with Devuan/1.


El 27/4/19 a les 16:25, CoolCold ha escrit:
> 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
> https://lists.openvz.org/mailman/listinfo/users
> 

From spameden at gmail.com  Sat Apr 27 17:39:03 2019
From: spameden at gmail.com (spameden)
Date: Sat, 27 Apr 2019 17:39:03 +0300
Subject: [Users] SSD trim support over a LUKS layer
In-Reply-To: <CAGqmV7pRBp07Yp7a=Ke98ZKLDu+a9nUVKMY_ct83Vir=hcp05A@mail.gmail.com>
References: <CAHCALex7pWgnGF8tVGUudqBCucTWsE8qt+2MJ-NsQFbFcONQ9w@mail.gmail.com>
	<41d82b38-4191-1dce-49e7-03d85f4d0772@actiu.net>
	<CAHCALez-+CfAXN=w8jj==m++qkQuaVHepqQSFx31B6i0Bzh45A@mail.gmail.com>
	<CAGqmV7pRBp07Yp7a=Ke98ZKLDu+a9nUVKMY_ct83Vir=hcp05A@mail.gmail.com>
Message-ID: <CAHCALexFnL7k3Q0+=r+NkyBqh4up=AjHeWjm-rDjmucP8dUuxA@mail.gmail.com>

Furthermore there might be issues using old legacy OpenVZ6 kernel on modern
hardware, e.g. NVMe or any newer NIC cards.

Seeing as you've been using Debian as well as me for quite some time I'd
recommend - https://proxmox.com

In proxmox you can use unprivileged LXC containers (for security) as well
as containers with directory storage though they don't support quotas (but
you save on precious nvme disk storage).

There is also fancy webui, but I don't use it, mainly sticking to the
console pct tool and template's system.

There is a bit hassle regarding using external IPs in the containers, but
it's possible via certain workaround with iptables and routing.

Proxmox also works natively with latest Debian Stretch (with systemd) and
it's using recent kernel, e.g.:

# uname -r
4.15.18-12-pve

and yes discards work just fine on proxmox:

# dmsetup table|grep discards
***: 0 123 crypt aes-xts-plain64
0000000000000000000000000000000000000000000000000000000000000000 0 9:1 4096
1 allow_discards

Migration from OpenVZ6 is also very straightforward to Proxmox: in most
cases containers just do work (if you've been using simfs before) and not
requiring any modifications.



??, 27 ???. 2019 ?. ? 17:28, CoolCold <coolthecold at gmail.com>:

> 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> 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>:
>>
>>> 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>:
>>>
>>>> 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
>>>> https://lists.openvz.org/mailman/listinfo/users
>>>>
>>>
>>> _______________________________________________
>>> Users mailing listUsers at openvz.orghttps://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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20190427/e224ab26/attachment-0001.html>

From paulocoghi at gmail.com  Sat Apr 27 20:09:57 2019
From: paulocoghi at gmail.com (Paulo Coghi - Coghi IT)
Date: Sat, 27 Apr 2019 19:09:57 +0200
Subject: [Users] SSD trim support over a LUKS layer
In-Reply-To: <CAGqmV7pRBp07Yp7a=Ke98ZKLDu+a9nUVKMY_ct83Vir=hcp05A@mail.gmail.com>
References: <CAHCALex7pWgnGF8tVGUudqBCucTWsE8qt+2MJ-NsQFbFcONQ9w@mail.gmail.com>
	<41d82b38-4191-1dce-49e7-03d85f4d0772@actiu.net>
	<CAHCALez-+CfAXN=w8jj==m++qkQuaVHepqQSFx31B6i0Bzh45A@mail.gmail.com>
	<CAGqmV7pRBp07Yp7a=Ke98ZKLDu+a9nUVKMY_ct83Vir=hcp05A@mail.gmail.com>
Message-ID: <CADZgedrB0vPa5xAQm=WggKOps79E440-sF+pRwk37UXoQfc=yg@mail.gmail.com>

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> 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> 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>:
>>
>>> 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>:
>>>
>>>> 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
>>>> https://lists.openvz.org/mailman/listinfo/users
>>>>
>>>
>>> _______________________________________________
>>> Users mailing listUsers at openvz.orghttps://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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20190427/c0c62945/attachment.html>

From informatica at actiu.net  Sat Apr 27 20:14:56 2019
From: informatica at actiu.net (Narcis Garcia)
Date: Sat, 27 Apr 2019 19:14:56 +0200
Subject: [Users] SSD trim support over a LUKS layer
In-Reply-To: <CAHCALexFnL7k3Q0+=r+NkyBqh4up=AjHeWjm-rDjmucP8dUuxA@mail.gmail.com>
Message-ID: <1bc92a73-9d48-018e-117f-19ae6a709a95@actiu.net>

I responded about OpenVZ/6 vs LXC, and Proxmox doesn't solve the Discard
issue for OpenVZ/6 with a LUKS layer.

With any of Devuan 1, 2, Debian 8, 9 kernels, Discard works fine with
LUKS layer (with or without LXC), and Proxmox doesn't help in this.


El 27/4/19 a les 16:39, spameden ha escrit:
> Furthermore there might be issues using old legacy OpenVZ6 kernel on
> modern hardware, e.g. NVMe or any newer NIC cards.
> 
> Seeing as you've been using Debian as well as me for quite some time I'd
> recommend - https://proxmox.com?
> 
> In proxmox you can use unprivileged LXC containers (for security) as
> well as containers with directory storage though they don't support
> quotas (but you save on precious nvme disk storage).
> 
> There is also fancy webui, but I don't use it, mainly sticking to the
> console pct tool and template's system.
> 
> There is a bit hassle regarding using external IPs in the containers,
> but it's possible via certain workaround with iptables and routing.
> 
> Proxmox also works natively with latest Debian Stretch (with systemd)
> and it's using recent kernel, e.g.:
> 
> # uname -r
> 4.15.18-12-pve
> 
> and yes discards work just fine on proxmox:
> 
> # dmsetup table|grep discards
> ***: 0 123 crypt aes-xts-plain64
> 0000000000000000000000000000000000000000000000000000000000000000 0 9:1
> 4096 1 allow_discards
> 
> Migration from OpenVZ6 is also very straightforward to Proxmox: in most
> cases containers just do work (if you've been using simfs before) and
> not requiring any modifications.
> 
> 
> 
> ??, 27 ???. 2019 ?. ? 17:28, CoolCold <coolthecold at gmail.com
> <mailto:coolthecold at gmail.com>>:
> 
>     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
> 

From informatica at actiu.net  Sat Apr 27 20:19:43 2019
From: informatica at actiu.net (Narcis Garcia)
Date: Sat, 27 Apr 2019 19:19:43 +0200
Subject: [Users] SSD trim support over a LUKS layer
In-Reply-To: <CADZgedrB0vPa5xAQm=WggKOps79E440-sF+pRwk37UXoQfc=yg@mail.gmail.com>
Message-ID: <f9b23b40-ba00-f4e8-1891-873110ede019@actiu.net>

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
> 

From spameden at gmail.com  Sat Apr 27 23:15:03 2019
From: spameden at gmail.com (spameden)
Date: Sat, 27 Apr 2019 23:15:03 +0300
Subject: [Users] SSD trim support over a LUKS layer
In-Reply-To: <1bc92a73-9d48-018e-117f-19ae6a709a95@actiu.net>
References: <CAHCALexFnL7k3Q0+=r+NkyBqh4up=AjHeWjm-rDjmucP8dUuxA@mail.gmail.com>
	<1bc92a73-9d48-018e-117f-19ae6a709a95@actiu.net>
Message-ID: <CAHCALexN2cjhOpBkdgrsNhUstZpOjHEasTLaH-n2WB7WMw3u1w@mail.gmail.com>

??, 27 ???. 2019 ?. ? 20:16, Narcis Garcia <informatica at actiu.net>:

> 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.


> issue for OpenVZ/6 with a LUKS layer.
>
> With any of Devuan 1, 2, Debian 8, 9 kernels, Discard works fine with
> LUKS layer (with or without LXC), and Proxmox doesn't help in this.
>
>
> El 27/4/19 a les 16:39, spameden ha escrit:
> > Furthermore there might be issues using old legacy OpenVZ6 kernel on
> > modern hardware, e.g. NVMe or any newer NIC cards.
> >
> > Seeing as you've been using Debian as well as me for quite some time I'd
> > recommend - https://proxmox.com
> >
> > In proxmox you can use unprivileged LXC containers (for security) as
> > well as containers with directory storage though they don't support
> > quotas (but you save on precious nvme disk storage).
> >
> > There is also fancy webui, but I don't use it, mainly sticking to the
> > console pct tool and template's system.
> >
> > There is a bit hassle regarding using external IPs in the containers,
> > but it's possible via certain workaround with iptables and routing.
> >
> > Proxmox also works natively with latest Debian Stretch (with systemd)
> > and it's using recent kernel, e.g.:
> >
> > # uname -r
> > 4.15.18-12-pve
> >
> > and yes discards work just fine on proxmox:
> >
> > # dmsetup table|grep discards
> > ***: 0 123 crypt aes-xts-plain64
> > 0000000000000000000000000000000000000000000000000000000000000000 0 9:1
> > 4096 1 allow_discards
> >
> > Migration from OpenVZ6 is also very straightforward to Proxmox: in most
> > cases containers just do work (if you've been using simfs before) and
> > not requiring any modifications.
> >
> >
> >
> > ??, 27 ???. 2019 ?. ? 17:28, CoolCold <coolthecold at gmail.com
> > <mailto:coolthecold at gmail.com>>:
> >
> >     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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20190427/f98c7efa/attachment-0001.html>

From informatica at actiu.net  Sun Apr 28 09:44:20 2019
From: informatica at actiu.net (Narcis Garcia)
Date: Sun, 28 Apr 2019 08:44:20 +0200
Subject: [Users] SSD trim support over a LUKS layer
In-Reply-To: <CAHCALexN2cjhOpBkdgrsNhUstZpOjHEasTLaH-n2WB7WMw3u1w@mail.gmail.com>
Message-ID: <751fd7b6-9e07-5773-191a-18a7e5df4284@actiu.net>

El 27/4/19 a les 22:15, spameden ha escrit:
> 
> ??, 27 ???. 2019 ?. ? 20:16, Narcis Garcia <informatica at actiu.net
> <mailto:informatica at actiu.net>>:
> 
>     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 ?

From spameden at gmail.com  Sun Apr 28 15:37:35 2019
From: spameden at gmail.com (spameden)
Date: Sun, 28 Apr 2019 15:37:35 +0300
Subject: [Users] SSD trim support over a LUKS layer
In-Reply-To: <751fd7b6-9e07-5773-191a-18a7e5df4284@actiu.net>
References: <CAHCALexN2cjhOpBkdgrsNhUstZpOjHEasTLaH-n2WB7WMw3u1w@mail.gmail.com>
	<751fd7b6-9e07-5773-191a-18a7e5df4284@actiu.net>
Message-ID: <CAHCALex8iJSkWnpp5tPU1O6upHChT=TOcy704Q80FYAmkG2chQ@mail.gmail.com>

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 <informatica at actiu.net>:

> El 27/4/19 a les 22:15, spameden ha escrit:
> >
> > ??, 27 ???. 2019 ?. ? 20:16, Narcis Garcia <informatica at actiu.net
> > <mailto:informatica at actiu.net>>:
> >
> >     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 at openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20190428/b5d0c20d/attachment.html>

From jehan.procaccia at tem-tsp.eu  Sun Apr 28 22:55:03 2019
From: jehan.procaccia at tem-tsp.eu (Jehan PROCACCIA)
Date: Sun, 28 Apr 2019 21:55:03 +0200
Subject: [Users] distro virtuozzo vs proxmox
In-Reply-To: <f9b23b40-ba00-f4e8-1891-873110ede019@actiu.net>
References: <f9b23b40-ba00-f4e8-1891-873110ede019@actiu.net>
Message-ID: <1419788028.12424498.1556481303105.JavaMail.zimbra@imtbs-tsp.eu>

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


From ccto at website-solution.net  Mon Apr 29 05:16:51 2019
From: ccto at website-solution.net (Website Solution - George)
Date: Mon, 29 Apr 2019 10:16:51 +0800
Subject: [Users] distro virtuozzo vs proxmox
In-Reply-To: <1419788028.12424498.1556481303105.JavaMail.zimbra@imtbs-tsp.eu>
References: <f9b23b40-ba00-f4e8-1891-873110ede019@actiu.net>
	<1419788028.12424498.1556481303105.JavaMail.zimbra@imtbs-tsp.eu>
Message-ID: <fafa9a0f-8c50-4545-9568-685d0b768377@website-solution.net>


 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


From informatica at actiu.net  Mon Apr 29 11:40:21 2019
From: informatica at actiu.net (Narcis Garcia)
Date: Mon, 29 Apr 2019 10:40:21 +0200
Subject: [Users] SSD trim support over a LUKS layer
In-Reply-To: <CAHCALex8iJSkWnpp5tPU1O6upHChT=TOcy704Q80FYAmkG2chQ@mail.gmail.com>
Message-ID: <13338de1-9707-07b4-90d0-3c77a7a792ff@actiu.net>

Definitely we'll not migrate to Proxmox because it's suboptimal writing
this in OpenDocument format from an HTML5 interface.


El 28/4/19 a les 14:37, spameden ha escrit:
> 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 <informatica at actiu.net
> <mailto:informatica at actiu.net>>:
> 
>     El 27/4/19 a les 22:15, spameden ha escrit:
>     >
>     > ??, 27 ???. 2019 ?. ? 20:16, Narcis Garcia <informatica at actiu.net
>     <mailto:informatica at actiu.net>
>     > <mailto:informatica at actiu.net <mailto:informatica at actiu.net>>>:
>     >
>     >? ? ?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 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
> 

From informatica at actiu.net  Mon Apr 29 11:47:27 2019
From: informatica at actiu.net (Narcis Garcia)
Date: Mon, 29 Apr 2019 10:47:27 +0200
Subject: [Users] distro virtuozzo vs proxmox
In-Reply-To: <fafa9a0f-8c50-4545-9568-685d0b768377@website-solution.net>
Message-ID: <2c3c6f00-6821-c304-f5c0-4fe121ddadc4@actiu.net>

Yes, these are the right comparisons:

OpenVZ vs LXC
Virtuozzo distro vs Proxmox distro
CentOS vs Debian vs Other general purpose distros

+ Interesting to know the support to run OpenVZ 7 on CentOS.
It should be documented at OpenVZ wiki!


El 29/4/19 a les 4:16, Website Solution - George ha escrit:
> 
> 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
> 
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://lists.openvz.org/mailman/listinfo/users

From paulocoghi at gmail.com  Mon Apr 29 11:52:20 2019
From: paulocoghi at gmail.com (Paulo Coghi - Coghi IT)
Date: Mon, 29 Apr 2019 10:52:20 +0200
Subject: [Users] SSD trim support over a LUKS layer
In-Reply-To: <13338de1-9707-07b4-90d0-3c77a7a792ff@actiu.net>
References: <CAHCALex8iJSkWnpp5tPU1O6upHChT=TOcy704Q80FYAmkG2chQ@mail.gmail.com>
	<13338de1-9707-07b4-90d0-3c77a7a792ff@actiu.net>
Message-ID: <CADZgedpX_XRhWnvA7Gskn42=-RKE1oMY0OdgVTOgv9k5GP5xDg@mail.gmail.com>

Why suggest LXC when we have OpenVZ 7? LXC is far behind, it has less
features, it's more insecure, has a network standard that is a nightmare,
etc.

I stopped using proxmox from the exact moment it removed OpenVZ support and
replaced it with LXC.

Now a happy customer with Virtuozzo 7 (the same as OpenVZ 7) using multiple
NVMe drives with zero issues for almost 2 years.

On Mon, Apr 29, 2019 at 10:42 AM Narcis Garcia <informatica at actiu.net>
wrote:

> Definitely we'll not migrate to Proxmox because it's suboptimal writing
> this in OpenDocument format from an HTML5 interface.
>
>
> El 28/4/19 a les 14:37, spameden ha escrit:
> > 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 <informatica at actiu.net
> > <mailto:informatica at actiu.net>>:
> >
> >     El 27/4/19 a les 22:15, spameden ha escrit:
> >     >
> >     > ??, 27 ???. 2019 ?. ? 20:16, Narcis Garcia <informatica at actiu.net
> >     <mailto:informatica at actiu.net>
> >     > <mailto:informatica at actiu.net <mailto:informatica at actiu.net>>>:
> >     >
> >     >     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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20190429/4f64322f/attachment-0001.html>

From paulocoghi at gmail.com  Mon Apr 29 11:56:30 2019
From: paulocoghi at gmail.com (Paulo Coghi - Coghi IT)
Date: Mon, 29 Apr 2019 10:56:30 +0200
Subject: [Users] SSD trim support over a LUKS layer
In-Reply-To: <CADZgedpX_XRhWnvA7Gskn42=-RKE1oMY0OdgVTOgv9k5GP5xDg@mail.gmail.com>
References: <CAHCALex8iJSkWnpp5tPU1O6upHChT=TOcy704Q80FYAmkG2chQ@mail.gmail.com>
	<13338de1-9707-07b4-90d0-3c77a7a792ff@actiu.net>
	<CADZgedpX_XRhWnvA7Gskn42=-RKE1oMY0OdgVTOgv9k5GP5xDg@mail.gmail.com>
Message-ID: <CADZgedoiEw1K6AFpq0DouPS8qqZdiN31Ad43KVQo_Z6jkqjTzA@mail.gmail.com>

I apologize for the duplicate message. I forgot that I had already sent a
message before.

On Mon, Apr 29, 2019 at 10:52 AM Paulo Coghi - Coghi IT <
paulocoghi at gmail.com> wrote:

> Why suggest LXC when we have OpenVZ 7? LXC is far behind, it has less
> features, it's more insecure, has a network standard that is a nightmare,
> etc.
>
> I stopped using proxmox from the exact moment it removed OpenVZ support
> and replaced it with LXC.
>
> Now a happy customer with Virtuozzo 7 (the same as OpenVZ 7) using
> multiple NVMe drives with zero issues for almost 2 years.
>
> On Mon, Apr 29, 2019 at 10:42 AM Narcis Garcia <informatica at actiu.net>
> wrote:
>
>> Definitely we'll not migrate to Proxmox because it's suboptimal writing
>> this in OpenDocument format from an HTML5 interface.
>>
>>
>> El 28/4/19 a les 14:37, spameden ha escrit:
>> > 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 <informatica at actiu.net
>> > <mailto:informatica at actiu.net>>:
>> >
>> >     El 27/4/19 a les 22:15, spameden ha escrit:
>> >     >
>> >     > ??, 27 ???. 2019 ?. ? 20:16, Narcis Garcia <informatica at actiu.net
>> >     <mailto:informatica at actiu.net>
>> >     > <mailto:informatica at actiu.net <mailto:informatica at actiu.net>>>:
>> >     >
>> >     >     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 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20190429/1cd9f5c3/attachment.html>

From paulocoghi at gmail.com  Mon Apr 29 13:26:35 2019
From: paulocoghi at gmail.com (Paulo Coghi - Coghi IT)
Date: Mon, 29 Apr 2019 12:26:35 +0200
Subject: [Users] distro virtuozzo vs proxmox
In-Reply-To: <2c3c6f00-6821-c304-f5c0-4fe121ddadc4@actiu.net>
References: <fafa9a0f-8c50-4545-9568-685d0b768377@website-solution.net>
	<2c3c6f00-6821-c304-f5c0-4fe121ddadc4@actiu.net>
Message-ID: <CADZgedqAN0HYbruzFTQDncmX55+NGu+SSGAV4xSOQzZTEDTVsw@mail.gmail.com>

My 2 cents.

*OpenVZ vs LXC*
OpenVZ requires a patched kernel, but it's finally updated with OVZ7
OpenVZ is gradually porting its technology to mainline Linux kernel
OpenVZ has a more battle tested OS virtualization technology
LXC is still more insecure
LXC has a more complex way to configure networks

*Virtuozzo vs Proxmox*
Virtuozzo better integrates OpenVZ with its features and capabilities, like
live migration, distributed storage, live snapshots, etc
Virtuozzo is made and maintained by the same company that maintains OpenVZ
itself, and buying its licenses helps the future of OpenVZ
Virtuozzo includes specialized tools to manage and ensure the healthy of
your distributed storage cluster, subdivides it in different layers of
performance and purpose, etc
Virtuozzo has a great and responsive support team, in my experience
Virtuozzo enhanced KVM a lot, that provides more server density and
performance
Virtuozzo is one of the main KVM contributors, and contributes to other
projects as well, as Linux Kernel, OpenStack, etc
Proxmox was famous when offered OpenVZ on its platform (not offering
anymore, replacing it by LXC)
Proxmox is made and maintained by a company not related to OpenVZ project
itself
Proxmox has a great and responsive support team, in my experience

On Mon, Apr 29, 2019 at 10:48 AM Narcis Garcia <informatica at actiu.net>
wrote:

> Yes, these are the right comparisons:
>
> OpenVZ vs LXC
> Virtuozzo distro vs Proxmox distro
> CentOS vs Debian vs Other general purpose distros
>
> + Interesting to know the support to run OpenVZ 7 on CentOS.
> It should be documented at OpenVZ wiki!
>
>
> El 29/4/19 a les 4:16, Website Solution - George ha escrit:
> >
> > 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
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20190429/1e703d05/attachment-0001.html>

From coolthecold at gmail.com  Mon Apr 29 20:10:07 2019
From: coolthecold at gmail.com (CoolCold)
Date: Tue, 30 Apr 2019 00:10:07 +0700
Subject: [Users] SSD trim support over a LUKS layer
In-Reply-To: <CADZgedpX_XRhWnvA7Gskn42=-RKE1oMY0OdgVTOgv9k5GP5xDg@mail.gmail.com>
References: <CAHCALex8iJSkWnpp5tPU1O6upHChT=TOcy704Q80FYAmkG2chQ@mail.gmail.com>
	<13338de1-9707-07b4-90d0-3c77a7a792ff@actiu.net>
	<CADZgedpX_XRhWnvA7Gskn42=-RKE1oMY0OdgVTOgv9k5GP5xDg@mail.gmail.com>
Message-ID: <CAGqmV7r-3D2H3mLZ0JR=+YRJDCez7k4yC_7wehKZNqdR914ufA@mail.gmail.com>

On Mon, Apr 29, 2019 at 3:53 PM Paulo Coghi - Coghi IT <paulocoghi at gmail.com>
wrote:

> Why suggest LXC when we have OpenVZ 7? LXC is far behind, it has less
> features, it's more insecure, has a network standard that is a nightmare,
> etc.
>
As some members of this maillist mentioned, not everyone wants to change
into specific distribution comparing to general purpose distribution. I.e.
having Debian based instalation action as application server with, for
example some containers as an addition (my case). Moving to Centos based
world brings it's own complications for some people.

>
> I stopped using proxmox from the exact moment it removed OpenVZ support
> and replaced it with LXC.
>
> Now a happy customer with Virtuozzo 7 (the same as OpenVZ 7) using
> multiple NVMe drives with zero issues for almost 2 years.
>
> On Mon, Apr 29, 2019 at 10:42 AM Narcis Garcia <informatica at actiu.net>
> wrote:
>
>> Definitely we'll not migrate to Proxmox because it's suboptimal writing
>> this in OpenDocument format from an HTML5 interface.
>>
>>
>> El 28/4/19 a les 14:37, spameden ha escrit:
>> > 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 <informatica at actiu.net
>> > <mailto:informatica at actiu.net>>:
>> >
>> >     El 27/4/19 a les 22:15, spameden ha escrit:
>> >     >
>> >     > ??, 27 ???. 2019 ?. ? 20:16, Narcis Garcia <informatica at actiu.net
>> >     <mailto:informatica at actiu.net>
>> >     > <mailto:informatica at actiu.net <mailto:informatica at actiu.net>>>:
>> >     >
>> >     >     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 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
>


-- 
Best regards,
[COOLCOLD-RIPN]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20190430/8242bf53/attachment.html>