From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34769) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URjUb-0004uf-1d for qemu-devel@nongnu.org; Mon, 15 Apr 2013 09:30:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1URjUZ-0006Zg-T6 for qemu-devel@nongnu.org; Mon, 15 Apr 2013 09:30:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8029) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URjUZ-0006Za-IF for qemu-devel@nongnu.org; Mon, 15 Apr 2013 09:30:43 -0400 Message-ID: <516C00DE.4040700@redhat.com> Date: Mon, 15 Apr 2013 15:30:06 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <20130411145632.GA2280@redhat.com> <5166F7AE.8070209@linux.vnet.ibm.com> <20130411191533.GA25515@redhat.com> <51671DFF.80904@linux.vnet.ibm.com> <20130412104802.GA23467@redhat.com> <5168105C.5040605@linux.vnet.ibm.com> <20130414082827.GA1548@redhat.com> <516ABDB8.1090100@linux.vnet.ibm.com> <20130414185116.GE7165@redhat.com> <516B06E0.9040804@linux.vnet.ibm.com> <20130414211647.GG7165@redhat.com> <516B538C.5060008@linux.vnet.ibm.com> <516BBB99.5040302@redhat.com> <516BFF83.40505@linux.vnet.ibm.com> In-Reply-To: <516BFF83.40505@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH RDMA support v5: 03/12] comprehensive protocol documentation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael R. Hines" Cc: aliguori@us.ibm.com, "Michael S. Tsirkin" , qemu-devel@nongnu.org, owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com Il 15/04/2013 15:24, Michael R. Hines ha scritto: > Now, in this example, let's say the migration starts up and the hypervisor > has run out of physical memory and starts swapping during the migration. > (also for the sake of argument). > > The next thing that would immediately happen is the > next IB verbs function call: "ib_reg_mr()". > > This function call would probably fail because there's nothing else left > to pin and the function call would return an error. > > So my question is: Is it not sufficient to send a message back to the > primary-VM side of the connection which says: > > "Your migration cannot proceed anymore, please resume the VM and try > again somewhere else". > > In this case, both the system administrator and the virtual machine are safe, > nothing has been killed, nothing has crashed, and the management software > can proceed to make a new management decision. > > Is there something wrong with this sequence of events? I think it's good enough. "info migrate" will then report that migration failed. Paolo