Alexey, it was Jehan who asked. But thanks to reinforce. Sure, OpenVZ *is* a virtualization technology, as well as LXC, Jails, LXD, Rkt, Systemd Nspawn, etc.
On Wed, May 1, 2019 at 4:18 AM Alexey Zilber <alexeyzil...@gmail.com> wrote: > Paulo, > > The container technology in OpenVZ is OpenVZ. As in: > > LXD, Rkt, Docker, OpenVZ. > > Here's a little comparison: > https://www.contino.io/insights/beyond-docker-other-types-of-containers > > OpenVZ is one of the oldest container technologies. I believe FreeBSD > Jails is probably considered the first. > > -Alex > > On Wed, May 1, 2019 at 5:33 AM Jehan PROCACCIA <jehan.procac...@tem-tsp.eu> > wrote: > >> Thanks for those comparisons >> I still wonder though what is the container technology used by >> virtuozzo/openVZ7 ? >> from >> https://www.slideshare.net/openvz/whats-missing-from-upstream-kernel-containers-kir-kolyshkin >> I understand that it is patches to kernel that takes advantages of kernel >> namespaces, cgroups etc .. ? >> is that right ? >> other insteresting reading, but probably a little oriented towards lxd >> ... : >> https://containerjournal.com/2017/01/09/comparing-openvz-lxd-linux-system-container-platforms/ >> it still beleive that choice between technologies proxmox / virtuozzo is >> driven by the linux distribution a sysadmin is most familiar with . >> anyway, I 'am happy and surprised by the 1st reference above that >> virtuozzo is that much contributing to the kernel and is so close to a >> native kernel . >> >> >> ------------------------------ >> *De: *"Paulo Coghi - Coghi IT" <pauloco...@gmail.com> >> *À: *"OpenVZ users" <users@openvz.org> >> *Envoyé: *Lundi 29 Avril 2019 12:26:35 >> *Objet: *Re: [Users] distro virtuozzo vs proxmox >> >> 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 <informat...@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" <informat...@actiu.net> >>> >> À: "OpenVZ users" <users@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 <coolthec...@gmail.com >>> >>> <mailto:coolthec...@gmail.com>> wrote: >>> >>> >>> >>> I believe to have fixes and backports like this in to legacy >>> >>> version >>> >>> of product will not happen, and you should consider upgrading. >>> >>> Personally, I've upgraded to lxc.. it's quite primitive >>> >>> comparing to >>> >>> ovz 6, but it's enough for my needs. >>> >>> >>> >>> On Sat, Apr 27, 2019, 17:49 spameden <spame...@gmail.com >>> >>> <mailto:spame...@gmail.com>> wrote: >>> >>> >>> >>> Yes, it's an issue in kernel. >>> >>> >>> >>> As dm-crypt/luks layer isn't passing TRIM to the underlying >>> >>> device. >>> >>> >>> >>> /boot is not encrypted that's why it works for you. >>> >>> >>> >>> сб, 27 апр. 2019 г. в 11:11, Narcis Garcia >>> >>> <informat...@actiu.net <mailto:informat...@actiu.net>>: >>> >>> >>> >>> See in the case that /dev/sda1 (Directly mounted as >>> Ext4 on >>> >>> /boot) works with Trim/Discard. >>> >>> It's the sda2_crypt (layer over sda2) that is not >>> detected >>> >>> to be trimmable. Devuan's stock kernel does. >>> >>> >>> >>> CentOS issue #6548 may not be this same bug; I've tested >>> >>> now >>> >>> with CentOS 6.8 with a similar (but not same) result*:* >>> >>> >>> >>> $ lsb_release -d >>> >>> Description: CentOS release 6.8 (Final) >>> >>> >>> >>> $ uname -a >>> >>> Linux localhost.localdomain 2.6.32-642.el6.x86_64 #1 SMP >>> >>> Tue >>> >>> May 10 17:27:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux >>> >>> >>> >>> $ lsblk --discard /dev/sda >>> >>> NAME >>> >>> DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO >>> >>> sda >>> >>> 0 512B 2G 0 >>> >>> ├─sda1 >>> >>> 0 512B 2G 0 >>> >>> └─sda2 >>> >>> 0 512B 2G 0 >>> >>> └─luks-f691f48b-8556-487d-ac64-50daa99ed4c9 (dm-0) >>> >>> 0 512B 2G 0 >>> >>> >>> >>> $ cat /etc/crypttab >>> >>> luks-f691f48b-8556-487d-ac64-50daa99ed4c9 >>> >>> UUID=f691f48b-8556-487d-ac64-50daa99ed4c9 none >>> luks,discard >>> >>> >>> >>> $ mount | grep -e discard >>> >>> /dev/mapper/luks-f691f48b-8556-487d-ac64-50daa99ed4c9 >>> on / >>> >>> type ext4 (rw,discard) >>> >>> /dev/sda1 on /boot type ext4 (rw,discard) >>> >>> >>> >>> $ sudo fstrim /boot >>> >>> # (same result as Devuan/1 and OpenVZ/6 kernel: success) >>> >>> >>> >>> $ sudo fstrim / >>> >>> fstrim: /: FITRIM ioctl failed: Operation not supported >>> >>> >>> >>> >>> >>> El 26/4/19 a les 21:36, spameden ha escrit: >>> >>>> Hi. >>> >>>> >>> >>>> I've asked this question years ago (in >>> >>>> >>> >>>> 2013): >>> https://lists.openvz.org/pipermail/users/2013-August/005250.html >>> >>>> >>> >>>> Let me know if it helps, but this bug should have been >>> >>>> fixed in CentOS and RHEL at >>> >>>> least: https://bugs.centos.org/view.php?id=6548 >>> >>>> >>> >>>> Maybe OpenVZ maintainers didn't pick up this fix in the >>> >>>> openvz6 legacy kernel? >>> >>>> >>> >>>> Thanks. >>> >>>> >>> >>>> ср, 10 апр. 2019 г. в 10:45, Narcis Garcia >>> >>>> <informat...@actiu.net <mailto:informat...@actiu.net >>> >>: >>> >>>> >>> >>>> Does anybody know how can I solve this? >>> >>>> >>> >>>> $ lsb_release -d >>> >>>> Description: Devuan GNU/Linux 1.0 (jessie) >>> >>>> >>> >>>> $ uname -a >>> >>>> Linux bell1 2.6.32-openvz-042stab134.8-amd64 #1 SMP >>> >>>> Fri Dec 7 17:18:40 >>> >>>> 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@openvz.org <mailto:Users@openvz.org> >>> >>>> https://lists.openvz.org/mailman/listinfo/users >>> >>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> Users mailing list >>> >>>> Users@openvz.org <mailto:Users@openvz.org> >>> >>>> https://lists.openvz.org/mailman/listinfo/users >>> >>> _______________________________________________ >>> >>> Users mailing list >>> >>> Users@openvz.org <mailto:Users@openvz.org> >>> >>> https://lists.openvz.org/mailman/listinfo/users >>> >>> >>> >>> _______________________________________________ >>> >>> Users mailing list >>> >>> Users@openvz.org <mailto:Users@openvz.org> >>> >>> https://lists.openvz.org/mailman/listinfo/users >>> >>> >>> >>> _______________________________________________ >>> >>> Users mailing list >>> >>> Users@openvz.org <mailto:Users@openvz.org> >>> >>> https://lists.openvz.org/mailman/listinfo/users >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Users mailing list >>> >>> Users@openvz.org >>> >>> https://lists.openvz.org/mailman/listinfo/users >>> >>> >>> >> _______________________________________________ >>> >> Users mailing list >>> >> Users@openvz.org >>> >> https://lists.openvz.org/mailman/listinfo/users >>> >> >>> >> _______________________________________________ >>> >> Users mailing list >>> >> Users@openvz.org >>> >> https://lists.openvz.org/mailman/listinfo/users >>> > >>> > _______________________________________________ >>> > Users mailing list >>> > Users@openvz.org >>> > https://lists.openvz.org/mailman/listinfo/users >>> _______________________________________________ >>> Users mailing list >>> Users@openvz.org >>> https://lists.openvz.org/mailman/listinfo/users >>> >> >> _______________________________________________ >> Users mailing list >> Users@openvz.org >> https://lists.openvz.org/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing list >> Users@openvz.org >> https://lists.openvz.org/mailman/listinfo/users >> > _______________________________________________ > Users mailing list > Users@openvz.org > https://lists.openvz.org/mailman/listinfo/users >
_______________________________________________ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users