From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxHhp-0003c0-Mw for qemu-devel@nongnu.org; Fri, 13 Nov 2015 12:00:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZxHhm-0002Zx-5d for qemu-devel@nongnu.org; Fri, 13 Nov 2015 12:00:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33380) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxHhl-0002Z9-V6 for qemu-devel@nongnu.org; Fri, 13 Nov 2015 12:00:06 -0500 References: <1446551816-15768-1-git-send-email-zhang.zhanghailiang@huawei.com> <1446551816-15768-19-git-send-email-zhang.zhanghailiang@huawei.com> From: Eric Blake Message-ID: <5646170D.7090301@redhat.com> Date: Fri, 13 Nov 2015 09:59:57 -0700 MIME-Version: 1.0 In-Reply-To: <1446551816-15768-19-git-send-email-zhang.zhanghailiang@huawei.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mPF1cUcWvIWieWdk5Q35SXccIhKDpECWb" Subject: Re: [Qemu-devel] [PATCH COLO-Frame v10 18/38] COLO failover: Introduce a new command to trigger a failover List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: zhanghailiang , qemu-devel@nongnu.org Cc: lizhijian@cn.fujitsu.com, quintela@redhat.com, Markus Armbruster , yunhong.jiang@intel.com, eddie.dong@intel.com, peter.huangpeng@huawei.com, dgilbert@redhat.com, arei.gonglei@huawei.com, stefanha@redhat.com, amit.shah@redhat.com, Luiz Capitulino This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mPF1cUcWvIWieWdk5Q35SXccIhKDpECWb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/03/2015 04:56 AM, zhanghailiang wrote: > We leave users to choose whatever heartbeat solution they want, if the = heartbeat > is lost, or other errors they detect, they can use experimental command= > 'x_colo_lost_heartbeat' to tell COLO to do failover, COLO will do opera= tions > accordingly. >=20 > For example, if the command is sent to the PVM, the Primary side will > exit COLO mode and take over operation. If sent to the Secondary, the > secondary will run failover work, then take over server operation to > become the new Primary. >=20 > Cc: Luiz Capitulino > Cc: Eric Blake > Cc: Markus Armbruster > Signed-off-by: zhanghailiang > Signed-off-by: Li Zhijian > --- > v10: Rename command colo_lost_hearbeat to experimental 'x_colo_lost_hea= rtbeat' > --- > @@ -29,6 +30,9 @@ bool migration_incoming_enable_colo(void); > void migration_incoming_exit_colo(void); > void *colo_process_incoming_thread(void *opaque); > bool migration_incoming_in_colo_state(void); > + > +int get_colo_mode(void); Should this return an enum type instead of an int? > +++ b/migration/colo-comm.c > @@ -20,6 +20,17 @@ typedef struct { > =20 > static COLOInfo colo_info; > =20 > +int get_colo_mode(void) > +{ > + if (migration_in_colo_state()) { > + return COLO_MODE_PRIMARY; > + } else if (migration_incoming_in_colo_state()) { > + return COLO_MODE_SECONDARY; > + } else { > + return COLO_MODE_UNKNOWN; > + } > +} Particularly since it is always returning values of the same enum. Not fatal to the patch, so much as a style issue. > +void qmp_x_colo_lost_heartbeat(Error **errp) > +{ > + if (get_colo_mode() =3D=3D COLO_MODE_UNKNOWN) { > + error_setg(errp, QERR_FEATURE_DISABLED, "colo"); > + return; We've slowly been trying to get rid of QERR_ usage. But you aren't the first user, and a global cleanup may be better. So I can overlook it for now. > +++ b/qapi-schema.json > @@ -734,6 +734,32 @@ > 'checkpoint-reply', 'vmstate-send', 'vmstate-size', > 'vmstate-received', 'vmstate-loaded' ] } > =20 > +## > +# @COLOMode > +# > +# The colo mode > +# > +# @unknown: unknown mode > +# > +# @primary: master side > +# > +# @secondary: slave side > +# > +# Since: 2.5 > +## > +{ 'enum': 'COLOMode', > + 'data': [ 'unknown', 'primary', 'secondary'] } > + > +## > +# @x-colo-lost-heartbeat > +# > +# Tell qemu that heartbeat is lost, request it to do takeover procedur= es. > +# The docs here are rather short, compared to your commit message (in particular, the fact that it causes a different action depending on whether it is sent to primary [takeover] or secondary [failover]). > +# Since: 2.5 2.6 in both places. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --mPF1cUcWvIWieWdk5Q35SXccIhKDpECWb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWRhcNAAoJEKeha0olJ0NqXroH/09Fj5lxu9A9Ih3rLamOyhAm CTEr7fokBp0u63mXbgIvRKwAXnDQTkhWiQ28TDSVX8gU2UG88cDGG2tkHCVlXZ7R HYs5qI6lwnCJsXrdGh7OMatJQmVpvgeFEtKpTKQ4mOwYMPQPUfwZnboM9stonwaH 7+WqJWIfTv3r3PtRkj9zHt0zOmw1V+wo3PaYDH+Ef8WoTtbHPipPrB/uWgRpSJ3x h/ASF2FEBOJ3PvVJiWw2p+oO0YB5XD2LgXaeMMfPT0MXU/NRo6juJj580XdC1hB0 IiGyz1h2L3zsZiUjwt8/CoP1axRJjaiTc1mpjReUbCU0WjqyviAW7HxNZ0Kpt7Q= =2nen -----END PGP SIGNATURE----- --mPF1cUcWvIWieWdk5Q35SXccIhKDpECWb--