On Thu, Jun 29, 2017 at 04:18:49PM -0300, Eduardo Habkost wrote:
> On Thu, Jun 29, 2017 at 11:00:13AM +0800, Peter Xu wrote:
> > On Thu, Jun 29, 2017 at 12:42:56AM +0200, Juan Quintela wrote:
> > > Eduardo Habkost wrote:
> > >
> > > >
> > > > So, this is a case where a user-provided config option
On Thu, Jun 29, 2017 at 11:00:13AM +0800, Peter Xu wrote:
> On Thu, Jun 29, 2017 at 12:42:56AM +0200, Juan Quintela wrote:
> > Eduardo Habkost wrote:
> >
> > >
> > > So, this is a case where a user-provided config option (-machine
> > > enforce-config-section) should trigger a different default i
On Thu, Jun 29, 2017 at 12:42:56AM +0200, Juan Quintela wrote:
> Eduardo Habkost wrote:
>
> >
> > So, this is a case where a user-provided config option (-machine
> > enforce-config-section) should trigger a different default in another
> > class (migration.send-configuration).
> >
> > Also, the
Eduardo Habkost wrote:
>
> So, this is a case where a user-provided config option (-machine
> enforce-config-section) should trigger a different default in another
> class (migration.send-configuration).
>
> Also, the new default triggered by -machine has a very specific
> priority:
>
> * AccelCl
On Tue, Jun 27, 2017 at 12:10:18PM +0800, Peter Xu wrote:
> These two parameters:
>
> - MachineState::enforce_config_section
> - MigrationState::send_configuration
>
> are playing similar role here. This patch merges the first one into
> second, then we'll have a single place to reference whether
These two parameters:
- MachineState::enforce_config_section
- MigrationState::send_configuration
are playing similar role here. This patch merges the first one into
second, then we'll have a single place to reference whether we need to
send the configuration section.
I didn't remove the Machine
