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.
Jirka
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list