[Qemu-devel] Re: KVM call agenda for Apr 27

[Avi Kivity <avi@redhat.com>]

On 04/27/2010 04:03 PM, Anthony Liguori wrote:
> On 04/27/2010 03:14 AM, Avi Kivity wrote:
>> On 04/27/2010 01:36 AM, Anthony Liguori wrote:
>>>
>>> A few comments:
>>>
>>> 1) The problem was not block watermark itself but generating a 
>>> notification on the watermark threshold.  It's a heuristic and 
>>> should be implemented based on polling block stats. 
>>
>> Polling for an event that never happens is bad engineering.  What 
>> frequency do you poll?  you're forcing the user to make a lose-lose 
>> tradeoff.
>>
>>> Otherwise, we'll be adding tons of events to qemu that we'll 
>>> struggle to maintain.
>>
>> That's not a valid reason to reject a user requirement.  We may argue 
>> the requirement is bogus, or that the suggested implementation is 
>> wrong and point in a different direction, but saying that we may have 
>> to add more code in the future due to other requirements is ... well 
>> I can't find a word for it.
>
> Polling is the best solution because it offers the most flexibility.  
> Baking the heuristic into qemu just removes flexibility for all 
> consumers.

Can you explain?  The ability to poll is not removed.  Nor is any 
heuristics performed by qemu; it just sends a notification when a write 
exceeds a user-defined threshold.  The distance from the threshold to 
the top-of-file is not known to qemu.

>
>>>
>>> 2) A block plugin doesn't solve the problem if it's just at the 
>>> BlockDriverState level because it can't interact with qcow2.
>>
>> Why not?  We have a layered model.  guest -> qcow2 -> plugin (sends 
>> event) -> raw-posix.  Just need to insert the plugin at the 
>> appropriate layer.
>
> All of the qcow2 information is static to the qcow2 driver and I don't 
> think changing that for plugins is a good idea.

There is no information that the plugin needs to access:

   if (write_offset > watermark && watermark_enabled) {
       send_notification();
       watermark_enabled = false;
   }
   bdrv_write(backing_blockstate, ..., write_offset, ...);

Note write_offset if not the guest's offset, but the offset into the 
backing file.  It will trigger on guest writes and qcow2 metadata writes 
alike.

>
>>>
>>> 3) For general block plugins, it's probably better to tackle 
>>> userspace block devices.  We have CUSE and FUSE already, a BUSE is a 
>>> logical conclusion.
>>
>> We also have an nbd client.
>>
>> 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.
>
> How does it address the watermark problem?

It doesn't. Mea confusa.

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