New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Anyone here still stuck on OpenVZ 6 and want new software?
I'm wondering if some technical discussion would be welcome here, and if OpenVZ 6 is still widely in use.
I myself rent an OpenVZ 6 VPS. The OS was originally Ubuntu 16.04, and now I've upgraded it to Ubuntu 20.04. The issue with Ubuntu 16.04 is its old software selection... (nginx was stuck at version 1.10.......)
Anyway, I did the upgrade by recompiling libc. If anyone's interested I can share my (messy ...) scripts here 
and maybe have a discussion, since it still has some limitations.
Comments
If you are still stuck on OpenVZ 6 you should terminate immediately.
Also name the provider please.
@noezde or @noezgermany still have oVZ6 services.. only provider I remember who did not switch their customers.
I'm having KVM only except with HostUS who switched my plan to LXC for free. So far so nice though no big improvement performance wise.
LXC tends to only show the host node's load averages though.
Also, time4vps has storage servers running OpenVZ. @yoursunny start the OVZ6 hall of shame?
This is easy to fix.
With Proxmox and other solutions for example you just need to add the option -l to ExecStart inside the file /lib/systemd/system/lxcfs.service
No one here really wants to have a discussion about how to survive with OVZ 6 when it would make much more sense to leave OVZ 6
Well, can I not do both?
It's one of the cheapest unmetered VPSes I can find over here, and the plan is not available anymore (they just keep renewing my service), so the tinkering is actually part of the fun.
Also, my country's network is basically tethered to the regional hub, so overseas nodes have terrible pings. This node is actually my main node nowadays, the others are overseas so SSH is slow...
I'm quite impressed with the service. A few days ago, when I was still trying to figure out a way to use new libc6 binaries without recompiling (I managed to make it work somewhat via binary patching), I accidentally borked the installation. I told them it was just 2 wrong symlinks, and they fixed the issue within the hour, just after midnight. That was awesome.
It's just fun for me
I do understand that I shouldn't probably use this node in production though.
Didn't feel like a downgrade. Applications are still working and performance is comparable.
Dedi is classified as ENTERPRISE
KVM is classified as premium grade.
OVZ is wood class, LXC is somewhere in-between wood and premium.
Shared Hosting is below wood, more like Evergreen, if it does even float, it will get stuck.
I prefer OVZ over LXC. why would LXC be better?
That's not true. Openvz can run ubuntu 20 with the new kernel. You can create a docker container in openvz too.
Not tried ovz 6 but I am using openvz 7 without any problems and I am very happy so far. Have not tried this lxc yet
I know there have been many security issues with lxc
I did not talk about Ubuntu 20.04 but, it gets delivered with 5.4 Kernel, you likely won't get it properly to run without any modifications on 3.x.
I did not say they won't work, I did say however out of the box aka no modifications.
If you are happy, then its fine.
Same with OVZ, I saw a few container breakouts.
Now I understand your meme. Switched to LXC from oVZ6 not KVM. I was imprecise, sorry. Everything else expect this box (oVZ6 -> LXC) is KVM.
Docker works on VirMach KVM (384MB).
Docker works on Gullo OpenVZ 7 (256MB).
Docker crashes on microLXC (256MB).
"No sane person would run Docker on 256MB"
Neoon May 2021
LXC in LXC inside the container is disabled so likely Docker won't work .
Should work with a few changes, however insane.
edit:
"No real security impact for unprivileged containers, rather disastrous security impacts for privileged containers (it allows bypassing apparmor and accessing /proc and /sys in unsafe ways)."
Could enable that I guess, I could but first I need to get drunk.
I'm not trying to nitpick here, but:
Since the latest glibc (2.33) still requires kernel 3.2.0 at minimum, newer distros will very likely be able to run with just a simple recompilation on OpenVZ 7. I know OpenVZ 6 needs a patch to the glibc before compiling, and it's missing a few system calls, but Ubuntu 20.04 runs just fine. If my provider keeps renewing my VPS, I plan to update to Ubuntu 22.04 once it's released.
On the other hand, I think I've seen some OpenVZ 7 offerings with Ubuntu 20.04. Either they got it to work unmodified, or they had to recompile glibc.
As far as I know, the only thing that should be calling system calls directly is just glibc, so a kernel recompile should be enough.
There's already a modified glibc version available here: https://github.com/sdwru/glibc-debian-10/releases for Debian and https://github.com/sdwru/glibc-centos-8/releases for CentOS.
I really wouldn't recommend it though, as more and more software is going to depend on newer kernel features. 2.6 is very old and is missing a large number of features... Even RHEL only backported bug fixes to 2.6, not new features. It's like trying to prolong the life of Windows XP by copying bits and pieces from Windows 10... It's not sustainable.
There's a bunch of features missing from 2.6.x kernels... It might appear to run fine if you shim newer system calls in glibc, but other random stuff will likely break too, as nobody is writing code in 2021 expecting it to run on a kernel that's been EOL for over 5 years now. It's not just glibc that depends on kernel features.
Until you run a Go program, which directly invokes syscalls without going through glibc.
Although, Go still supports kernel 2.6 for now.
True.
The stallion coder doesn't deal with legacy stuff.
My code this year requires 5.4 kernel, so that I can use AF_XDP.
Pressure Stall Information is also useful for monitoring purposes, but it's only included in kernel 4.10 and above.
OV6 in 2021
Just move on. Utilize your time, money & efforts into something more useful.
This thread reminded me to check on my NAT VMs from @mikho / mrvm that where supposedly "being converted [...] to OpenVZ7 as soon as possible" back in Dec 2019.
They're still running OVZ6 as far as I can tell.
I think you're being too generous to KVM here. I would argue that KVM is closer to entry level, although on a low-end budget I suppose it's a bit more "premium".
Most of the popular VPS providers (DO, Vultr, etc.) only ship fully virtualized services (minus their kubernetes service I suppose), and I would consider DigitalOcean an "entry level" service for the most part.
LXC is a fine low-end option, it's so much better than OpenVZ (3.x kernels, disgusting). I would love to see more LXC low-end offerings, because unless I'm missing something huge it seems to have all the same properties as OpenVZ with regard to scalability and performance but is vastly superior in being usable for this day and age.
They run on normal KVM instances.
I remember an OpenVZ 6 node I look after with few "production VMs", was always pain to see it with obsolete softwares and that too with no straight forward method to upgrade to OVZ 7 that time. Then finally converted them to LXC and latest kernel, feels good now.
Wow, I wasn't aware of that. That kernel takes a different approach though -- it makes glibc compatible with kernel 2.6.32 again, instead of my approach (pretending to be kernel 3.2.0). That would be useful, someday I'll integrate some of those changes into my patchset.
Yeah, this is just for fun really. Actually looking at the OpenVZ kernel patches, some features (at least, syscalls) are also backported into that kernel:
recvmmsg
clock_adjtime
name_to_handle_at
open_by_handle_at
syncfs
sendmmsg
setns
process_vm_readv
process_vm_writev
These syscalls have not been backported though:
prlimit64
fanotify_init
fanotify_mark
Ah I see... I didn't consider that. And I certainly didn't consider statically-linked programs, which would have been compiled against the distro-standard glibc. Luckily not many utilities are statically linked, but yeah I see the problem now.
Okay... I just wanted to scratch an itch. I agree that it's not very useful
Why is that? I mean, what would you consider "premium"? A KVM instance can do almost everything that a bare metal instance can, right? Except for maybe nested virtualization if the provider doesn't enable it.
This is OT but I'm a bit curious, since performance benchmarks are lacking -- how does VMware compare to KVM?
What about OVH? They are cheaper than DO and Vultr, and also Linode...
@wpyoga Thanks for your open support request. Could you please share your script as I still have one openvz 6 storage VPS from time4vps where I have debian 9 and will try if I can upgrade to debian 10.
Security comes to my mind.
Or rather lack of. People always talk about performances and rarely talk about security.