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

[Kevin Wolf]

Am 21.11.2014 um 09:43 hat Francesco Romani geschrieben:
> ----- Original Message -----
> > From: "Kevin Wolf" <address@hidden>
> > To: "Stefan Hajnoczi" <address@hidden>
> > Cc: address@hidden, "Stefan Hajnoczi" <address@hidden>, address@hidden, 
> > address@hidden,
> > "Francesco Romani" <address@hidden>
> > 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

The video recording of that presentation wasn't really good quality,
unfortunately. But you can watch the one of this year's presentation by
Max and myself (you're probably mostly interested in Max's part), the
title was "More Block Device Configuration".

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

I'm afraid that this single wiki page that has a well structured
presentation of all information doesn't exist.

> 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?

No, node-name is assigned at the BlockDriverState (BDS) creation and
can't be changed later on.

> 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).

-drive on the command line can do everything that blockdev-add can do.
So let's assume you have a qcow2 image on a filesystem. Then you end up
with two BDSes, one for the format driver and one for accessing the
filesystem:

    BlockBackend (virtual device) -> qcow2 BDS -> file BDS (raw-posix.c)

For assigning a node name to the qcow2 BDS, you simply specify it in the
obvious way:

    -drive file=test.qcow2,node-name=foo

Now if you want to assign a node name to the file BDS as well, you would
get nested dicts in the blockdev-add call. In -drive a dot syntax is
used to represent this:

    -drive file=test.qcow2,node-name=foo,file.node-name=bar

Are things a bit clearer with this?

Kevin