On Mon, Feb 26, 2018 at 01:20:49PM -0700, Jim Fehlig wrote:
On 02/15/2018 02:47 PM, Marek Marczykowski-Górecki wrote:
On Tue, Feb 13, 2018 at 09:02:35AM -0700, Jim Fehlig wrote:
It looks like we never answered my question from V3, i.e. should we change the default mode in the post-parse callback if NUMA or CPU features are defined within <cpu>?
Hmm, but this means changing the config behind user's back, no?
Well, sort of. But it is really just making the implicit explicit.
You have disabled nested HVM, upgrade, now you have enabled. Global switch is some consolation here, but is it enough?
I _think_ so. With a global default that disables nesting, are there any scenarios you envision where a previously disabled nesting becomes enabled after upgrade?
Probably also importing VM from older libvirt. Not sure about migration? Any other opinion about this? Daniel? Since introduction of global switch I'm fine with either.
BTW, I'm fine with this patch, just playing devil's advocate with handling such things post-parse vs domain start. It's not the only place where default xen config is not reflected in libvirt :-/.
Regards, Jim
It sure feels like such configuration tweaks and error checks should be handled in the parsing phase, similar to qemuDomainDefVcpusPostParse() and qemuDomainDefCPUPostParse() in the qemu driver. I think danpb is vaguely familiar with this series and can help answer that question. Daniel, do you have an opinion? Or a general comment about guidelines for checking/tweaking config in parse phase vs domain start phase?
-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?