On Mon, 1 Jun 2020 17:14:20 -0300 Daniel Henrique Barboza <danielhb413@xxxxxxxxx> wrote: > On 6/1/20 4:40 PM, Peter Krempa wrote: > > On Mon, Jun 01, 2020 at 14:50:41 -0300, Daniel Henrique Barboza wrote: > >> Now that we have the auto-fill code in place, and with proper documentation > >> to let the user know that (1) we will auto-fill the NUMA cpus up to the > >> number to maximum VCPUs number if QEMU supports it and (2) the user > >> is advised to always supply a complete NUMA topology, this warning > >> is unneeded. > >> > >> This reverts commit 38d2e033686b5cc274f8f55075ce1985b71e329a. > > > > Since we already have the validation in place for some time now I think > > we should just keep it. The auto-filling would be a useful hack to work > > around if config breaks, but judged by itself it's of questionable > > benefit. > > That's a good point. I agree that removing the message after being in place > for this long is more trouble than it's worth. > > > > > Specifically users might end up with a topology which they didn't > > expect. Reasoning is basically the same as with qemu. Any default > > behaviour here is a policy decision and it might not suit all uses. > > > > > An ideal situation would be QEMU to never accept incomplete NUMA topologies > in the first place. At least with your series I can safely drop deprecated incomplete NUMA topologies on QEMU side (which were producing warnings for a while) > > Given that this wasn't the case and now there might be a plethora of guests > running with goofy topologies all around, the already existing warning > message + this auto-fill hack + documentation mentioning that users should > avoid these topologies is a fine solution from Libvirt side, in my > estimation. > > > Thanks, > > > DHB >
