@adriangabura said in XCP-ng 8.1.0 beta now available!:

Thanks for the update! I've installed the update on one of my servers, it works. If it will work fine I'll try on another server.

Are there some technical issues that would explain why Dynamic Memory Control was deprecated by Citrix?

There was some talk about in https://xcp-ng.org/forum/topic/2254/citrix-hypervisor-8-1-released/23 .
Personally I am happy to see DMC go. I've not used it for years now after VMs sometimes crashed due to running out of memory. At that time the ballooning would happen during every live migration if I remember correctly, even though there was plenty of RAM available.

@cg Yes, I can read, thanks. It says "heavily consider".
I honestly don't care if you run ZFS with dedup, and if it keeps on working for you that's great, but it did sound like a recommendation for running dedup without adding a big fat warning. I felt it was necessary to add that warning.

Some more info about the rule of thumb:
https://github.com/zfsonlinux/zfs/issues/2829
https://news.ycombinator.com/item?id=8437921

ryao created this issue in zfsonlinux/zfs

open Warning about deduplication is not accurate #2829

@cg Sure, see man zfs :

Unless necessary, deduplication should NOT be enabled on a system. See Deduplication

And continue from there. For instance:

Deduplicating data is a very resource-intensive operation. It is generally
recommended that you have at least 1.25 GiB of RAM per 1 TiB of storage when
you enable deduplication. Calculating the exact requirement depends heavily
on the type of data stored in the pool.

@cg You should be careful when recommending dedup on ZFS. I think (but my knowledge might be outdated) there are still at least some caveats people should be aware of.
A quick search reveals you typically need 1-5 GB of RAM per TB of storage.

Installing now, seems to run fine.

@stormi I'll try it on a master, no worries. But not on a Friday.

@stormi Sure, but I'd rather test on a pool member first if trying as an early adopter .

@stormi said in Updates announcements and testing:

yum update --enablerepo='xcp-ng-updates_testing' microcode_ctl-2.1-26.xs5.x86_64 xen-dom0-libs-4.7.6-6.5.1.xcpng.x86_64 xen-dom0-tools-4.7.6-6.5.1.xcpng.x86_64 xen-hypervisor-4.7.6-6.5.1.xcpng.x86_64 xen-libs-4.7.6-6.5.1.xcpng.x86_64 xen-tools-4.7.6-6.5.1.xcpng.x86_64

Should the pool master be updated first? Or it doesn't matter for there updates?

@stormi I only tested with one VM. It crashed a couple of times when the pool master had updates from xcp-ng-updates_testing and the slaves had the updates that were released yesterday. After updating the last remaining slave to updates from xcp-ng-updates_testing, moving the VM resulted in a stuck VM. So I don't think you can draw any conclusions from this, except maybe that you should install the same version on master and slaves.

@stormi Thanks. Installing the update candidate on all hosts and restarting the toolstack works, but only after power cycling the VM once.
xcp-emu-manager is version 0.0.9-1

Is it advisable to stay on the testing repo until the next version? There are some more non-Windows HVM VM's.

I've installed the updates on a pool. Now every time I migrate a pfSense HVM VM within the pool the console is gone and memory usage is at 100%. I did do the following on the pool master: yum update xenopsd xenopsd-xc xenopsd-xenlight --enablerepo='xcp-ng-updates_testing'. The package version also differs from other hosts (0.66.0-1.1.xcpng versus 0.66.0-1.el7.centos). Would that be the cause?