Hm, @WSS ... Care to define what characterizes a pig kernel?
Maybe pig = messy kernel? I usually use the advanced debian installer option, since I have some options to build more targeted boot image and such ... I guess I should use the same with KVM VPS installs...
Anotger thing I forgot to mention that I really dislike about OpenVZ is its handling of CPU cores. On a VPS, when you ask how many CPUs the system has using the glibc sysconf(_SC_NPROCESSORS_ONLN) function, it returns the right number of virtual CPUs, but when you ask it which CPU the current thread is executing on using sched_getcpu, it returns the actual real CPU ID. So on a VPS that doesn't use CPU affinity, you code can be running on "CPU #3" (for example) on a VPS with just one virtual CPU. Great, thanks OpenVZ. There's leaky abstractions like that all over the place, where they only override some syscalls but not all of them.
This is not a problem on KVM, of course, as the kernel isn't virtualized.
@WSS said: OpenVZ 6 with the 2.3.32-stab13x(something) backported some ctls used by systemd so Ubuntu 18 would work. As well, if you use KernelCare/kpatch, you will often get security, and firmware updates.
Sure, but it's just security updates and a few necessary updates, right? That still means you're missing out on most of the new features. For example, PSI was only added in 4.20.
@flips said:
Hm, @WSS ... Care to define what characterizes a pig kernel?
It's fat, and wasteful.
@Daniel said:
Sure, but it's just security updates and a few necessary updates, right? That still means you're missing out on most of the new features. For example, PSI was only added in 4.20.
"Just enough to make it work", essentially. Rarely more. They're not going to add what the userland doesn't require. OpenVZ is a reactionary hypervisor- when stuff breaks they'll look into implementing what's required, rather than, you know, ensuring the system works. As you've witnessed yourself, OpenVZ does some really bizarre things, and I can't say I'm a fan.
@WSS said: "Just enough to make it work", essentially. Rarely more. They're not going to add what the userland doesn't require. OpenVZ is a reactionary hypervisor- when stuff breaks they'll look into implementing what's required, rather than, you know, ensuring the system works.
And I think the only reason they can even have that low level of support is thanks to paid Virtuozzo users. If Virtuozzo disappeared, OpenVZ would die along with it. I doubt any other company would pick up OpenVZ dev given there's so many other choices these days.
@Daniel said:
I doubt any other company would pick up OpenVZ dev given there's so many other choices these days.
As do I. The way that it works by repatching the kernel for every major revision, and the fact it is now two major builds behind doesn't really ingratiate itself with those of us who would/will/do have to support these products. Although emulating the complete hardware stack is a bit excessive in many cases, having to rely on out-of-band kernel patches which are then patched by yet another third party, well.. don't even get me started about having to maintain in-house drivers on top of these two stacks.
Hm, VSwap, I see I have 0 KB in my SolusVM panel ...
This is something that's defined in the host/hypervisor?
Or just what I do swapon inside my container/VM?
(Or does it have to be defined outside my VM, since it's a shared kernel?)
@flips said:
Hm, VSwap, I see I have 0 KB in my SolusVM panel ...
This is something that's defined in the host/hypervisor?
Or just what I do swapon inside my container/VM?
(Or does it have to be defined outside my VM, since it's a shared kernel?)
If its one of the NAT services that is because they dont come with any swap.
To follow up my own question/comments in The Cest Pit, it seems that, even though iptables-legacy and nft both use the netfilter layer in the kernel, nft won't work properly on OpenVZ 7 (tested with Debian 10).
When trying to add rules, getting: Error: Could not process rule: Operation not supported
I'm guessing the issue would be the nft_ct and nft_counter kernel modules (and maybe others).
So for now running iptables-legacy and Ferm for firewall on OVZ.
Comments
Hm, @WSS ... Care to define what characterizes a pig kernel?
I usually use the advanced debian installer option, since I have some options to build more targeted boot image and such ... 
I guess I should use the same with KVM VPS installs...
Maybe pig = messy kernel?
Anotger thing I forgot to mention that I really dislike about OpenVZ is its handling of CPU cores. On a VPS, when you ask how many CPUs the system has using the glibc
sysconf(_SC_NPROCESSORS_ONLN)function, it returns the right number of virtual CPUs, but when you ask it which CPU the current thread is executing on usingsched_getcpu, it returns the actual real CPU ID. So on a VPS that doesn't use CPU affinity, you code can be running on "CPU #3" (for example) on a VPS with just one virtual CPU. Great, thanks OpenVZ. There's leaky abstractions like that all over the place, where they only override some syscalls but not all of them.This is not a problem on KVM, of course, as the kernel isn't virtualized.
Sure, but it's just security updates and a few necessary updates, right? That still means you're missing out on most of the new features. For example, PSI was only added in 4.20.
Daniel15 | https://d.sb/. List of all my VPSes: https://d.sb/servers
dnstools.ws - DNS lookups, pings, and traceroutes from 30 locations worldwide.
It's fat, and wasteful.
"Just enough to make it work", essentially. Rarely more. They're not going to add what the userland doesn't require. OpenVZ is a reactionary hypervisor- when stuff breaks they'll look into implementing what's required, rather than, you know, ensuring the system works. As you've witnessed yourself, OpenVZ does some really bizarre things, and I can't say I'm a fan.
My pronouns are like/subscribe.
So, you won't be joining my OpenVZ Fan Boys Discord?!?
... (Ok, I'll go to bed now.) 
And I think the only reason they can even have that low level of support is thanks to paid Virtuozzo users. If Virtuozzo disappeared, OpenVZ would die along with it. I doubt any other company would pick up OpenVZ dev given there's so many other choices these days.
Daniel15 | https://d.sb/. List of all my VPSes: https://d.sb/servers
dnstools.ws - DNS lookups, pings, and traceroutes from 30 locations worldwide.
As do I. The way that it works by repatching the kernel for every major revision, and the fact it is now two major builds behind doesn't really ingratiate itself with those of us who would/will/do have to support these products. Although emulating the complete hardware stack is a bit excessive in many cases, having to rely on out-of-band kernel patches which are then patched by yet another third party, well.. don't even get me started about having to maintain in-house drivers on top of these two stacks.
I really wish it would just fucking die.
My pronouns are like/subscribe.
Hm, VSwap, I see I have 0 KB in my SolusVM panel ...
This is something that's defined in the host/hypervisor?
Or just what I do
swaponinside my container/VM?(Or does it have to be defined outside my VM, since it's a shared kernel?)
If its one of the NAT services that is because they dont come with any swap.
https://inceptionhosting.com
Please do not use the PM system here for Inception Hosting support issues.
I figured that might be the case. I'm just curious.
So with OVZ, I can't just set
swaponinside the container?Nope, it is managed from the host node.
https://inceptionhosting.com
Please do not use the PM system here for Inception Hosting support issues.
To follow up my own question/comments in The Cest Pit, it seems that, even though
iptables-legacyandnftboth use the netfilter layer in the kernel,nftwon't work properly on OpenVZ 7 (tested with Debian 10).When trying to add rules, getting:
Error: Could not process rule: Operation not supportedI'm guessing the issue would be the
nft_ctandnft_counterkernel modules (and maybe others).So for now running iptables-legacy and Ferm for firewall on OVZ.