From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34528) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5Dlx-0003n8-6t for qemu-devel@nongnu.org; Thu, 10 Jul 2014 08:48:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X5Dlr-0002TV-9n for qemu-devel@nongnu.org; Thu, 10 Jul 2014 08:48:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:28342) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5Dlr-0002TG-10 for qemu-devel@nongnu.org; Thu, 10 Jul 2014 08:48:19 -0400 Message-ID: <53BE8B8E.5020505@redhat.com> Date: Thu, 10 Jul 2014 06:48:14 -0600 From: Eric Blake MIME-Version: 1.0 References: <1404495717-4239-1-git-send-email-dgilbert@redhat.com> <53B7D36B.4050800@redhat.com> <20140707140229.GA3443@work-vm> <53BAB03B.5000308@redhat.com> <20140710112921.GG2627@work-vm> In-Reply-To: <20140710112921.GG2627@work-vm> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VaIOxwkxti6GKwpAfI0oDhTnnhVU4mcrq" Subject: Re: [Qemu-devel] [PATCH 00/46] Postcopy implementation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" , Paolo Bonzini Cc: aarcange@redhat.com, yamahata@private.email.ne.jp, quintela@redhat.com, qemu-devel@nongnu.org, lilei@linux.vnet.ibm.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VaIOxwkxti6GKwpAfI0oDhTnnhVU4mcrq Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/10/2014 05:29 AM, Dr. David Alan Gilbert wrote: > * Paolo Bonzini (pbonzini@redhat.com) wrote: >> Il 07/07/2014 16:02, Dr. David Alan Gilbert ha scritto: >>>>> Could you have instead a "migrate_start_postcopy" command, and leav= e the >>>>> policy to management instead? >>> Hmm; yes that is probably possible - although with the migration_set_= parameter >>> configuration you get the best of both worlds: >>> 1) You can set the parameter to say a few seconds and let QEMU hand= le it >>> 2) You can set the parameter really large, but (I need to check) yo= u could >>> drop the parameter later and then cause it to kick in. >>> >>> I also did it this way because it was similar to the way the auto-thr= ottling >>> mechanism. >> >> Auto-throttling doesn't let you configure when it kicks in (it doesn't= even >> need support from the destination side). For postcopy you would still= have >> a capability, like auto-throttling, just not the argument. >> >> The reason why I prefer a manual step from management, is because post= copy >> is a one-way street. Suppose a newer version of management software h= as >> started migration with postcopy configured, and then an older version = is >> started. It is probably an invalid thing to do, but the confusion in = the >> older version could be fatal and it's nice if there's an easy way to p= revent >> it. >=20 > Actually the 'migrate_start_postcopy' idea is growing on me; Eric is th= at > also your preferred way of doing it? >=20 > If we did this I'd: > 1) Remove the migration_set_parameter code I added > 2) and the x-postcopy_ram_start_time parameter > 3) Add a new command migrate_start_postcopy that just sets a flag > which is tested in the same place as I currently check the timeou= t. > If it's issued after a migration has finished it doesn't fail bec= ause > that would be racy. If issued before a migration starts that's O= K > as long as postcopy is enabled and means to start postcopy mode > immediately. So to make sure I understand, the idea is that the management starts migration as normal, then after enough time has elapsed, issues a migrate_start_postcopy to tell qemu that it is okay to switch to postcopy at the next convenient opportunity? Is there any need for an event telling libvirt that enough pre-copy has occurred to make a postcopy worthwhile? And of course, I _still_ want an event for when normal precopy migration is ready (instead of the current solution of libvirt having to poll to track progress). But in answer to your question, yes, it sounds like adding a new command (actually, per QMP conventions it should probably be migrate-start-postcopy with dashes instead of underscore) for management to determine if/when to allow postcopy to kick in seems okay. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --VaIOxwkxti6GKwpAfI0oDhTnnhVU4mcrq 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 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTvouOAAoJEKeha0olJ0NqNqAIAIYjFK4ZnYdUlYu+qbY66rzz d/qvzVlgF0kuFijDUCDrmpeuQ0aVytoD0/rPhZt7fVRuM1nl2PMUeXUsc99uU+F/ ElCOTp97EDTEtoF1oIvB2eeNAR7JIHodZ8rQZyJ2CbRrUEebBdBlaGerYTn6ZRZr /HusSly0RoDETDjaYADJaO5WP2N7tBbNROTb54EEuBPmoFYdQInlYpqK7jTOCOA6 7mAU3tnHzLE4k1aDPsvw4GZDSo/7Vb6bJme3TPMdHtBkI70una7os+G2wvK6qtgP kKKO1l3jVdDejkMsLxpQq3M9JdNRoBS1Kzn4ABolrWmLsapNAms57j//kbQuOKc= =kW3M -----END PGP SIGNATURE----- --VaIOxwkxti6GKwpAfI0oDhTnnhVU4mcrq--