On 10 Oct 2014, at 5:59 , Jiri Denemark <jdenemar@xxxxxxxxxx> wrote:
> On Thu, Oct 09, 2014 at 16:22:54 +0900, Cristian Klein wrote:
>> On 07 Oct 2014, at 23:48 , Jiri Denemark <jdenemar@xxxxxxxxxx> wrote:
>>
>>> On Tue, Sep 30, 2014 at 16:39:29 +0200, Cristian Klein wrote:
>>>> Signed-off-by: Cristian Klein <cristian.klein@xxxxxxxxx>
>>>> ---
>>>> tools/virsh-domain.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++--
>>>> tools/virsh.pod | 5 ++++
>>>> 2 files changed, 75 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
>>>> index 36a6d52..395c73c 100644
>>>> --- a/tools/virsh-domain.c
>>>> +++ b/tools/virsh-domain.c
>>>> @@ -9251,6 +9251,10 @@ static const vshCmdOptDef opts_migrate[] = {
>>>> .type = VSH_OT_INT,
>>>> .help = N_("force guest to suspend if live migration exceeds timeout (in seconds)")
>>>> },
>>>> + {.name = "postcopy-after",
>>>> + .type = VSH_OT_INT,
>>>> + .help = N_("switch to post-copy migration if live migration exceeds timeout (in seconds)")
>>>> + },
>>>> {.name = "xml",
>>>> .type = VSH_OT_STRING,
>>>> .help = N_("filename containing updated XML for the target")
>>>
>>> We also want to add --postcopy option to enable just
>>> VIR_MIGRATE_POSTCOPY without an automatic switch to post-copy after a
>>> timeout. The --postcopy-after option may turn it on automatically,
>>> though, so that users don't have to use --postcopy --postcopy-after. And
>>> we also want to add a new migrate-startpostcopy command as a direct
>>> wrapper to virDomainMigrateStartPostCopy.
>>
>> I’m still not convinced this is a good idea. To use —postcopy and
>> migrate-startpostcopy, the user would have to launch a second instance
>> of virsh, since the first one is busy monitoring the migration. I feel
>> that this is a bit too low level for a tool like virsh: It would be as
>> if we offered the user a dedicated migrate-cancel command, instead of
>> pressing CTRL+C.
>
> I'm not saying we should remove --postcopy-after and only provide
> --postcopy and migrate-startpostcopy. We should provide both ways of
> switching to post-copy: the easy one (--postcopy-after) and the powerful
> one (--postcopy + migrate-startpostcopy). We tend to make every single
> piece of libvirt API available through virsh so that it has the full
> power. The ability to call any libvirt API manually with virsh is often
> useful for developers. You may, for example, try to call
> migrate-startpostcopy on a domain that's not even running, is not being
> migrated, or is being migrated without the POSTCOPY flag.
>
> In addition to the low level wrappers for libvirt APIs, we sometimes
> provide easy-to-use wrappers for some functionality, e.g., creating
> snapshots, aborting long running jobs...
>
> Your example with migrate-cancel is actually a perfect one since it is
> exactly what I'm asking for. We do have the ability to cancel migration
> via a dedicated virsh command and the command is called domjobabort
> (it's not limit to migration, it also covers managed-save, dump, and
> other similar jobs). In addition to this command users can just press
> Ctrl-C to achieve the same without having to run one more virsh.
I didn’t know about domjobabort. That’s a pretty compelling argument to add migrate-startpostcopy. Okey, I’ll add it in the next version of the patch series.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list