From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56614) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkEde-0008DJ-RU for qemu-devel@nongnu.org; Thu, 08 Oct 2015 13:05:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZkEdd-00020x-Oe for qemu-devel@nongnu.org; Thu, 08 Oct 2015 13:05:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42568) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkEdd-00020h-I8 for qemu-devel@nongnu.org; Thu, 08 Oct 2015 13:05:53 -0400 Date: Thu, 8 Oct 2015 18:05:47 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20151008170547.GC2667@work-vm> References: <5614531B.5080107@redhat.com> <1444198846-5383-1-git-send-email-den@openvz.org> <1444198846-5383-8-git-send-email-den@openvz.org> <20151007135653.GF2710@work-vm> <5615356D.7030408@redhat.com> <5616A180.5090104@openvz.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5616A180.5090104@openvz.org> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 7/8] migration: new migration test mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Denis V. Lunev" Cc: Igor Redko , quintela@redhat.com, jsnow@redhat.com, annam@virtuozzo.com, qemu-devel@nongnu.org, amit.shah@redhat.com * Denis V. Lunev (den@openvz.org) wrote: > On 10/07/2015 06:08 PM, Eric Blake wrote: > >On 10/07/2015 07:56 AM, Dr. David Alan Gilbert wrote: > >>* Denis V. Lunev (den@openvz.org) wrote: > >>>From: Igor Redko > >>> > >>>In this patch the ability to start a migration with test-only > >>>capability was added. It allows to gather the guest VM=E2=80=99s mem= ory > >>>usage statistics avoiding time and memory overheads and real > >>>data transmission. New MIGRATION_STATUS_TEST_COMPLETED was > >>>added to distinguish between test migration and true migration > >>>success states. > >>Why isn't this just a new transport? i.e. I could do this just by doi= ng > >>a migrate to test: ? > >> > >>It seems simpler and avoids some of the special casing? > >Indeed. Even if the new state can only be triggered by using a new > >option, the fact that the new state exists in introspection means > >clients have to figure out what to do with it; while a new transport > >would not require any new states ("running" to completion means that > >nothing migrated, but the existing states can then be reused to see th= at > >the test: transport has finished computing its numbers). > > >=20 > we need to expose calculated numbers to the caller somehow. > This could be done in MIGRATION_STATUS_COMPLETED state > even for ordinary migration. Will it be OK? I think so; if you look at the way the information is displayed in info migrate, a lot of the data is only displayed 'sometimes', e.g. : if (blk_mig_active()) { info->has_disk =3D true; info->disk =3D g_malloc0(sizeof(*info->disk)); info->disk->transferred =3D blk_mig_bytes_transferred(); info->disk->remaining =3D blk_mig_bytes_remaining(); info->disk->total =3D blk_mig_bytes_total(); } It seems fair to do the same type of thing if you have an extra block of values. Dave >=20 > Den >=20 > >>>+++ b/qapi-schema.json > >>>@@ -432,6 +432,8 @@ > >>> # > >>> # @completed: migration is finished. > >>> # > >>>+# @test-completed: migration time estimation finished. > >>>+# > >If this gets added, in spite of our ideas to use a 'test:' transport > >instead of a new state, it would need a 'since 2.5' marker. > > >=20 -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK