So the first thing will only give you streamline benchmarks, what almost nobody cares about.
The second can simulate realworld (VM/database...) workloads, where (controller) Caches and non magnetic storage (Flash, Optane, MRAM...) makes the real difference.
Also use big amount of data, since caches can impact small ones extremely. Don't get me wrong: We need them and they can make huge differences, but as long as your benchmarks fully fit into them, it gives your nonsense/fake results. Also (consumer) SSDs start throttling after some 10 to a very few 100 GB of data written. Their caches fill up and they 'overheat'.

You can spend days on benchmarks and how to do what.

@maxcuttins did you really measure 10 and 100 MB after I said 1 G is not enough for accurate results?

Usually you set blocksize to something usefull, like 1M and set count to e.g. 10000.
Of course you can change blocksize to test a bit, but that's usually between like 64k and maybe 4M.

Ah did you intend 10G? instead of 10M?

Usually you set blocksize to something usefull, like 1M and set count to e.g. 10000.
Of course you can change blocksize to test a bit, but that's usually between like 64k and maybe 4M.

@maxcuttins said in Citrix Hypervisor 8.0 landed:

I throw down one of my xcp-host to setup a not-nested-virtualized xen-8 in order to test RBD speed. Performance are about 4x slower than they should be but at least it run almost like a standard local disk.

dd if=/dev/zero of=./test.img bs=1G count=1 oflag=dsync
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB) copied, 1.86156 s, 577 MB/s

1G is usually a really bad test, as pretty small things can influence the result massively.
You should run tests with 10 or better 100 - if you can.
That also diminishes influence of any caches (on source and target!).

Not very good.
Here is 10M:

dd if=/dev/zero of=./test1.img bs=10M count=1 oflag=dsync
1+0 records in
1+0 records out
10485760 bytes (10 MB) copied, 0.0545468 s, 192 MB/s

and here 100M:

dd if=/dev/zero of=./test1.img bs=100M count=1 oflag=dsync
1+0 records in
1+0 records out
104857600 bytes (105 MB) copied, 0.266544 s, 393 MB/s

So, I agree with you but we need to be careful about the definition of "trusted".

And that's why no vendor can say they "support" it anymore, since no one can guarantee the security of anything running on them now.

i did notice it load cpu microcode rev 1f on boot, i also notices systemd is throwing a error on boot: systemd failed to load kernel modules, this has no impact and the host is running fine with no error other than that. i suspect the error might be related to upgrade fra 7.6, i will try to reinstall 8.0 as a fresh install and see if this clears the kernel modules stuff.

No errors during install, and boots up just fine for use.

going to revert back to xcp 7.6 today.

https://xcp-ng.org/forum/post/11832

Thanks!