Re: [Qemu-devel] [PATCH 2.5 v5 0/11] dataplane snapshot fixes

["Denis V. Lunev" <den@openvz.org>]

On 11/10/2015 12:05 AM, Eric Blake wrote:
> On 11/06/2015 02:13 PM, Denis V. Lunev wrote:
>
>>> That is a case of using libvirt to trigger internal snapshots...
>>>
>>>> The HMP monitor is legacy and also not used by modern libvirt.
>>> ...and libvirt is forced to use HMP for internal snapshots, since we
>>> _still_ haven't exposed internal snapshots as a QMP command.
>> Eric,
>>
>> by the way, there is a user visible bug with this too :))))))
>>
>> EFI based VM with pflash storage for NVRAM could not
>> be snapshoted as libvirt configures storage as 'raw'.
>> OK, this is a libvirt bug. The patch will be sent next
>> week or in a week by my colleague switching storage
>> type from 'raw' to 'qcow2'.
> Not necessarily a bug in libvirt, so much as a limitation that the
> current qemu implementation of internal snapshots requires qcow2 for all
> storage devices (even though it might not be technically necessary, if
> there were an easy way to snapshot state of one non-qcow2 storage
> alongside the rest of the machine state stored elsewhere).  But a
> libvirt patch would certainly be useful.
>
>> For a QEMU this results in the following:
>> - QEMU receives command via HMP to make a snapshot
>> - it fails, but QEMU does not see that fact (error code
>>    is not delivered to libvirt in HMP AFAIK)
> Libvirt is still using QMP to deliver the HMP command (via the QMP
> human-monitor-command); if I'm understanding your complaint correctly,
> you are saying that qemu doesn't do error reporting correctly for that?
> If so, fix that in qemu, although libvirt should also be able to work
> around it when dealing with broken qemu.
>
>> - on request to switch to snapshot the commands
>>    just do nothing and from the point of libvirt the command
>>    was successful
>>
>> We should have these commands even in the simple
>> rudimentary current non-ideal form even just as wrappers
>> around HMP functions.
>>
>> Do you have an opinion about importance of the last
>> issue? Should it be considered for 2.6?
> We've gone since 0.14 without anyone writing the remaining few QMP
> commands to completely obsolete the need for human-monitor-command
> backdoors into HMP.  Volunteers are welcome to submit code to complete
> the conversion, but the length of time it has taken so far may be an
> indication that it is not as easy as you think.
>
I have one for snapshot operations :)

Den