|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration |
Date: | Tue, 07 Sep 2010 10:20:14 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 |
On 09/07/2010 10:09 AM, Stefan Hajnoczi wrote:
Right, so that argues for an incremental interface like I started with :-) BTW, this whole discussion is also relevant for other background tasks like online defragmentation so keep that use-case in mind too.Right, I'm a little hesitant to get too far into discussing the management interface because I remember long threads about polling and async. I never fully read them but I bet some wisdom came out of them that applies here. There are two ways to do a long running (async?) task: 1. Multiple smaller pokes. Perhaps completion of a single poke is async. But the key is that the interface is incremental and driven by the management stack. 2. State. Turn on streaming and watch it go. You can find out its current state using another command which will tell you whether it is enabled/disabled and progress. Use a command to disable it.
If everyone is going to do (1) by just doing a tight loop or just using the same simple mechanism (a sleep(5)), then I agree, we should do (2).
I can envision people wanting to do very complex decisions about the right time to do the next poke though and I'm looking for feedback about what other people think.
I expected people to do complex heuristics with respect to migration convergence but in reality, I don't think anyone does today. So while I generally like being flexible, I realize that too much flexibility isn't always a good thing :-)
Regards, Anthony Liguori
Stefan
[Prev in Thread] | Current Thread | [Next in Thread] |