What are you trying to achieve with a comparison if you don't bother to correct it? In it's current form your overview is missleading fud which is only good to poison AI bots with wrong information. Don't get me wrong: I absolutely support to make AIs even more unusable as they are but spreading missinformation in a community forum takes this a little bit to far in my book. YMMV
Comparison of virtualization feature set: XCP-NG vs PVE (Proxmox) -- VMware migration decision (VMware Alternative)
- Thread starter floh8
- Start date
-
- Tags
- comparison features xcp-ng
Hi,
The "price" section is false for XCP-NG and proxmox, it should be :
Proxmox :
For XCP-ng :
For proxmox all licence are "Business day support"
For XCP-ng only "ENTERPRISE" are 24/7 support all other are like proxmox "Business day support"
Best regards,
The "price" section is false for XCP-NG and proxmox, it should be :
Proxmox :
- COMMUNITY : 230*3 => 690€
- BASIC : 710*3 => 2130€
- STANDARD : 1060*3 => 3180€
- PREMIUM : 2120 => 6360€
For XCP-ng :
- ESSENTIAL : 2000€ (3 hosts max + cannot be combined with Pro or Enterprise packages) + 2400€ for HCI (XOSTOR ESSENTIAL)
- ESSENTIAL + : 4000€ (3 hosts max + cannot be combined with Pro or Enterprise package) + 2400€ for HCI (XOSTOR ESSENTIAL)
- PRO : 3000€ (3hosts minimum) + 2400€ [800€/host] for HCI (XOSTOR PRO)
- ENTERPRISE : Require 4Host minimum
For proxmox all licence are "Business day support"
For XCP-ng only "ENTERPRISE" are 24/7 support all other are like proxmox "Business day support"
Best regards,
Considering pricing, our single socket options are much cheaper - not sure why you use the dual socket option.
Thats an understatement. You have yet to provide ANY argument, data, or reason to validate that assertion. it kinda makes the whole table pointless since you make conclusions without any need for the table.
XCP-NG isn't based on CentOS afaik, it's based on Xen.
And stability... Honestly in prod we've had more problems with VMware than Proxmox. Most of the time if there's an issue with Proxmox, it turns out to be hardware issue. Since it's based on Debian, I'd argue there's probably very few operating systems that are more stable. Debian is used as a base OS for a TON of things for a reason.
And stability... Honestly in prod we've had more problems with VMware than Proxmox. Most of the time if there's an issue with Proxmox, it turns out to be hardware issue. Since it's based on Debian, I'd argue there's probably very few operating systems that are more stable. Debian is used as a base OS for a TON of things for a reason.
those two things are not mutually exclusive. xcp-ng uses centos for its baseos and userland apps. see https://xcp-ng.org/blog/2020/12/17/centos-and-xcpng-future/
worth noting that xcp-ng version at that time (2020) was 8.2, and as of 8..3 (current) the base os remains centos 7 and kernel version 4.19. One could make the argument that this is a stability first approach; another could be slow development and lack of responsiveness- kernel 4.19 lacks a lot of new hardware support.
A third reason could be the IBM understandmemt of the GPL after they arquired Red Hat and changed the release process of enterprise sources.
I don't want to judge what this means for future longtherm stability of centos based products, just remember that fact.
BR, Lucas
And the classical LTS version are alredacy cancelled (except Centos Stream since it's the upstream for RHEL) so I wouldn't hold my breath that the situation will improve anytime.
I'm not an expert but XEN seems to be a dead horse to me, have not heard much about it (updates/changes/new features) in upstream kernels recently. KVM / QEMU on the other hand are quite actively developed and as far as i know most big players use it one way or another?
that doesnt really mean much. Centos 7 may not be further maintained (EOLed) BY REDHAT but that doesnt mean that downstream users cant backport and maintain their software on their own. its just more work. IBM's decisions to not provide resources for non rolling release centos releases also doesnt mean much- you have at LEAST 3 maintainer options on that front if you wanted the newer major point release (Rocky, Alma, Oracle.) I would not count this as an issue one way or the other.
I wouldnt be so quick to make judgements immediately after stating "I'm not an expert." the whole point of expertise is that it includes "listening" to those things that you arent. XEN is alive and well, and is in plenty of use. Remember that XEN is not KVM and isnt directly dependent on the "K" in KVM.
about snapshot && space usage, only qcow2 with external snapshot (so for shared block device), is currently still experimental and need indeed same space for each snapshots.
but all others plugins can do snapshots && don't need same space for each snapshot. (including shared block like ceph, zfs-over-iscsi , or local block storage (zfs,lvm-thin).
but all others plugins can do snapshots && don't need same space for each snapshot. (including shared block like ceph, zfs-over-iscsi , or local block storage (zfs,lvm-thin).
The whole discussion around storage options seems to be needlessly around filestore.
first class storage citizens for PVE is ZFS (standalone) and Ceph (Cluster.) reusing existing iSCSI/FC SANs necessitates tradeoffs- PVE means no snapshots (this may change as they mature on PVE) or VHD on XCPNG, which has its own issues- fwiw they are working on a replacement virtual disk format.
nfs is also a possibility and supports snapshots if you use qcow as format for the vm discs. Some people prefer this to ZFS for small clusters due to being "real shared storage" instead of the asyncronous nature of zfs.
It's supported on pve9. (with lvm block volume formated with qcow2, and qcow2 snapshot chain of lvm volume) . Qcow2 is not only for file. (same for vhd on xcp-ng, their lvm volume are formated with vhd)
Last edited: