XCP-NG 9, Dom0 considerations
-
@mnv For local SR, just use Local ext SR type and you will be thin already.
-
Don't be too excited: the new platform itself won't trigger that many visible changes. We can already have it running with the same Xen and Dom0 kernel than 8.3, it doesn't change many things. It's just far more comfortable to build new stuff on top of it, but the new platform "itself" isn't really providing "features". There's a lot of work on the rest: running a very recent kernel more easily, having more control on the packages, etc. But most of the work for increasing performances (for example) will have to happen in Xen or the PV drivers, or the storage blocks. Another example: a recent kernel can unlock io-uring, but we still need to modify tapdisk to use it. So it's building all the bricks one by one to make something useful.
-
@olivierlambert thats totally understandable as Xen is the core of the appliance!
Only reason i mention NFS as an example is, as you probably remember, i had a lot of issues with NFSv4 under load with drop outs that switching to NFSv3 totally resolved, when i look at a 8.3 host i see:
[15:03 xcp-ng-01 ~]# rpm -q nfs-utils nfs-utils-1.3.0-0.54.el7.x86_64compared to the verison in Almalinux 10:
[root@localhost ~]$ rpm -q nfs-utils nfs-utils-2.7.1-1.el10.x86_64Im hopeful that some of the improvements and fixes from jumping up to a much newer version like will help with this sort of thing, and likely other examples of this exist as well.
-
Yes, it will surely have an impact on some things like this, note the impact could be both ways
(but hopefully better in the end) -
@mnv said in XCP-NG 9, Dom0 considerations:
Thanks for your heads up, Olivier, and I hope your internal tests and developements go in the best direction! I can't wait for the next big thing! Only thing I could hope for that is missing (AFAIK) in XCP-NG 8.x is support for LVM Thin storage, that's so good when you have crappy consumer SSDs...
I've actually been puttering with LVM thin patches for awhile as it's always bothered me that we didn't have. I think I finally have my head around the code. , but I'm sure I'm missing something obvious that will be pointed out when I submit.
It's been a very-very-very-side project. -
My wishlist for a new XCP-ng:
- Recent kernel for dom0.
- Guest trim support -> i.e. guest trim translates to shrunk VDI file.
- Better VM console support: Spice and/or RDP support with client USB access, shared clipboard and file transfers. Note, I do not mean remoting into the guest itself, but providing console access via XCP-ng like the current console VM access is with XO and XCP-ng Center.
- Implement VirtIO support: virtio-net, virtio-gpu, virtio-blk/scsi. (There are also serial and socket virtio devices, but i do not personally use these much, but could be important for management of some types if VMs).
- Support multiqueue i guests for net and blk.(would be possible with virtio)
- VirGL support. This is important as an alternative to GPU pass through or SR-IOV. It would in theory support migration too.
-
All of this is in our product "backlog" (more or less depending on feasibility) also it's a bit out of scope for this thread.
-
@olivierlambert said in XCP-NG 9, Dom0 considerations:
@mnv For local SR, just use Local ext SR type and you will be thin already.
Hi Olivier,
Sorry for my late reply.
Yes, I am aware of that, however using LVM (like using ZVOL) would offer the disk as a block device directly, thin ext4 ought to be ext4 + the virtual disk + the VM filesystem, ZVOL/LVM should be block device + VM filesystem. There seems to be way less overhead.
ZVOL doesn't play nice with all SSDs, not mines for sure, LVM Thin seems to play much better, write less and take longer to have the same wear as ext4-thin or ZVOL.
I understand this isn't a problem in an Enterprise environment, though...
-
@mnv said in XCP-NG 9, Dom0 considerations:
@olivierlambert said in XCP-NG 9, Dom0 considerations:
@mnv For local SR, just use Local ext SR type and you will be thin already.
Hi Olivier,
Sorry for my late reply.
Yes, I am aware of that, however using LVM (like using ZVOL) would offer the disk as a block device directly, thin ext4 ought to be ext4 + the virtual disk + the VM filesystem, ZVOL/LVM should be block device + VM filesystem. There seems to be way less overhead.
ZVOL doesn't play nice with all SSDs, not mines for sure, LVM Thin seems to play much better, write less and take longer to have the same wear as ext4-thin or ZVOL.
I understand this isn't a problem in an Enterprise environment, though...
Larger issue is the existing block storage code is thick only, so rolls across to local lvm, HBA and iscsi. And fiber channel/SAS multipath HBA and iscsi are what are more commonly used in many enterprises, blocking many from migrating from competing products.
LVM has supported thin provisioning since release 2.02.89 back in 2012, with redhat 6.4 I believe.
This should also solve the initial vhd sparse file growth write performance penalty -
LVM thin works it's not the problem. The problem is corruption because it's used by multiple hosts at the same time. BTW, this topic shouldn't be "the offtopic general stuff I need".
-
@olivierlambert said in XCP-NG 9, Dom0 considerations:
BTW, this topic shouldn't be "the offtopic general stuff I need".
Sorry for deviating, just wanted to mention one desiderata besides dom0.
Thanks for the replies
-
Everything told here is already in our (huge) backlog
