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.
Comments
Xen uses more resources, reserves RAM so you have to undersell and is harder to manage.
Also you can't over commit,
32GB Node OpenVZ you could sell e.g. 30 1GB VPS or 60 1GB VPS or even 90 or 120 1GB VPS
With Xen you can maybe sell 29 1GB VPS
Xen is a more (going to get jumped on for this) Honest service.
Nah, I'd say 28GB.
Well on a 32GB Node xen itself is going to use around 400 - 450MB Ram + 2GB reserved for Dom0, so yeah ... 29GB
But you've then got to leave some RAM for anything else that may run on the server, e.g. SolusVM services, backups, update etc.
Although I suppose you could swap them programs, but its going to be slow.
Well they all pretty much run under the Dom0 (2GB) and then there is an additional 500 - 550MB on top that XEN did not gobble up
+1. A Xen from even the shittiest provider is going to have decent "hardware" performance.
I think Xen on an Intel Atom is probably going to be worst then an OpenVZ on an Xeon even if oversold.
@Daniel it would be hard, there are almost no Atoms supporting hardware virtualization.
I thought Xen PV doesn't require virtualization extensions?
@Daniel not sure. I will try it these days, i think i have a spare atom somewhere.
This is an easy question to answer. The bottom line (in purely abstract terms) is that Xen is a "premium" virtualisation technology that providers better performance than OpenVZ. To obtain this premium level of performance, a high standard of/investment in hardware is required along with a certain skill set from the provider.
Correct. It doesn't. Only HVM does.
OpenVZ has better performance then Xen, since there is zero overhead on OpenVZ, however this only applies in an environment where the node has not been overcommitted.
Given that each node is nearly empty, then yes, you are correct. However my post was in purely abstract terms. We you start to load a node, you start to see the true benefits of Xen in action, as Xen provides for really good isolation between customers, leading to a better performance. The term "overcommitted" is subjective and relative. If a Xen node and an OpenVZ node each had X number of VPSes (of the same spec), you would probably find that the Xen node coped better.
I assumed the physical nodes will/would have similar specs.
This is a non-sequitur, Daniel. Anyone who just wants to run a basic stock LAMP setup, if they have half a grey cell, will go with OpenVZ instead of Xen.
You want to grind a non-committed OpenVZ to its knees? Try doing something on each container that requires lots and lots of inodes. In that case, even a Xen PV on Atom will beat the OpenVZ on E3-1270
Well, ploop will fix the OpenVZ inode issue
Yes it doesn't. I tried that a few months ago
It doesn't need VT but it needs custom kernel drivers to boot :P
Francisco
Not any more. These extensions are now in the mainline Linux kernel. So in theory, any Linux distro using a fairly recent kernel will be bootable on Xen PV :P
Is it really impossible to oversell Xen? I've read on other forums (ex. WHT) that it is possible.
You can balloon,
I don't think you can oversell Xen full stop when using SolusVM. Just my thought though, im not an expert with Xen.
I think SolusVM prevents you from creating more Xen VPS then available RAM, but you can still enable ballooning, but sort of useless.
Is the same with KVM?
With KVM you can over commit on RAM however I personally wouldn't advise it, I can be done but out of personal preference I wouldn't.
Here is a snippet from OnApps guide which explains overheads in a pretty simple way if you are wondering (best I could find at short notice):
Example calculation:
>
Dom0 memory (400 Mb).. This is a standard value.
64 Mb for Xen itself.
1 Mb for each virtual CPU
8 Kb for each 1 Mb of virtual machine RAM
>
Dom0 memory = 400Mb +64Mb (this is a standard minimum value, though you can allocate more)
1Mb x 4 vCPUs = 4
2048 x 8/1024 = 16
XEN memory overhead = 464 + 4 + 16 = 484 Mb
>
SOURCE: https://help.onapp.com/manual.php?s=faa2d7eb91db288fbf4175fc36e7ce41&print=1635
Yes, but Xen ballooning requires the cooperation of a driver (kernel module) in the guest, and if you fear this just compile a custom kernel (or not load)
xen_balloon.