qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC][PATCH 09/16 v6] introduce a new monitor command '


From: Eric Blake
Subject: Re: [Qemu-devel] [RFC][PATCH 09/16 v6] introduce a new monitor command 'dump' to dump guest's memory
Date: Fri, 17 Feb 2012 10:05:45 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0

On 02/17/2012 09:51 AM, Jan Kiszka wrote:
> On 2012-02-17 17:32, Eric Blake wrote:
>> There are other APIs where qemu has ended up pausing the domain and not
>> restoring things back to running when done, and where libvirt has had to
>> track existing state prior to starting actions in order to manually fix
>> things after the fact (see libvirt's qemudDomainCoreDump as a wrapper
>> around migration to file, for an example).  If we do things right in
>> this new DumpState API, we may want to decide to fix other monitor
>> commands to use the same mechanism (it won't offload any of the burden
>> from libvirt, which must still correctly interact with older qemu, but
>> would make life nicer for clients that can assume the saner semantics).
> 
> I think there is no need for a new API. Everything you need is there:
> check current state, prevent transitions or invoked handlers on
> unexpected transitions. If other commands do not make use of this, they
> should probably be fixed.
> 
> What command or series of commands do you have in mind?

Right now, libvirt pauses qemu itself at least before issuing 'migrate'
to file, before issuing 'savevm', and before issuing
'blockdev-snapshot-sync' [1].  In particular, this comment in the
libvirt code surrounding the 'savevm' call is interesting:

    if (virDomainObjGetState(vm, NULL) == VIR_DOMAIN_RUNNING) {
        /* savevm monitor command pauses the domain emitting an event which
         * confuses libvirt since it's not notified when qemu resumes the
         * domain. Thus we stop and start CPUs ourselves.
         */

I'm not sure if the situation has improved since that comment was first
written, but it looks like a case where if libvirt were to let qemu do
the pause and resume as part of the single monitor command, instead of
libvirt breaking things into multiple monitor commands to track state
itself, then enough weird stuff happened at least with older versions of
qemu to make libvirt unhappy.

[1] Note - the fact that libvirt must pause around
'blockdev-snapshot-sync' is due to an orthogonal issue of snapshotting
more than one disk as an atomic operation; my understanding is that Jeff
Cody is working on a patch series to add a new monitor command
'blockdev-group-snapshot-sync' that would let libvirt delegate the pause
and resume to qemu instead, but that's a topic for a different thread.

-- 
Eric Blake   address@hidden    +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]