qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/5] migration: Remove use of old MigrationParam


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 3/5] migration: Remove use of old MigrationParams
Date: Tue, 16 May 2017 17:35:40 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Juan Quintela <address@hidden> writes:

> Markus Armbruster <address@hidden> wrote:
>> Juan Quintela <address@hidden> writes:
>>
>>> We have change in the previous patch to use migration capabilities for
>>> it.  Notice that we continue using the old command line flags from
>>> migrate command from the time being.  Remove the set_params method as
>>> now it is empty.
>>>
>>> Signed-off-by: Juan Quintela <address@hidden>
>
>>> diff --git a/migration/savevm.c b/migration/savevm.c
>>> index b4f736f..5fc10ab 100644
>>> --- a/migration/savevm.c
>>> +++ b/migration/savevm.c
>>> @@ -1233,8 +1233,6 @@ static int qemu_savevm_state(QEMUFile *f, Error 
>>> **errp)
>>>  {
>>>      int ret;
>>>      MigrationParams params = {
>>> -        .blk = 0,
>>> -        .shared = 0
>>>      };
>>>      MigrationState *ms = migrate_init(&params);
>>>      MigrationStatus status;
>>> @@ -1245,6 +1243,12 @@ static int qemu_savevm_state(QEMUFile *f, Error 
>>> **errp)
>>>          goto done;
>>>      }
>>>  
>>> +    if (migrate_use_block()) {
>>> +        error_setg(errp, "Block migration and snapshots are incompatible");
>>> +        ret = -EINVAL;
>>> +        goto done;
>>> +    }
>>> +
>>>      qemu_mutex_unlock_iothread();
>>>      qemu_savevm_state_header(f);
>>>      qemu_savevm_state_begin(f, &params);
>>
>> New error that isn't mentioned in the commit message.  Does it belong
>> here?
>
> It is the equivalent of the previous chunk.
>
> If you do a savevm, you can't do a:
>
> savevm -b/-i foo
>
> but now you can do:
>
> migrate_set_capability block on
> savevm foo
>
> And we can't use block migration.  If you preffer, I can disable the
> feature unconditionally, but I am not sure that it is much better.

I see.

Add your explanation to the commit message, and I'm happy.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]