[Users] distro virtuozzo vs proxmox
Paulo Coghi - Coghi IT
paulocoghi at gmail.com
Wed May 1 12:43:53 MSK 2019
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 <alexeyzilber at 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.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
>>
> _______________________________________________
> 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/8e0297b5/attachment-0001.html>
More information about the Users
mailing list