From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48350) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkEbB-0005Ac-Nw for qemu-devel@nongnu.org; Thu, 08 Oct 2015 13:04:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZkEa7-0003Hn-VT for qemu-devel@nongnu.org; Thu, 08 Oct 2015 13:03:21 -0400 Received: from relay.parallels.com ([195.214.232.42]:43426) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkEa2-00039z-2j for qemu-devel@nongnu.org; Thu, 08 Oct 2015 13:02:13 -0400 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> From: "Denis V. Lunev" Message-ID: <5616A180.5090104@openvz.org> Date: Thu, 8 Oct 2015 20:01:52 +0300 MIME-Version: 1.0 In-Reply-To: <5615356D.7030408@redhat.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit 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: Eric Blake , "Dr. David Alan Gilbert" Cc: Igor Redko , quintela@redhat.com, annam@virtuozzo.com, qemu-devel@nongnu.org, amit.shah@redhat.com, jsnow@redhat.com 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’s memory >>> 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 doing >> 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 that > the test: transport has finished computing its numbers). > 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? Den >>> +++ 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. >