[libvirt] [RFC PATCH auto partition NUMA guest domains v1 0/2] auto partition guests providing the host NUMA topology
Wim ten Have
wim.ten.have at oracle.com
Mon Oct 15 18:26:21 UTC 2018
On Tue, 25 Sep 2018 14:37:15 +0200
Jiri Denemark <jdenemar at redhat.com> wrote:
> On Tue, Sep 25, 2018 at 12:02:40 +0200, Wim Ten Have wrote:
> > From: Wim ten Have <wim.ten.have at oracle.com>
> >
> > This patch extends the guest domain administration adding support
> > to automatically advertise the host NUMA node capabilities obtained
> > architecture under a guest by creating a vNUMA copy.
>
> I'm pretty sure someone would find this useful and such configuration is
> perfectly valid in libvirt. But I don't think there is a compelling
> reason to add some magic into the domain XML which would automatically
> expand to such configuration. It's basically a NUMA placement policy and
> libvirt generally tries to avoid including any kind of policies and
> rather just provide all the mechanisms and knobs which can be used by
> applications to implement any policy they like.
>
> > The mechanism is enabled by setting the check='numa' attribute under
> > the CPU 'host-passthrough' topology:
> > <cpu mode='host-passthrough' check='numa' .../>
>
> Anyway, this is definitely not the right place for such option. The
> 'check' attribute is described as
>
> "Since 3.2.0, an optional check attribute can be used to request a
> specific way of checking whether the virtual CPU matches the
> specification."
>
> and the new 'numa' value does not fit in there in any way.
>
> Moreover the code does the automatic NUMA placement at the moment
> libvirt parses the domain XML, which is not the right place since it
> would break migration, snapshots, and save/restore features.
Howdy, thanks for your fast response. I was Out Of Office for a
while unable to reply earlier. The beef of this code does indeed
not belong under the domain code and should rather move into the NUMA
specific code where check='numa' is simply badly chosen.
Also whilst OOO it occurred to me that besides auto partitioning the
host into a vNUMA replica there's probably even other configuration
target we may introduce reserving a single NUMA-node out of the nodes
reserved for a guest to configure.
So my plan is to come back asap with reworked code.
> We have existing placement attributes for vcpu and numatune/memory
> elements which would have been much better place for implementing such
> feature. And event cpu/numa element could have been enhanced to support
> similar configuration.
Going over libvirt documentation I am more appealed with vcpu area. As
said let me rework and return with better approach/RFC asap.
Rgds,
- Wim10H.
> Jirka
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
More information about the libvir-list
mailing list