@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.

@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.

@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?