From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38354) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XeRZZ-0005kK-SE for qemu-devel@nongnu.org; Wed, 15 Oct 2014 12:37:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XeRZU-0001Cm-01 for qemu-devel@nongnu.org; Wed, 15 Oct 2014 12:37:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4112) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XeRZT-0001Ce-OP for qemu-devel@nongnu.org; Wed, 15 Oct 2014 12:37:07 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9FGb6FS003955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 15 Oct 2014 12:37:06 -0400 Message-ID: <543EA2B1.7010200@redhat.com> Date: Wed, 15 Oct 2014 10:37:05 -0600 From: Eric Blake MIME-Version: 1.0 References: <1413359710-2799-1-git-send-email-quintela@redhat.com> <543E8B45.3040809@redhat.com> <877g01fhob.fsf@elfo.elfo> In-Reply-To: <877g01fhob.fsf@elfo.elfo> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jwn0oXe6njjBavQuu2mAvJeDUnOa9EDNR" Subject: Re: [Qemu-devel] [RFC 0/7] Optional toplevel sections List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: quintela@redhat.com Cc: kwolf@redhat.com, qemu-devel@nongnu.org, laine@redhat.com, lcapitulino@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jwn0oXe6njjBavQuu2mAvJeDUnOa9EDNR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/15/2014 09:59 AM, Juan Quintela wrote: >> Do we need a new monitor command that says to put the >> guest into the same state that migration said it should be in (and the= >> command fails if migration was from an older source that did not send >> the subsection)? >=20 > I think that you don't need the command. > Target is started "paused" (-S) or "running" (nothing). Libvirt will _always_ pass -S. This is because there is a need for additional handshaking from destination back to source to let the source know that the destination is ready to take over operation. >=20 >=20 > source old: target old: no changes > source old: target new: the same as now, no changes > source new: target new: we set the right state. And if it is not > "running" we don't run on destination, independent of what is happening= =2E > source new: target old: if source is in state "running" or "paused", no= > change. If source is in error state, we sent > the section and migration gets aborted (target > don't understand it) >=20 > source new: target new, running with old machine type: > if state is "running" or "paused", nothing is sent. > if state is "error", target is set to "error". >=20 > So, I think that we get all the cases possible right, no? Only if the existing 'cont' is changed to do something other than put the destination into 'running', which doesn't sound good; or if we add some new way for the destination to resume to the state passed in migrati= on. >=20 >=20 >> How can libvirt introspect that the destination qemu is new enough to >> understand the subsections, and/or that the source qemu is new enough = to >> send the subsections? >=20 > A new qemu_option value would make for you? Or even the existence of a new QMP command in parallel to 'cont' that has semantics of 'please restore this guest to the state it had on incoming migration'. > If you use libvirt, and you *don't* need to do anything special to run > after migration, you shouldn't use -S. And I would emit an event sayin= g > "migration was finished". >=20 No, libvirt will ALWAYS use -S. So what we need is the hooks for using -S and still relying on the migration stream rather than the current status quo of a blind 'cont' (or nothing, if libvirt knows the source was also in the paused state). In fact, it is more confusing than that: libvirt has a live migration mode that will auto-fallback to paused migration if live migration wasn't converging fast enough. That is, on the source, we intentionally pause the source to quit waiting for convergence, but on the destination we then 'cont' to wake the guest back up. In _that_ scenario, the migration stream will contain data that the guest is paused, but we WANT the destination to be running. > But what I want to know is _what_ events are you interested in? Really, an event that the destination is ready to be woken up, and some indication of the destination having received state in the migration stream (so that it will wake up to the correct state). >=20 > Later, Juan. >=20 >=20 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --jwn0oXe6njjBavQuu2mAvJeDUnOa9EDNR 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEbBAEBCAAGBQJUPqKxAAoJEKeha0olJ0Nql64H93r4+e9a4BC2RipSqB5uaIs5 Oce6ei9xEtUM8djXa90kn9UWdO+tfuEapGrMMf6a9XXUPUg/xcgurrYs8cJ/pE9I 1iytZf20o1LptlX4LzNrVeF9vRFWu3jiz8CIeLx++dc5j8hRH6Qv9PdHGXZL9JG6 5dOekHVumoTHYwAlqI4CzaLDz67Ma6cUrQ57zzMi9D1We+ky2Hh6xLsLR4vpKHI/ /MgtKhmaE++bhI8exP0MzOgA/gEMqj3pEbGzI12uPQtEJh2aoexdlkw9VWiPUUNp amkrHCUdAb5GWfVunNdEWqqxFxtjqEf+awkTbvhWiK5uJaXF1uUNzjbQNu9Wag== =Vk+z -----END PGP SIGNATURE----- --jwn0oXe6njjBavQuu2mAvJeDUnOa9EDNR--