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
