Re: [Qemu-devel] [PATCH 3/4] Purge migration of (almost) everything to do with monitors

[Anthony Liguori]

On 03/09/2012 12:45 PM, Eric Blake wrote:
> On 03/09/2012 11:31 AM, Anthony Liguori wrote:
> > On 03/09/2012 12:20 PM, Jan Kiszka wrote:
> > > On 2012-03-09 19:13, Luiz Capitulino wrote:
> > > > The Monitor object is passed back and forth within the migration/savevm
> > > > code so that it can print errors and progress to the user.
> > > >
> > > > However, that approach assumes a HMP monitor, being completely invalid
> > > > in QMP.
> > > >
> > > > This commit drops almost every single usage of the Monitor object, all
> > > > monitor_printf() calls have been converted into DPRINTF() ones.
> > >
> > > I guess for most printfs, this is OK. But do you provide an alternative
> > > for the block migration progress output? I did not find anything on
> > > first glance. That is not a debugging feature.
> >
> > The block migration progress stuff is horribly broken and I regret ever
> > merging it.  Are you actively relying on this?
> >
> > Does block migration even work?
> >
> > Could we just remove block migration entirely...
>
> Libvirt has already exposed block migration to users,

:-(

Do you rely on the progress stats that are printed?

> but it is
> untested; if, as you say, it is horribly broken, then libvirt needs to
> pass on the error message back to the user that it is broken.  But we
> regularly get people complaining that they don't have shared storage set
> up, and they are looking for a magic bullet that will do block migration
> alongside the domain migration; perhaps libvirt can still provide that
> with block mirroring or other (working) solutions from the same API it
> gives to the user if you end up pulling it out of the migrate QMP
> command.

Well block mirroring is hopefully around the corner.

Regards,

Anthony Liguori

> At the end of the day, it's your call whether to pull it out,
> and libvirt will adapt, but it would be nice to know what kosher working
> alternative(s) to use instead.