From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39117) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XeQ0u-0007Nh-VG for qemu-devel@nongnu.org; Wed, 15 Oct 2014 10:57:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XeQ0l-0008Iq-GO for qemu-devel@nongnu.org; Wed, 15 Oct 2014 10:57:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58762) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XeQ0l-0008If-9P for qemu-devel@nongnu.org; Wed, 15 Oct 2014 10:57:11 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9FEvALx018168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 15 Oct 2014 10:57:10 -0400 Message-ID: <543E8B45.3040809@redhat.com> Date: Wed, 15 Oct 2014 08:57:09 -0600 From: Eric Blake MIME-Version: 1.0 References: <1413359710-2799-1-git-send-email-quintela@redhat.com> In-Reply-To: <1413359710-2799-1-git-send-email-quintela@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WL758K9c7wp7f4KXXjV7mGxE6lMaJJRMA" Subject: Re: [Qemu-devel] [RFC 0/7] Optional toplevel sections List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela , qemu-devel@nongnu.org Cc: kwolf@redhat.com, laine@redhat.com, lcapitulino@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WL758K9c7wp7f4KXXjV7mGxE6lMaJJRMA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/15/2014 01:55 AM, Juan Quintela wrote: > Hi >=20 > by popular demand, and after too many time, this series. This is an > RFC to know what people think about how to use them, the interface > proposed, whatever. >=20 > * simplify optional subsections moving the "needed" function to > vmstate description. I think that this simplification makes sense > by itself, it is indipendent of the rest of the patches. >=20 > * runstate: To make an example of an optional section, I decided to > use current runstate. Right now, we have a problem when: > - we start destination without -S > - we run migration, and it causes an ioerror on source, but migration= finishes > - we try to run migration on destination anyways, when it is > possible that we could get disk corruption (the ioerror was there f= or a reason) > Luiz: You can see any obvious improvement about how we use runstates?= > Laine: Could you told me if you (libvirt) like this or would want > something a bit different? Right now, libvirt always uses -S, then just calls 'cont' on the destination to resume the CPUs (if the migration was live and the source was in the running state). But if we start passing other states, 'cont' might not be the right thing to do. For example, if the guest is at S3 on the source, how do we transfer from in migration to S3 at the destination? 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)? 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 > * I sent that option indpendently for new machine types. >=20 > * For old machine types I use this as one example of optional section. > We only sent it when the state is different from "running" or "paused= ". >=20 > So, the only case where we fail is if we migrate to an old qemu and > there is one error. Seems reasonable. >=20 > * On the runstate subsection "postload" we can send any event for > anything that libvirt wants when migration finishes. > Laine, can you told us what libvirt would preffer for this? So you're thinking that an event on the destination emitted stating that 'incoming migration is complete, and requests the following state' is sufficient for libvirt to know how to put the domain into that state? >=20 > Kevin: You asked for optional sections in the past for the block > layer, would this proposal be enough for you? >=20 > Please review, comment. >=20 > Thanks, Juan. >=20 > PD. Yes, on proper submission, patches 6 and 7 are on the wrong order.= >=20 > Juan Quintela (7): > migration: Create optional sections > runstate: Add runstate store > runstate: create runstate_index function > runstate: migration allows more transitions now > migration: create now section to store global state > global_state: Make section optional > vmstate: Create optional sections >=20 > cpus.c | 11 ++-- > docs/migration.txt | 11 ++-- > exec.c | 11 ++-- > hw/acpi/ich9.c | 10 ++-- > hw/acpi/piix4.c | 10 ++-- > hw/block/fdc.c | 37 +++++-------- > hw/char/serial.c | 41 ++++++--------- > hw/display/qxl.c | 11 ++-- > hw/display/vga.c | 11 ++-- > hw/i386/pc_piix.c | 2 + > hw/ide/core.c | 32 +++++------- > hw/ide/pci.c | 16 +++--- > hw/input/pckbd.c | 22 ++++---- > hw/input/ps2.c | 11 ++-- > hw/isa/lpc_ich9.c | 10 ++-- > hw/net/e1000.c | 11 ++-- > hw/net/rtl8139.c | 11 ++-- > hw/net/vmxnet3.c | 12 ++--- > hw/pci-host/piix.c | 10 ++-- > hw/scsi/scsi-bus.c | 11 ++-- > hw/timer/hpet.c | 11 ++-- > hw/timer/mc146818rtc.c | 23 ++++----- > hw/usb/hcd-ohci.c | 11 ++-- > hw/usb/redirect.c | 34 ++++++------ > hw/virtio/virtio.c | 10 ++-- > include/migration/migration.h | 4 ++ > include/migration/vmstate.h | 10 ++-- > include/sysemu/sysemu.h | 2 + > migration.c | 117 ++++++++++++++++++++++++++++++++++= ++++++-- > savevm.c | 14 +++-- > target-arm/machine.c | 26 ++++------ > target-i386/machine.c | 71 ++++++++++--------------- > target-ppc/machine.c | 62 +++++++++------------- > vl.c | 26 ++++++++++ > vmstate.c | 27 +++++++--- > 35 files changed, 393 insertions(+), 356 deletions(-) >=20 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --WL758K9c7wp7f4KXXjV7mGxE6lMaJJRMA 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 iQEcBAEBCAAGBQJUPotFAAoJEKeha0olJ0NqikgIAIshy1C0gq6pftnMMRlaI9If L73UkLC/a87jpAOSncBM8bmTFwWRTRzgH8sYXC8txTFyvgonfUs8BTZl9RwKNxAZ r/ALNf+CIddXzI9E2pAh9zvqGAKSljzRhfv61lNxjXzpCEb5lM7V3qdzxrUFt2k2 fJqy3KqHEYuM7qnKQ19vnvxDOfSocKfOIZEF4OZF6OJysY7B1NfnG9t/bHzWVX26 93Z0bc/tVYT1jO2RPnPLREevcixm+Jw9zlhKK3m8cjpKsjGQRlPYb9IV9vNSYRdo jcjhnuxJqoFFNHbrp0f0p7iY10jwfLK9Ld8VC5AQ1Q9i3/TEt1JGcodSqXWxgJw= =BuAb -----END PGP SIGNATURE----- --WL758K9c7wp7f4KXXjV7mGxE6lMaJJRMA--