[mg12]

A pool cannot yet tell whether GPU partitioning is in use on a host, being entered or left, or why a host does not take part. Nothing records it, so nothing can check it before enabling partitioning, and an administrator cannot see it.

Each host now reports its own state in two read-only fields, shown by xe host-param-list: a status and the reason for it. Later changes that add the pool-wide switch and the steps that enter and leave partitioning read and extend them.

Host.gpu_partitioning_status has all five values from this release on, as a host fails on a stored enum value it does not know; new causes go in Host.gpu_partitioning_reason, an open set of tokens. At xapi start, after the database sync and on its own thread, the host runs its checks under one lock, most specific first, and writes both fields together. NVIDIA cards are found by PCI vendor: pass-through unbinds the driver.

Nothing else changes: the internal Host.create takes both fields, with defaults; no VM, GPU or placement path reads them; and the GPU compatibility check keeps its vendor test. Until the pool can enable partitioning, a host shows inactive once its xapi has started on this version; an older host, or a joining one until its xapi restarts, shows not_reported. Schema bumped; tests cover the checks and the write.

After xapi starts, until the pool can enable partitioning, every host logs (debug) its state and xe shows it; on a host with an NVIDIA card:

    Xapi_host.sync_gpu_partitioning: inactive (pool_disabled)
    $ xe host-param-list uuid=<host> | grep gpu-partitioning
    gpu-partitioning-status ( RO): inactive
    gpu-partitioning-reason ( RO): pool_disabled

and on a host without one, the reason is no_partitionable_gpu.