On Wed, Mar 01, 2023 at 06:29:50PM +0200, Anton Kuchin wrote: > On 01/03/2023 17:52, Michael S. Tsirkin wrote: > > On Wed, Mar 01, 2023 at 05:40:09PM +0200, Anton Kuchin wrote: > > > So catching errors in not the only purpose of this property, but it > > > definitely > > > allows us to catch some obvious ones. > > OK let's say this. If migration=external then migration just works. > > If migration=internal it fails for now. We are agreed here right? > > > > Our argument is whether to check on load or save? > > > > I propose this compromize: two properties: > > migration-load and migration-save > > > > migration-load : how is incoming migration handled. > > internal - through qemu > > external - through the daemon > > > > checked in pre-load > > > > migration-save : how is outgoing migration handled. > > internal - through qemu > > external - through the daemon > > > > checked in post-save > > > > This way whether the check is on source or destination or both > > is up to the user. > > > > Hmm? > > Hmm, sounds interesting, this can be a really good compromise. > > So migration-save will be "none" by default to protect unaware > orchestrators. > What do you think should migration-load be "none" too to force orchestrator > set proper incoming migration type?
Yes. I am also thinking whether we should block setting migration-load if qemu is starting a VM as opposed to loading it. Thoughts? -- MST