From: Gary Hook <gary.hook@nimboxx.com>
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Postcopy failures
Date: Mon, 27 Oct 2014 21:18:43 +0000 [thread overview]
Message-ID: <D0741AED.2332%gary.hook@nimboxx.com> (raw)
In-Reply-To: <20141027124114.GE5021@work-vm>
On 10/27/14, 7:41 AM, "Dr. David Alan Gilbert" <dgilbert@redhat.com> 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.
prev parent reply other threads:[~2014-10-27 21:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-24 16:48 [Qemu-devel] Postcopy failures Gary Hook
2014-10-27 12:41 ` Dr. David Alan Gilbert
2014-10-27 21:18 ` Gary Hook [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D0741AED.2332%gary.hook@nimboxx.com \
--to=gary.hook@nimboxx.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).