qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: [Qemu-devel] Re: KVM call agenda for Apr 27
Date: Tue, 27 Apr 2010 08:03:42 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

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.


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.


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?

Regards,

Anthony Liguori




reply via email to

[Prev in Thread] Current Thread [Next in Thread]