@kagbasi-ngc said in Red Hat Linux 10.1 ISO Won't Boot in UEFI Mode:

Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz

Ah indeed, I missed this Nice catch @bogikornel!

Hi,

Can you explain yourself (without the help of ChatGPT) exactly what you did in the first place to get into that situation? It's not clear to me

Someone from the @team-os-platform-release should take a look

Let me ping @team-xo-frontend

@thomas-dkmt we want to use this to improve our XCP-ng doc

Great detailed answer, TYVM Andy!

Yes, there's a possible weird combo between XOSTOR and HA in some situations. Let me add @ronan-a or @dthenot in the loop.

It's likely that XOA disconnection is just a visible symptom of something else. It's not ultra trivial to reproduce though.

Can you just disable HA and see if you still have the same disconnection problem?

Hi,

Out of curiosity, do you have HA enabled on that pool?

It cannot be done on runtime, because if it does, VMs will crash when losing some CPU features. A CPU mask is applied on domain creation.

Shutdown and then start all VMs (not just reboot).

Could be confirmed by @andyhhp ideally

Not until we can have our own piece of code doing it. Right now, it's a binary that's not Open Source made by Citrix, we cannot legally re-distribute it.

Use "warm migration" then. VM/advanced view/warm migration button.

Hi,

It's coming next month. You can even upvote as a priority: https://feedback.vates.tech/posts/1/vm-complete-lifecycle-management

Hi,

It's possible your XenServer 8.4 has slightly more recent packages so it won't work. You can use continuous replication or warm migration to achieve the goal of migrating to XCP-ng.

Hi,

It is indeed possible. See https://xcp-ng.org/forum/topic/8342/gpu-support-and-nvidia-grid-vgpu/33 for more info.

@stormi Yes, I'm also affected in here, due to an USB device that's disabled by default.

@tristis-oris

See https://feedback.vates.tech/?tags=xo-6 (updates are planned already)

For the rest, if it's a feedback that's not there and not a bug, feel free to add it

@nikade It's because it's often a misnomer. There reason is simple: Dom0 is indeed the place where you SSH, having an almost regular Linux system (at first sight), the toolstack, backup export etc. So it seems indeed to be "the host".

However, in "reality", the host is the entire resources of the machine, all CPUs and memory. It includes the Dom0, but not only (Dom0 doesn't have access to all CPU and memory, "only" all physical devices): all other VMs.

The difference is subtle enough, especially for people not coming from Xen, "Dom0" doesn't give any clue about what it is ("Control Domain" is a bit better, even if "Domain" is still less clear than "Virtual Machine"). That's because when you boot, you do NOT boot Linux but a micro-kernel, Xen, that does have access to all the host. That's also what makes Xen design more secure than others: only a small kernel (200k LoC) has access to everything, unlike in KVM for example, where it's the full kernel with at least 20M LoC. But you cannot access "Xen" with SSH or anything, outside sending commands from the Dom0. Hence the confusion.

That's why I'm even myself, on regular basis, uses "host" instead of Dom0 in the sake of simplicity/clarity.

Ping @team-xo-backend

That's also because XO Lite is replacing basically "nothing before", while XO 5 is 10y full of features that we can't all re-implement at once in XO 6