qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Postcopy failures


From: Gary Hook
Subject: Re: [Qemu-devel] Postcopy failures
Date: Mon, 27 Oct 2014 21:18:43 +0000

On 10/27/14, 7:41 AM, "Dr. David Alan Gilbert" <address@hidden> 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* ³challenge² to walk into 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¹s 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¹s 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 ³unexpected error² 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¹d 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¹t include that code, and I¹d like to test that modification to see if
it addresses my failure.

2) I¹d 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¹t 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¹ve managed to even build the
system with tracing enabledŠ.

Searching wiki.qemu.org has been so far fruitless. The word ³trace² shows
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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]