From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34537) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xrjok-00088v-IU for qemu-devel@nongnu.org; Fri, 21 Nov 2014 03:43:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xrjof-0004pv-IQ for qemu-devel@nongnu.org; Fri, 21 Nov 2014 03:43:50 -0500 Received: from mx3-phx2.redhat.com ([209.132.183.24]:57001) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xrjof-0004pX-AU for qemu-devel@nongnu.org; Fri, 21 Nov 2014 03:43:45 -0500 Date: Fri, 21 Nov 2014 03:43:40 -0500 (EST) From: Francesco Romani Message-ID: <21397425.1869233.1416559420438.JavaMail.zimbra@redhat.com> In-Reply-To: <20141120113428.GB9266@noname.redhat.com> References: <1415365933-3727-1-git-send-email-fromani@redhat.com> <1415365933-3727-2-git-send-email-fromani@redhat.com> <20141117164936.GL16192@stefanha-thinkpad.redhat.com> <20141120103053.GA9266@noname.redhat.com> <20141120110456.GA11224@stefanha-thinkpad.redhat.com> <20141120113428.GB9266@noname.redhat.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1869231_113683423.1416559420436" Subject: Re: [Qemu-devel] [RFC][PATCH v2] block: add write threshold reporting for block devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, Stefan Hajnoczi , mdroth@linux.vnet.ibm.com, Luiz Capitulino , Stefan Hajnoczi ------=_Part_1869231_113683423.1416559420436 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Kevin Wolf" > To: "Stefan Hajnoczi" > Cc: mdroth@linux.vnet.ibm.com, "Stefan Hajnoczi" , lcapitulino@redhat.com, qemu-devel@nongnu.org, > "Francesco Romani" > 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 ------=_Part_1869231_113683423.1416559420436 Content-Type: application/x-shellscript; name=qemu.sh Content-Disposition: attachment; filename=qemu.sh Content-Transfer-Encoding: base64 IyEvYmluL2Jhc2gKClFFTVU9Ii9ob21lL2Zyb21hbmkvTG9jYWwvcWVtdS9iaW4vcWVtdS1rdm0i CgpMQ19BTEw9QyBQQVRIPS91c3IvbG9jYWwvc2JpbjovdXNyL2xvY2FsL2JpbjovdXNyL3NiaW46 L3Vzci9iaW4gUUVNVV9BVURJT19EUlY9c3BpY2UgJFFFTVUgXAoJCS1uYW1lIGZlZG9yYTIwIFwK CQktUyBcCgkJLW1hY2hpbmUgcGMtaTQ0MGZ4LTIuMSxhY2NlbD1rdm0sdXNiPW9mZiBcCgkJLWNw dSBTYW5keUJyaWRnZSBcCgkJLW0gMjA0OCBcCgkJLXJlYWx0aW1lIG1sb2NrPW9mZiBcCgkJLXNt cCAyLHNvY2tldHM9Mixjb3Jlcz0xLHRocmVhZHM9MSBcCgkJLXV1aWQgNDY3YzNiZTMtZTJkMi00 MzM0LTgxYmEtYzAzNzYzM2E4YzZiIFwKCQktbm8tdXNlci1jb25maWcgXAoJCS1ub2RlZmF1bHRz IFwKCQktY2hhcmRldiBzb2NrZXQsaWQ9Y2hhcm1vbml0b3IscGF0aD0vdmFyL3RtcC9mZWRvcmEy MC5tb25pdG9yLHNlcnZlcixub3dhaXQgXAoJCS1tb24gY2hhcmRldj1jaGFybW9uaXRvcixpZD1t b25pdG9yLG1vZGU9Y29udHJvbCBcCgkJLXJ0YyBiYXNlPXV0YyxkcmlmdGZpeD1zbGV3IFwKCQkt Z2xvYmFsIGt2bS1waXQubG9zdF90aWNrX3BvbGljeT1kaXNjYXJkIFwKCQktbm8taHBldCBcCgkJ LW5vLXJlYm9vdCBcCgkJLWdsb2JhbCBQSUlYNF9QTS5kaXNhYmxlX3MzPTEgXAoJCS1nbG9iYWwg UElJWDRfUE0uZGlzYWJsZV9zND0xIFwKCQktYm9vdCBzdHJpY3Q9b24gXAoJCS1kZXZpY2UgaWNo OS11c2ItZWhjaTEsaWQ9dXNiLGJ1cz1wY2kuMCxhZGRyPTB4NS4weDcgXAoJCS1kZXZpY2UgaWNo OS11c2ItdWhjaTEsbWFzdGVyYnVzPXVzYi4wLGZpcnN0cG9ydD0wLGJ1cz1wY2kuMCxtdWx0aWZ1 bmN0aW9uPW9uLGFkZHI9MHg1IFwKCQktZGV2aWNlIGljaDktdXNiLXVoY2kyLG1hc3RlcmJ1cz11 c2IuMCxmaXJzdHBvcnQ9MixidXM9cGNpLjAsYWRkcj0weDUuMHgxIFwKCQktZGV2aWNlIGljaDkt dXNiLXVoY2kzLG1hc3RlcmJ1cz11c2IuMCxmaXJzdHBvcnQ9NCxidXM9cGNpLjAsYWRkcj0weDUu MHgyIFwKCQktZGV2aWNlIHZpcnRpby1zZXJpYWwtcGNpLGlkPXZpcnRpby1zZXJpYWwwLGJ1cz1w Y2kuMCxhZGRyPTB4NiBcCgkJLWRyaXZlIGZpbGU9L3Zhci9saWIvbGlidmlydC9pbWFnZXMvZmVk b3JhMjAucWNvdzIsaWY9bm9uZSxpZD1kcml2ZS12aXJ0aW8tZGlzazAsZm9ybWF0PXFjb3cyIFwK CQktZGV2aWNlIHZpcnRpby1ibGstcGNpLHNjc2k9b2ZmLGJ1cz1wY2kuMCxhZGRyPTB4Nyxkcml2 ZT1kcml2ZS12aXJ0aW8tZGlzazAsaWQ9dmlydGlvLWRpc2swLGJvb3RpbmRleD0yIFwKCQktZHJp dmUgZmlsZT0vdmFyL2xpYi9saWJ2aXJ0L2ltYWdlcy9GZWRvcmEtTGl2ZS1EZXNrdG9wLXg4Nl82 NC0yMC0xLmlzbyxpZj1ub25lLGlkPWRyaXZlLWlkZTAtMC0wLHJlYWRvbmx5PW9uLGZvcm1hdD1y YXcgXAoJCS1kZXZpY2UgaWRlLWNkLGJ1cz1pZGUuMCx1bml0PTAsZHJpdmU9ZHJpdmUtaWRlMC0w LTAsaWQ9aWRlMC0wLTAsYm9vdGluZGV4PTEgXAoJCS1jaGFyZGV2IHB0eSxpZD1jaGFyc2VyaWFs MCBcCgkJLWRldmljZSBpc2Etc2VyaWFsLGNoYXJkZXY9Y2hhcnNlcmlhbDAsaWQ9c2VyaWFsMCBc CgkJLWNoYXJkZXYgc29ja2V0LGlkPWNoYXJjaGFubmVsMCxwYXRoPS92YXIvbGliL2xpYnZpcnQv cWVtdS9jaGFubmVsL3RhcmdldC9mZWRvcmEyMC5vcmcucWVtdS5ndWVzdF9hZ2VudC4wLHNlcnZl cixub3dhaXQgXAoJCS1kZXZpY2UgdmlydHNlcmlhbHBvcnQsYnVzPXZpcnRpby1zZXJpYWwwLjAs bnI9MSxjaGFyZGV2PWNoYXJjaGFubmVsMCxpZD1jaGFubmVsMCxuYW1lPW9yZy5xZW11Lmd1ZXN0 X2FnZW50LjAgXAoJCS1jaGFyZGV2IHNwaWNldm1jLGlkPWNoYXJjaGFubmVsMSxuYW1lPXZkYWdl bnQgXAoJCS1kZXZpY2UgdmlydHNlcmlhbHBvcnQsYnVzPXZpcnRpby1zZXJpYWwwLjAsbnI9Mixj aGFyZGV2PWNoYXJjaGFubmVsMSxpZD1jaGFubmVsMSxuYW1lPWNvbS5yZWRoYXQuc3BpY2UuMCBc CgkJLWRldmljZSB1c2ItdGFibGV0LGlkPWlucHV0MCBcCgkJLWRldmljZSBxeGwtdmdhLGlkPXZp ZGVvMCxyYW1fc2l6ZT02NzEwODg2NCx2cmFtX3NpemU9NjcxMDg4NjQsYnVzPXBjaS4wLGFkZHI9 MHgyIFwKCQktZGV2aWNlIGludGVsLWhkYSxpZD1zb3VuZDAsYnVzPXBjaS4wLGFkZHI9MHg0IFwK CQktZGV2aWNlIGhkYS1kdXBsZXgsaWQ9c291bmQwLWNvZGVjMCxidXM9c291bmQwLjAsY2FkPTAg XAoJCS1jaGFyZGV2IHNwaWNldm1jLGlkPWNoYXJyZWRpcjAsbmFtZT11c2JyZWRpciBcCgkJLWRl dmljZSB1c2ItcmVkaXIsY2hhcmRldj1jaGFycmVkaXIwLGlkPXJlZGlyMCBcCgkJLWNoYXJkZXYg c3BpY2V2bWMsaWQ9Y2hhcnJlZGlyMSxuYW1lPXVzYnJlZGlyIFwKCQktZGV2aWNlIHVzYi1yZWRp cixjaGFyZGV2PWNoYXJyZWRpcjEsaWQ9cmVkaXIxIFwKCQktZGV2aWNlIHZpcnRpby1iYWxsb29u LXBjaSxpZD1iYWxsb29uMCxidXM9cGNpLjAsYWRkcj0weDggXAoJCS1tc2cgdGltZXN0YW1wPW9u Cg== ------=_Part_1869231_113683423.1416559420436--