[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4 3/9] cli: add -preconfig option
From: |
Peter Krempa |
Subject: |
Re: [Qemu-devel] [PATCH v4 3/9] cli: add -preconfig option |
Date: |
Tue, 3 Apr 2018 12:41:39 +0200 |
User-agent: |
Mutt/1.9.3 (2018-01-21) |
On Thu, Mar 29, 2018 at 13:57:54 -0300, Eduardo Habkost wrote:
> On Thu, Mar 29, 2018 at 03:01:12PM +0200, Igor Mammedov wrote:
> > On Wed, 28 Mar 2018 16:17:32 -0300
> > Eduardo Habkost <address@hidden> wrote:
> > > On Tue, Mar 27, 2018 at 05:05:41PM +0200, Igor Mammedov wrote:
> > > > On Fri, 23 Mar 2018 18:25:08 -0300
> > > > Eduardo Habkost <address@hidden> wrote:
> > > > > On Mon, Mar 12, 2018 at 02:11:09PM +0100, Igor Mammedov wrote:
[...]
> > > > > Why exactly it's not possible to use -incoming with -preconfig?
> > > > there are 2 reasons why I made options mutually exclusive
> > > > 1. (excuse ) '-incoming' is an option with non explicit side effects
> > > > on other parts of code. It's hard to predict behavior
> > > > of preconfig commands in combination with inmigrate.
> > > > I wouldn't try to touch/change anything related to it
> > > > in this series.
> > > > If we need to change how option is handled, it should
> > > > be separate series that focuses on it.
> > > > 2. (main reason) is to expose as minimal interface
> > > > as possible. It's easier to extend/modify it future if
> > > > necessary than cut it down after it was introduced.
> > > >
> > > > Not counting [1], I don't see a reason to permit
> > > > 'preconfig' while migration is in progress.
> > > > Configuration commands that where used during 'preconfig'
> > > > stage on source side, should use corresponding CLI options
> > > > on target side. (it's the same behavior as with hotplugged
> > > > devices, keeping migration work-flow the same)
> > > >
> > > > In short I'd prefer to keep restriction until there will be
> > > > a real usecase for combo to work together.
> > >
> > > I understand the reasons, but I think we already have an
> > > important use case: live-migrating a VM with non-trivial NUMA
> > > config (that needs -preconfig). Don't we?
> > Not really,
> > whatever we have configured on source side using -preconfig
> > (discovering valid topology in process), we should be able
> > to replicate using only CLI options on target since we
> > already have all necessary values for it from source (it's
> > certainly the case with this series set-numa-node command).
> >
> > As for the future, I agree it would be much more flexible
> > to allow both -preconfig and -incoming at the same time,
> > so we could start target with empty CLI, and then feed it
> > options from source. It would require audit/refactoring of
> > INMIGRATE state and making 'all' current CLI options
> > available via QMP interface.
> >
> > But for now I'd prefer to keep using old way to start target.
>
> Well, if management software developers tell us that -preconfig
> will be already useful without -incoming support, I won't object.
Hmm, that depends on what we will be configured using the new interface.
We usually prefer to use the same approach to set up things when
starting a new VM and when starting a VM for migration.
Since we do have options to setup the vCPU topology stuff on the
command line once we are going to migrate, we certainly can use
-preconfig even when it will collide with -incoming
Ideally -preconfig should replace -incoming, so that we can swithc to
incomming migration operation after we configure everything.
> But it would be very nice for management software if they can
> simply assume that -preconfig and -incoming will work together
> since the first version. Can we have this as a goal for 2.13?
It usually helps in reducing code clutter.
signature.asc
Description: PGP signature
- Re: [Qemu-devel] [PATCH v4 3/9] cli: add -preconfig option,
Peter Krempa <=