Re: KVM call agenda for Apr 27

[Avi Kivity <avi@redhat.com>]

On 04/27/2010 12:16 PM, Kevin Wolf wrote:
> Am 27.04.2010 10:56, schrieb Avi Kivity:
>    
>> On 04/27/2010 11:48 AM, Dor Laor wrote:
>>      
>>>> Here's another option: an nbd-like protocol that remotes all BlockDriver
>>>> operations except read and write over a unix domain socket. The open
>>>> operation returns an fd (SCM_RIGHTS strikes again) that is used for read
>>>> and write. This can be used to implement snapshots over LVM, for
>>>> example.
>>>>
>>>>          
>>>
>>> Why w/o read/writes?
>>>        
>> To avoid the copying.
>>      
> Hm, stupid question: What problem does this NFS thing solve? What can we
> do with it that we currently can't do inside qemu?
>    

For example, you can't create an lvm snapshot due to privilege problems.

>>> the watermark code needs them too (as info, not the actual buffer).
>>>        
>> Yeah.  It works for lvm snapshots, not for watermarks.
>>      
> So even if it solves anything, it doesn't solve the watermark problem.
> At least I'm not sure how you would use LVM snapshots to dynamically
> grow the volume on which a qcow2 image is stored.
>    

It's separate issue.  Consider a fat-provisioned lvm volume, you can't 
snapshot it today from within qemu.

It doesn't solve the watermark problem (qcow2 on fat-provisioned 
backing), I didn't think it through.

>>> IMHO the whole thing is way over engineered:
>>>   a) Having another channel into qemu is complicating management
>>>      software. Isn't the monitor should be the channel? Otherwise we'll
>>>      need to create another QMP (or nbd like Avi suggest) for these
>>>      actions. It's extra work for mgmt and they will have hard time to
>>>      understand events interleaving of the various channels
>>>        
> I agree. But if everyone insists on overengineering what about allowing
> QMP clients to request an event for any change to a particular query-*
> result? (Or rather a specific field of it, if the watermark is going to
> be a blockstat.) Would need to be supported by the respective
> implementation behind that query subcommand, but we can enable it one
> after another without changes to the interface (except that more
> parameter values start working).
>
> If this is not overengineered enough yet, add a scripting engine to
> allow specifying more complex conditions for event generation, depending
> on multiple fields and so on. :-)
>    

Any simple question has a complicated answer...

-- 
error compiling committee.c: too many arguments to function