Re: [RFC PATCH auto partition NUMA guest domains v1 0/2] auto partition guests providing the host NUMA topology

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 25 Sep 2018 14:37:15 +0200
Jiri Denemark <jdenemar@xxxxxxxxxx> wrote:

> On Tue, Sep 25, 2018 at 12:02:40 +0200, Wim Ten Have wrote:
> > From: Wim ten Have <wim.ten.have@xxxxxxxxxx>
> > 
> > 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@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/libvir-list

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux