From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50566) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xirgm-0005up-Hp for qemu-devel@nongnu.org; Mon, 27 Oct 2014 17:19:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xirgc-0005LZ-I9 for qemu-devel@nongnu.org; Mon, 27 Oct 2014 17:18:56 -0400 Received: from mail-bn1bon0132.outbound.protection.outlook.com ([157.56.111.132]:17056 helo=na01-bn1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xirgc-0005LI-E2 for qemu-devel@nongnu.org; Mon, 27 Oct 2014 17:18:46 -0400 From: Gary Hook Date: Mon, 27 Oct 2014 21:18:43 +0000 Message-ID: References: <20141027124114.GE5021@work-vm> In-Reply-To: <20141027124114.GE5021@work-vm> Content-Language: en-US Content-Type: text/plain; charset="Windows-1252" Content-ID: <2B43EE0E7CA5884FA4A7BC7386CECBF1@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Qemu-devel] Postcopy failures List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "qemu-devel@nongnu.org" On 10/27/14, 7:41 AM, "Dr. David Alan Gilbert" wrote: >It should be possible to postcopy block storage as well, if that's >the question (it might take some work to make sure that they play >nicely together; e.g. wanting to making the page transfer higher >priority than block transfer). >However, I thought there were other ways to do block storage >migration (using blockcopy I think? but I'm not a block guy). Honestly (and frankly), it is a complete *ahem* =B3challenge=B2 to walk int= o a project that is in a state of high flux and attempt to ascertain the terminology in use with little usable documentation. I am trying to learn, however. I believe I understand the above statement, but there=B9s a more fundamental issue for which I can find no discussion anywhere on the inter web. So perhaps it would be sensible if I explain my context. Here=B9s the problem: a (working) peer-to-peer transfer of a modest VM succeeds (PEER2PEER, PERSIST_DEST, NON_SHARED_INC) (running under libvirt), regardless of its size. As soon as the TUNNELLED [sic] flag is added (because security is a good thing) the transfer of the qcow2 file completes but the sending side throws an error. The migration therefore fails with an =B3unexpected error=B2 according to libvirt logging. A smaller (about 1.9 GB) VM succeeds,ostensibly because it completes before some timeout value is reached. My conclusion is that the timeout throws an invalid error, and based upon patch 47, my conclusion seems reasonable. I=B9d like to: 1) understand if/when the patches that went by on 10/3 (47 pieces?) are going to be committed, and if so, how do I access them? A git clone today didn=B9t include that code, and I=B9d like to test that modification to see= if it addresses my failure. 2) I=B9d also love to understand how to turn on tracing in what becomes the qemu-system_x86_64 executable on Ubuntu 14.04. Command line options are valueless when I don=B9t control the invocation of the process. Thus I wonder if there is a config file mechanism or environment variable that can be used? That presumes, of course, that I=B9ve managed to even build th= e system with tracing enabled=8A. Searching wiki.qemu.org has been so far fruitless. The word =B3trace=B2 sho= ws up in exactly one document, in the discussion of command line parameters. I need to crawl into the engine to find and resolve this failure; at this point the challenge is getting the hood open. Any advice/pointers from any corner would be greatly appreciated.