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 <ehabk...@redhat.com> 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 <ehabk...@redhat.com> 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
