XCP-ng 8.0.0 Beta now available!
-
@peder Thanks! Could you make it fail once again and then produce a bug status report on both hosts with
xen-bugtool -yand send the the produced tarballs to the project contact address, or to upload it somewhere temporarily for us to download? -
I just made a try here, I can't reproduce with the same guest OS and memory settings.
Are you also doing Xen Storage motion?
-
@stormi I've placed the tarballs here https://student.oedu.se/~peder/xcp-ng/
I changed the static min to 512M, to match the Fedora case, but it still failed.Olivier, I'm not using Xen Storage motion but I am using two old Lenovo L430 Thinkpads as "servers" so that could be part of the problem.
I'll install a new C7 guest and see if the problem persists.
-
@olivierlambert The VM that fails migration seems to have been created in xcp-ng 7.6 using the "Other Media" template.
I made a new VM in xcp-ng 8 using the CentOS7 template and I can migrate that just fine with a larger static max. -
Can you provide the full VM record of the problematic one? with
vm param-list uuid=<YOUR FAILING VM UUID>Also the same with the one now working, so I can compare.
-
@olivierlambert Sure.
I've put the param-list logs as well as the VMs (sans the Disk) on https://student.oedu.se/~peder/xcp-ng/ -
So I imported your VM metadata in my lab pool, attached to a VM disk with Debian (so we don't really care about the OS) and it worked
I also attached a disk of a previously working CentOS 7 VM, same thing: migration worked
-
Weird.
Maybe it's due to the hardware I'm using. I only have 8 GB RAM in the servers but the migration fails even if I'm not running any other VM.
And since it works if static max=dynamic max it shouldn't be a RAM case either.Unless the migration for some reason tries to allocate 2-3 times the amount of RAM if static and dynamic max differ.
-
@MajorTom Sorry about that I've been (and still am AFK):
Corrected link: https://github.com/sammcj/benchmark_results/blob/master/xcpng/8/hyperthreading_impact/test_2_sysbench_prime.md
-
Folks... was at Citrix event today and the morning was a talk by LoginVSI looking at the impact of the latest security patches for Intel CPU's and the performance impact server on EUC work loads and server scalebility on the Hypervisors. According to the presenter all the Hypervisors (Hyper-V, VMware ESX and XenServer) that they were testing were seeing approx 20-25% decrease in performance when using Intel based systems. What I found interesting was VMware has developed a new scheduler, SCAv2 to help reduce the impact although no numbers where mentioned. There was no mention of anything of th sort for XenServer or HyperV.
https://blogs.vmware.com/performance/2019/05/new-scheduler-option-for-vsphere-6-7-u2.html
According to that blog post .. the impact using the SCAv2 was reduced to 11%.
-
This will come in Xen. In fact, work already started. It's called "core scheduling", and this is the preliminary work before sync scheduling, which is a perfect solution (better perfs AND better security) against Intel CPU flaws.
Source: https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg00370.html
-
Good to know that they're already working on it for Xen. Surprised that none of the Citrix bod's at the event mentioned it. Looks like the best way to do get around the massive performance hit without switching to AMD !
-
@AllooTikeeChaat I'm always stunned by the fact Citrix communication on Xen is equal to
/dev/null, despite all the great efforts made by the Xen devs (half of them are from Citrix!)So as I said, it's not there yet, but it's going into that direction pretty well, I would expect this stuff to be backported in the future I suppose, because it's really powerful!
-
When will the final version of XCP-ng 8.0.0. be available?
-
This will depend a bit on community feedback: more feedback means faster release
-
@olivierlambert I’m sorry I’m not more available to bring more testing to the table this week, I am AFK.
-
No worries mate! To give a more precise answer, we might target a RC for the end of the month, maybe sooner, IDK yet.
Then if there is no big issue spotted with the RC, release will come near after
-
Connecting an iSCSI SR in xsconsole fails if there's a discovery password.
It works if I disable the authentication.It works in XenOrchestra if I attach it as a new SR (With auth) AND have the same discovery username and password in the ACL of the iqn.
That still doesn't work in xsconsole.My iscsi server uses targetcli-fb/LIO.
-
Is it something broken before? Because I don't think we ever touched xsconsole outside colors
-
I’ve fairly certain I’ve had this problem since xenserver 6.x
