On 01/03/2012 05:47 PM, Stefan Hajnoczi wrote: > On Tue, Jan 3, 2012 at 3:34 PM, Orit Wasserman <owass...@redhat.com> wrote: >> + .args_type = "detach:-d,blk:-b,inc:-i,xbrle:-x,uri:s", >> + .params = "[-d] [-b] [-i] [-x] uri", >> + .help = "migrate to URI" >> + "\n\t -d to not wait for completion" >> + "\n\t -b for migration without shared storage with" >> + " full copy of disk" >> + "\n\t -i for migration without" >> + " shared storage with incremental copy of disk" >> + " (base image shared between source and destination)" >> + "\n\t -x to use XBRLE page delta compression", > > It's too bad that this algorithm is user-visible and needs to be > expicitly enabled/disabled. I think it would be useful in a much > wider range of cases if the trade-offs were understood well enough so > that QEMU can include a threshold or heuristic which chooses the > migration algorithm behind the scenes.
I agree that an automatic switching on/off XBRLE is very desirable. At the first phase we merge it as a user option, and the in the next phase will be adding the part that switch it on/off. > > I'm afraid that locking XBRLE behind an explicit option means we're > merging dead code. What do you think? Even as a user option this option will be useful , in many cases users are aware of their workload and can set this option on. Orit > > Stefan
