From mboxrd@z Thu Jan 1 00:00:00 1970 From: Osier Yang Subject: Re: [libvirt] [PATCH 7/7] kvmtool: Implementation for kvm tool driver Date: Fri, 09 Dec 2011 15:30:57 +0800 Message-ID: <4EE1B931.9080809@redhat.com> References: <1321012626-31713-1-git-send-email-jyang@redhat.com> <1321012626-31713-9-git-send-email-jyang@redhat.com> <20111206145538.GG7937@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: libvir-list@redhat.com, kvm@vger.kernel.org, penberg@cs.helsinki.fi, levinsasha928@gmail.com, gorcunov@gmail.com, mingo@elte.hu, asias.hejun@gmail.com To: "Daniel P. Berrange" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:17172 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750871Ab1LIHbI (ORCPT ); Fri, 9 Dec 2011 02:31:08 -0500 In-Reply-To: <20111206145538.GG7937@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2011=E5=B9=B412=E6=9C=8806=E6=97=A5 22:55, Daniel P. Berrange wrote: > On Fri, Nov 11, 2011 at 07:57:06PM +0800, Osier Yang wrote: >> Basically, the drivers is implemented by using kvm tool binary >> currently, (see ./kvm help for more info). >> >> Current implementation supports define/undefine, start/destroy/, >> suspend/resume, connect to guest console via "virsh console", >> and balloon memory with with "virsh setmem" (using ./kvm balloon >> command). Also as it supports cgroup controllers "cpuacct", and >> "memory", so some other commands like "schedinfo", "memtune" can >> also work. Some other commands such as "domid", "domname", "dumpxml" >> ,"autostart", etc. are supported, as the driver is designed >> as a "stateful" driver, those APIs just need to talk with libvirtd >> simply. >> >> As Native Linux KVM Tool is designed for both non-root and root user= s, >> the driver is designed just like QEMU, supports two modes of the >> connection: >> >> kvmtool:///system >> kvmtool+unix:///system >> >> kvmtool:///session >> kvmtool+unix:///session >> >> An example of the domain XML (all the XMLs supported currently are >> listed): >> >> % virsh -c kvm:///system dumpxml kvm_test >> >> kvm_test >> 88bf38f1-b6ab-cfa6-ab53-4b4c0993d894 >> 524288 >> 524288 >> 1 >> >> hvm >> /boot/bzImage >> >> >> >> destroy >> restart >> restart >> >> /usr/bin/kvmtool >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> --- >> cfg.mk | 1 + >> daemon/Makefile.am | 4 + >> daemon/libvirtd.c | 7 + >> po/POTFILES.in | 2 + >> src/Makefile.am | 36 +- >> src/kvmtool/kvmtool_conf.c | 130 ++ >> src/kvmtool/kvmtool_conf.h | 66 + >> src/kvmtool/kvmtool_driver.c | 3079 ++++++++++++++++++++++++++++++= ++++++++++++ >> src/kvmtool/kvmtool_driver.h | 29 + > > My main suggestion here would be to split up the kvmtool_driver.c > file into 3 parts as we did with the QEMU driver. > > kvmtool_driver.c -> Basic libvirt API glue > kvmtool_command.c -> ARGV generation > kvmtool_process.c -> KVMtool process start/stop/autostart/autode= stroy > Agreed. As a early thinking, kvmtool might has APIs exposed in future, how should we plan for it? A new driver just like libxl for XEN? or new backend driver like what we do for xm, xend for XEN driver? Should we consider the expansibility currently if we tend to use backend drivers? Regards, Osier