From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RyRFq-0002m9-H5 for qemu-devel@nongnu.org; Fri, 17 Feb 2012 12:05:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RyRFp-0005jK-5V for qemu-devel@nongnu.org; Fri, 17 Feb 2012 12:05:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33909) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RyRFo-0005jG-TQ for qemu-devel@nongnu.org; Fri, 17 Feb 2012 12:05:53 -0500 Message-ID: <4F3E88E9.2070305@redhat.com> Date: Fri, 17 Feb 2012 10:05:45 -0700 From: Eric Blake MIME-Version: 1.0 References: <4F333AAA.1070601@cn.fujitsu.com> <4F333D4B.6090300@cn.fujitsu.com> <4F3AA11C.50408@siemens.com> <4F3E1546.9090303@cn.fujitsu.com> <4F3E8130.10908@redhat.com> <4F3E8590.1060505@siemens.com> In-Reply-To: <4F3E8590.1060505@siemens.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigDBDD70AACA045BE42D969FC1" Subject: Re: [Qemu-devel] [RFC][PATCH 09/16 v6] introduce a new monitor command 'dump' to dump guest's memory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: HATAYAMA Daisuke , Dave Anderson , qemu-devel , Luiz Capitulino This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDBDD70AACA045BE42D969FC1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 no= t >> restoring things back to running when done, and where libvirt has had = to >> track existing state prior to starting actions in order to manually fi= x >> 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)= =2E >=20 > 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. >=20 > 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) =3D=3D VIR_DOMAIN_RUNNING) { /* savevm monitor command pauses the domain emitting an event whi= ch * 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. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigDBDD70AACA045BE42D969FC1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPPojqAAoJEKeha0olJ0NqqLUH/31DsEhngSe68TaFxfQSA+gI yfauII500xfYsEJ8Zf0NqQWD0BxWSCnaLZz7xSxOM+eEvoNJd3ikp4nu1Ui1A9cv tq+Wugt3M0dv+92lGWAXda0exJ9yP7CarwhGCPV0enpdkBkx5PH+2e0gKXHpbLXl jaRmCkduCsiB4T3YGMREH5LWUJSbshvXCIuJ/eWUw5T0awpVpRMgL80FtPXg0qTw nZkCv/tMOL8SunqJhliw4eV426Aua3w+hOovu1olxnq3bt15q/9Cxm+RVRplKzsM Y0p4EBV1fo6k+D5cT4lWsqIP42Fu35D9esk9O6dok34DXU2F9AyyrPlWkSdWMq0= =LXOZ -----END PGP SIGNATURE----- --------------enigDBDD70AACA045BE42D969FC1--