Product team group | XCP-ng and XO forum

stormi

@JamesG Thanks. I'll let @teddyastie see. I think he would be more confortable with having the card in our lab, which should be imminent now, but I won't speak for him.

stormi

@pandusen said:

But I would in any case where PCI passthrough for edge cases like the GPU marked kind of is, is not a requirement, Always recommend XCP-ng over the others.

Thanks for that :).

There's no problem to state faithfully what works and what doesn't with a solution, and adapt the advice to the actual needs.

I just felt compelled to react because I didn't find it entirely right to state that GPU passthrough has low priority. It's supported in general, but there are devices that come with technical challenges not fully addressed yet in Xen or in XCP-ng, and we treat that as part of the general hardware support we aim for.

Same as we work on device drivers for devices mostly found in home labs, without dismissing them as low priority.

And it's a good point to state that the needs around GPUs are growing fast due to AI, indeed.

stormi

@pandusen said:

99 percent of the dev team is working security and basic hypervisor

The numbers don't match any reality though. Yes, maintenance is important, but we have a developer working on AMD iGPU passthrough fixes, and Teddy here is following the Intel Arc topic closely and obtained hardware (waiting for it to be available in the lab). We also work on AMD MxGPU for vGPU support on the supported devices. We also have work on virtio-gpu. Without producing something that can become an actual feature yet, as it's complex, but there's clearly investment on those fronts.

stormi

CCing @Team-XAPI-Network and @Team-Hypervisor-Kernel for them to have a look at this strong vs weak host model and the impact on HA.

stormi

@pandusen said:
its scary that GPU passthrough still has a low priority for XCP-ng, during the boom of AI and local LLM Inferencing.

As XCP-ng product owner, and someone who sees how much work developers put into such topics, may I ask you to elaborate on this "has low priority" statement?

stormi

@mthird said:

Spoke to soon. While the updates succeeded, one of the nodes is rebooting every few minutes due to an HA self-fence.

Could you open a dedicated thread and ping me there?

stormi

@rzr said:

As this is my first time installing these update candidates,

Actually we moved first batch of packages that landed in testing to candidates repo, to avoid mix up in the second batch that just landed in testing repo. Since nothing new appeared in candidate you should probably already had them before, home this is clarifying what is actually happening

Next yum update should just pull the latest stable versions?

Not if you already have installed then from testing (or candidate) repo, because versions are same, it's only the distribution channel that change, no impact for testers.

I'm not sure what you understood from @scarfantennae's question, but that we moved packages from xcp-ng-testing to xcp-ng-candidates doesn't seem on topic here.

The question is: "now that I've applied this update candidates from the testing repositories, am I definitively in testing mode?".

The answer is: no, because:

The --enable-repo switch only applies to the two commands you ran: clearing the cache and applying updates. The repositories remain disabled by default, so yes, next time you update you'll only get stable updates if there are any.
Either the exact packages that you installed will be pushed as official updates (in which case there will be nothing for you to do), or we'll push newer updates that will supersede them automatically next time you update.

Hope it's clear.

Product team

Posts

Member List