Citrix Hypervisor 8.0 landed

Arraylist

According to the XS HCL Citrix Hypervisor 8.0 is supporting Dell R420 servers but not Dell R430 (same model, but newer, you can still buy the R430). The newer R440 is also supported. This seems very odd to me. Has anyone any idea why this is the case?

stormi

While you're waiting for XCP-ng 8.0 beta, what about testing the latest security update to help us release it fast?

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

Thanks!

nuts23

Been running CH 8.0 for a week to test it out. There's an issue with the guest tools. performance is slow because the guests I/O isn't "optimized"

going to revert back to xcp 7.6 today.

olivierlambert

@nuts23 testing what? CH 8.0?

nuts23

@olivierlambert yes, sorry, the Citrix Hypervisor 8.0

olivierlambert

Guest tools on Windows (I suppose) aren't working well?

nuts23

@olivierlambert yep

olivierlambert

Have you used Citrix tools directly from CH ISO or something else?

nuts23

yes, I used the ones in the ISO and through the system. I also tried some older ones.. In the end the system never recognized that I had the proper ones installed. Tried with 2 different windows VMs. Server 2016 and Win10

Prilly

Can anybody that has the means try to run Citrix Hypervisor 8.0 on those legacy 56xx series CPUs?

borzel

@nuts23 did you use fresh installed windows or "used" ones?

crash

@Prilly I installed Citrix Hypervisor 8.0 on my Dell C6100 which is running L5630 CPU and it booted just fine.

olivierlambert

@crash you can even try with XCP-ng 8.0 now (still beta but will be useful to try)

crash

@olivierlambert @prilly Just loaded the XCP-ng 8.0 successfully on a Dell C6100 with 2 x L5630.

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

Prilly

Thanks you guys for testing the l5630 cpu, this gave me confidence to upgrade my dell r610 with 2x x5675 cpus with hypervisor 8.0, upgrade was done with iso and cd and the upgrade process went very smooth, server boot up and everything seems almost nice.

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.

stormi

From what I see in https://www.intel.com/content/dam/www/public/us/en/documents/corporate-information/SA00233-microcode-update-guidance_05132019.pdf X5675 CPUs are not supported by Intel itself anymore, so no mitigation for you for the MDS attacks

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.

Prilly

@stormi as long as you dont have any untrusted vms running on this cpus there is no problem with security issues.

stormi

@Prilly You're fine if you're running trusted workload. This includes VMs themselves and everything that gets executed in it. Including maybe javascript or webassembly stuff on some not-so-trusted websites. This also means that a compromised VM due to a security flaw in the VM or something badly configured or access obtained through social engineering can leverage the hardware security flaws to get access to sensitive data not only from within the VM but also from other VMs.

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

maxcuttins

@cg said in Citrix Hypervisor 8.0 landed:

@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

cg

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