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

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]

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, 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.  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.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]