@hitechhillbilly no it doesn't, it just ensures the N-th vCPU of Dom0 only runs on N-th pCPU of the machine. Not sure about the practical impact of it, in the past it has been used for getting meaningful CPU temperatures from coretemp (with physical core matching virtual one), but that doesn't work anymore since Xen filters MSR accesses (including Dom0).

@hitechhillbilly I'd say this is normal if you are low on RAM and you are doing a live VDI migration. XCP-ng requires some amount of free RAM on the host to be able to live migrate the VDI. The larger the VDI, the more RAM is needed but exact sizing is unknown to me. I've encountered this error numerous times so I consider it common. The way around this is to shutdown the VM and then migrate the VDI. RAM requirements in that case are much much lower.

Yes, and then Xen will reduce the RAM if there's not enough available to boot a new VM (reducing down to dynamic min). Static means it can't be changed live, while dynamic can.

@hitechhillbilly Hi, For now the import tool does not use the proxy. Not that the full import tool also work from source if you need additional XOA , but we won't be able to connect to them for support

@olivierlambert I 100% agree its vague. I even told the person that. Like I was saying I was more looking for anyone who has ran a cluster in those other scheduler settings to get some feedback on it. I guess being a little more specific, would socket or Core be better for VMs that are NUMA sensitive? Such as database servers or the like?

@gduperrey Thank you for the reply. The use case is to centralize all of our reporting and monitoring for all of our devices. We have a number of XCP host, various servers, etc, that we are responsible for, and all of them besides our XCP nodes are being monitored for real-time analytics by Netdata. We are also using Zabbix for trending and long term usage but would like to be able to move the XCP nodes into our Netdata cloud versus being just on XOA/XCP. I also understand this would be overidden by updates and that you guys cant support it. I mainly wanted to see if it would "break" anything you already have in place. As a feature request, maybe have a way that you can report to a Netdata cloud instance. That would be nice.

Yeah I remember it wasn't that easy

Hi, XOSTOR on XCP-ng 8.2.1 has been supported since it was released approx 9 months ago. XOSTOR on XCP-ng 8.3 is still in the beta phase, so not officially supported. Regards, Dan

@hitechhillbilly Hello, can you please try the buffered-task-events branch and let me know if that solves the issue?

@Andrew, Thank you for the reply.

Thanks everyone for the report!

No problem, and it's not your fault, it's far from being intuitive. It will be a lot easier in XO 6. Also, enjoy discovering the cool little things hidden in this view (like trying XO in Chinese )

@hitechhillbilly What XCP-ng version are you runing? With XOA Premium up-to-date and the Enterprise support plan, I think it is best to open a ticket and let the support team have a look (especially for a productive environment).

So I think I figured out my issue. The VMs I was importing were reading off the local storage of the ESX server which is a single SSD. Once I started one that was reading off the the storage device, it went much, much faster. I still have an issue with something else on imports, but I will open a ticket since I have support. Thank you for the help.

@hitechhillbilly no problem.

This won't work. We are working to get an installer for the version 9 as we speak, probably having a beta package in the next weeks. Until then, either use the version 8 with XCP-ng drivers or use Citrix ones.

@olivierlambert Hey thanks a lot for that tip.

@Gheppy thank you for the response. I will do that.

Right, if your used is 123.4/128, there seems RAM crunch to migrate anything around 4GB. Can you try migration after freeing up some RAM? Also what version of XCP-NG is being used? There is a known issue related to migration - you can find it on forum.