Re: [Qemu-devel] [PATCH v4] XBZRLE delta for live migration of large memory apps

[Anthony Liguori <anthony@codemonkey.ws>]

On 08/08/2011 08:41 AM, Alexander Graf wrote:
>
> On 08.08.2011, at 15:29, Anthony Liguori wrote:
>
>> One thing that strikes me about this algorithm is that it's very good for a particular type of workload--shockingly good really.
>>
>> I think workload aware migration compression is possible for a lot of different types of workloads.  That makes me a bit wary of QEMU growing quite a lot of compression mechanisms.
>>
>> It makes me think that this logic may really belong at a higher level where more information is known about the workload.  For instance, I can imagine XBZRLE living in something like libvirt.
>>
>> Today, parsing migration traffic is pretty horrible but I think we're pretty strongly committed to fixing that in 1.0.  That makes me wonder if it would be nicer architecturally for a higher level tool to own something like this.
>>
>> Originally, when I added migration, I had the view that we would have transport plugins based on the exec: protocol.  That hasn't really happened since libvirt really owns migration but I think having XBZRLE as a transport plugin for libvirt is something worth considering.
>>
>> I'm curious what people think about this type of approach.  CC'ing libvirt to get their input.
>
> In general, I believe it's a good idea to keep looking at libvirt as a vm management layer and only a vm management layer. Directly working with the migration protocol basically ties us to libvirt if we want to do migration, killing competition in the management stack. Just look at how xm is tied to xen - it's one of the major points I dislike about it :).

The way I originally envisioned things, you'd have:

(qemu) migrate xbzrle://destination?opt1=value1&opt2=value2

Which would in turn be equivalent to:

(qemu) migrate exec:///usr/libexec/qemu/migration-helper-xbzrle 
--opt1=value1 --opt2=value2

But even if we supported that, it wouldn't get exposed via libvirt 
unless the libvirt guys exposed QEMU URIs directly.

So I think the open question is, how do we do transport plugins in a way 
that makes libvirt and QEMU both happy?

Regards,

Anthony Liguori

>
> Alex
>
>