From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60688 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONOfQ-0007Lb-1d for qemu-devel@nongnu.org; Sat, 12 Jun 2010 07:14:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONOfO-0007Mo-LE for qemu-devel@nongnu.org; Sat, 12 Jun 2010 07:14:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50731) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONOfO-0007Mg-AL for qemu-devel@nongnu.org; Sat, 12 Jun 2010 07:14:22 -0400 From: Juan Quintela In-Reply-To: <4C124A72.9000807@codemonkey.ws> (Anthony Liguori's message of "Fri, 11 Jun 2010 09:38:42 -0500") References: <20100609175215.2e2071a0@redhat.com> <20100611113022.27490bfe@redhat.com> <4C124A72.9000807@codemonkey.ws> Date: Sat, 12 Jun 2010 13:14:17 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, Luiz Capitulino Anthony Liguori wrote: > On 06/11/2010 09:30 AM, Luiz Capitulino wrote: >> On Thu, 10 Jun 2010 12:44:55 +0200 >> Juan Quintela wrote: > > I think we've more or less agreed that MIGRATION_CONNECTED is really > the event we want. This had the problem of migrating to a file/whatever. MIGRATION_CONECTED only makes sense when you have TCP or similar. MIGRATION_STARTED it just means that migration has started, independently of whatever method you have. For TCP it is possible that we want another event each time that somebody connected to a port (not only for migration), but that is something different. >>> - MIGRATION_ENDED: migration ended with sucess, all needed data is in >>> target machine. Also emitted in all monitors on source and target. >>> >>> - MIGRATION_CANCELED: in one of the source monitors somebody typed: >>> migrate_cancel. It is only emmited on the source monitors, target >>> monitors will receive a MIGRATION_FAILED event. >>> >>> - MIGRATION_FAILED (with this error). At this point we don't have >>> neither the QMP infraestructure for sending (with this error) nor >>> migration infrastructure to put there anything different than -1. >>> >> Aren't all the three events above duplicating the async response? >> > > Yes. Today, we should just generate a MIGRATION_DONE event and let a > client poll for failure status. I disagree completely. It just defeat the reason for this. MIGRATION_ENDED on destination machine: go ahead, everything is ok. MIGRATION_FAILED: Uh, oh, something got wrong, we are in the slow path. With MIGRATION_DONE + polling, we are delaying the "success" case just to avoid having a new event. I don't buy it. >>> This event is emmited on all source and target monitors. >>> - For 0.13: Event don't have a QError. >>> - For 0.14: It will gain a QError. >>> >>> About migration becoming an async command. Really it is independent >>> of what events we emit. If migration becomes async command, only >>> difference is for the monitor that emitted the command, rest of >>> monitors see nothing. If we want to be able to see that informantion >>> in the other monitors, we need the events anyways. >>> >> Somewhere else in this discussion someone has said that we should assume >> that the client talking to the source is the same one which is going to >> talk to the target, in this case all the communication is done through >> the source qemu instance. >> > > MIGRATION_DONE gets deprecated for 0.14. I still think that we want the 4 events that I described. My understanding is that libvirt people also would love to have that 4 events. Answer here is that: you can do this workaround and this other workaround and you can get that information. About semantics of messages, I don't see anytime soon that migration are going to change from: Start migration and then end with success or failure. The only one that we could change/remove is MIGRATION_CANCEL to MIGRATION_FAILURE(User canceled) it. But that is it. Why have to do a polling when none is needed? If you preffer to change the MIGRATION_ENDED + MIGRATION_FAILURE(error) to MIGRATION_ENDED(result code), and you have to check the error code, I can also live with that. But that is it. Later, Juan.