Re: [Qemu-devel] [RFC][PATCH v2] block: add write threshold reporting for block devices

[Francesco Romani <fromani@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3716 bytes --]

----- Original Message -----
> From: "Kevin Wolf" <kwolf@redhat.com>
> To: "Stefan Hajnoczi" <stefanha@redhat.com>
> Cc: mdroth@linux.vnet.ibm.com, "Stefan Hajnoczi" <stefanha@gmail.com>, lcapitulino@redhat.com, qemu-devel@nongnu.org,
> "Francesco Romani" <fromani@redhat.com>
> Sent: Thursday, November 20, 2014 12:34:28 PM
> Subject: Re: [Qemu-devel] [RFC][PATCH v2] block: add write threshold reporting for block devices

> > > > One way to solve this is to require that the management tool tells QEMU
> > > > which exact BlockDriverState node the threshold applies to.  Then QEMU
> > > > doesn't need any hardcoded policy.  But I'm not sure how realistic that
> > > > it at the moment (whether management tools are uses node names for each
> > > > node yet), so it may be best to hardcode the bs->file traversal that
> > > > I've suggested.
> > > > 
> > > > Kevin: Do you agree?
> > > 
> > > I have a feeling that we would regret this in the long run because it
> > > would allow only one special case of a general problem (watching a BDS).
> > > This means that we'll get inconsistent APIs.
> > > 
> > > We're "only" talking about an optimisation here, even though a very
> > > useful one, so I wouldn't easily make compromises here. We should
> > > probably insist on using the node-name. Management tools need new code
> > > anyway to make use of the new functionality, so they can implement
> > > node-name support as well while they're at it.
> > 
> > Using node-name is the best thing to do.
> > 
> > My concern is just whether libvirt and other management tools are
> > actually using node-name yet.
> 
> I don't think so. They also don't use blockdev-add yet.
> 
> But that's not a reason for us to add hacks that allow libvirt and other
> management tools to avoid the proper APIs even in the future. They just
> need to add support for node-names if they want to use new qemu features.
> New features require support for new infrastructure, I think that's fair.
> 
> If they feel that representing complete BDS graphs in their code is too
> much work for now, they can still keep temporary hacks with hardcoded
> assumptions in their management code (like setting file.node-name and
> ignoring other setups). At least it would be temporary hacks there; if
> we did them in qemu, they would be a permanent API.

I'm fine to use node_name in my patch, it looks even much simpler and cleaner

I'd love to take this chance and learn more about the topic, becuse
I'm very near to the border of my knowledge in that area.
I joined the discussion quite later, so my sources are actually
pretty sparse. Mostly:
- staring at the sources and git history
- googling for specific bits
- presentations like http://www.linux-kvm.org/wiki/images/3/34/Kvm-forum-2013-block-dev-configuration.pdf

There are some sources I'm missing? Hopefully a nice wiki page I somehow lost :)

A couple of specific questions more, mostly to make sure I can do meaningful
tests for my next submission:

1. I'm running a simple test using the attached script -
which is a qemu command line adapted from libvirt ouput driven
by oVirt. There is a way to attach a name at this stage, using a QMP command?

2. (related to the former) it seems from a not-so-deep look that the blessed (only?)
way to set a proper node_name is using blockdev-add.
If so, I'm not sure I follow how the qemu boot flow would look like.
It will not be anymore as simple as crafting a command line and run the qemu, right?
IIUC some interaction with QMP will be needed (sorry for asking silly question,
trying to fill gaps in my knowledge).

Thanks for the great feedback!


-- 
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani

[-- Attachment #2: qemu.sh --]
[-- Type: application/x-shellscript, Size: 2509 bytes --]