[Users] distro virtuozzo vs proxmox
Alexey Zilber
alexeyzilber at gmail.com
Wed May 1 05:15:36 MSK 2019
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.procaccia at 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" <paulocoghi at gmail.com>
> *À: *"OpenVZ users" <users at 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 <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
>>
>
> _______________________________________________
> 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/20190501/dfcba623/attachment-0001.html>
More information about the Users
mailing list