From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6nNe-0004Ed-NG for qemu-devel@nongnu.org; Tue, 27 Apr 2010 12:11:26 -0400 Received: from [140.186.70.92] (port=56166 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6nNb-00048C-1j for qemu-devel@nongnu.org; Tue, 27 Apr 2010 12:11:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6nNH-00088w-4X for qemu-devel@nongnu.org; Tue, 27 Apr 2010 12:11:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35567) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6nNG-00088n-Ru for qemu-devel@nongnu.org; Tue, 27 Apr 2010 12:11:03 -0400 Date: Tue, 27 Apr 2010 09:11:00 -0700 From: Chris Wright Message-ID: <20100427161100.GG12848@x200.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Qemu-devel] KVM call minutes for Apr 27 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: kvm@vger.kernel.org Cc: qemu-devel@nongnu.org qemu management interface (and libvirt) - qemu standardizing guest enumeration itself - fs w/ QMP sockets in well-known location per guest or qemud for enumeration - QMP C library - QMP for runtime guest mgmt, but not guest launch, storage pools, networking - selinux, cgroups, tc, etc..done in libvirt, not in qemu, need to enable qemu users - libvirt is adding effectively raw QMP interface - would be useful to launch w/ qemu directly and a later manage w/ libvirt - some issues around flexible policy (svirt, cgroups, capabilities, uids) - namespace is esp problematic if libvirtd and qemu don't have same namesapce when libvirt connects later - libvirt needs to support qemu as first class primary usecase - libvirt already focuses on qemu - QMP passthru is stopgap, important features should grow to proper API - libvirt - NetworkManager integration (netcf), possible... - NetworkManager still needs to become aware of bridges, etc - whole mess of options...need to move them out to extensible helper scripts to simplify network setup stable tree policy (push vs. pull and call for stable volunteers) - historically pull based (cherry picking) - doesn't scale wwell - push based...submit patches directly to stable tree - not just add "good for stable" in uptream patch submission - looking for volunteers to manage stable tree - Anthony volunteers!! (ok, not really) block watermark - concensus around polling - other details to be worked out on list - block layer ripe for plugins, good time for collecting requirements and discussion on list