qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 2.5 v5 0/11] dataplane snapshot fixes
Date: Mon, 9 Nov 2015 14:05:47 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

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.

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]