From mboxrd@z Thu Jan 1 00:00:00 1970 From: Osier Yang Subject: Re: [libvirt] Add driver support for Native Linux KVM Tool Date: Fri, 11 Nov 2011 19:30:19 +0800 Message-ID: <4EBD074B.3060901@redhat.com> References: <1321012626-31713-1-git-send-email-jyang@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: 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 Return-path: Received: from mx1.redhat.com ([209.132.183.28]:6812 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756625Ab1KKLay (ORCPT ); Fri, 11 Nov 2011 06:30:54 -0500 In-Reply-To: <1321012626-31713-1-git-send-email-jyang@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Sorry, I missed the title. :( Osier On 11/11/2011 07:56 PM, Osier Yang wrote: > Hi, all > > This is a basic implementation of libvirt Native Linux KVM > Tool driver. Note that this is just made with my own interest > and spare time, it's not an endorsement/effort by Red Hat, > and it isn't supported by Red Hat officially. > > Basically, the driver is designed as *stateful*, as KVM tool > doesn't maintain any info about the guest except a socket which > for its own IPC. And it's implemented by using KVM tool binary, > which is name "kvm" currently, along with cgroup controllers > "cpuacct", and "memory" support. And as one of KVM tool's > pricinple is to allow both the non-root and root user to play with. > The driver is designed to support root and non-root too, just > like QEMU does. Example of the connection URI: > > virsh -c kvmtool:///system > virsh -c kvmtool:///session > virsh -c kvmtool+unix:///system > virsh -c kvmtool+unix:///session > > The implementation can support more or less than 15 virsh commands > currently, including basic domain cycle operations (define/undefine, > start/destroy, suspend/resume, console, setmem, schedinfo, dumpxml, > ,autostart, dominfo, etc.) > > About the domain configuration: > * "kernel": must be specified as KVM tool only support boots > from the kernel currently (no integration with BIOS app yet). > > * "disk": only virtio bus is supported, and device type must be 'disk'. > > * "serial/console": only one console is supported, of type serial or > virtio (can extend to support multiple console as long as kvm tool > supports, libvirt already supported mutiple console, see upstream > commit 0873b688c). > > * "p9fs": only support specifying the source dir, and mount tag, only > type of 'mount' is supported. > > * "memballoon": only virtio is supported, and there is no way > to config the addr. > > * Multiple "disk" and "p9fs" is supported. > > * Graphics and network are not supported, will explain below. > > Please see "[PATCH 7/8]" for an example of the domain config. (which > contains all the XMLs supported by current implementation). > > The problems of Native Linux KVM Tool from libvirt p.o.v: > > * Some destros package "qemu-kvm" as "kvm", also "kvm" is a long > established name for "KVM" itself, so naming the project as > "kvm" might be not a good idea. I assume it will be named > as "kvmtool" in this implementation, never mind this if you > don't like that, it can be updated easily. :-) > > * It still doesn't have an official package yet, even no "make install". > means we have no way to check the dependancy and do the checking > when 'configure'. I assume it will be installed as "/usr/bin/kvmtool" > in this implementation. This is the main reason which can prevents > upstream libvirt accepting the patches I guess. > > * Lacks of options for user's configuration, such as "-vnc", there > is no option for user to configure the properties for the "vnc", > such as the port. It hides things, doesn't provide ways to query > the properties too, this causes problems for libvirt to add the > vnc support, as vnc clients such as virt-manager, virt-viewer, > have no way to connect the guest. Even vncviewer can't. > > * KVM tool manages the network completely itself (with DHCP support?), > no way to configure, except specify the modes (user|tap|none). I > have not test it yet, but it should need explicit script to setup > the network rules(e.g. NAT) for the guest access outside world. > Anyway, there is no way for libvirt to control the guest network. > > * There is a gap about the domain status between KVM tool and libvirt, > it's caused by KVM tool unlink()s the guest socket when user exits > from console (both text and graphic), but libvirt still think the > guest is running. > > * KVM tool uses $HOME/.kvm_tool as the state dir, and no way to configure, > I made a small patch to allow KVM tool accept a ENV variable, > which is "KVM_STATE_DIR", it's used across the driver. I made a > simple patch against kvm tool to let the whole patches work. See > "[PATCH] kvm tools.....". As generally we want the state dir of > a driver can be "/var/run/libvirt/kvmtool/..." for root user or > "$HOME/.libvirt/kvmtool/run" for non-root user. > > * kvmtoolGetVersion is just broken now, as what "./kvm version" returns > is something like "3.0.rc5.873.gb73216", however, libvirt wants things > like "2.6.40.6-0". This might be not a problem as long as KVM tool > has a official package. > > * console connection is implemented by setup ptys in libvirt, stdout/stderr > of kvm tool process is redirected to the master pty, and libvirt connects > to the slave pty. This works fine now, but it might be better if kvm > tool could provide more advanced console mechanisms. Just like QEMU > does? > > * Not much ways existed yet for external apps or user to query the guest > informations. But this might be changed soon per KVM tool grows up > quickly. > > * It will be quite desireable if kvm tool could report the capabilities, > of which is lacked by QEMU forever (seems so), it causes much pain for > upper layer mgmt apps. See the RFC by Daniel Berrange in QEMU list > for more details: > > http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg00921.html > > As a conclusion, it seems to me that KVM tool dosesn't consider too much > about the interface for upper layer management tools, (generally, upper > layer apps will want good interface to set/get), which might be no good > for KVM tool future development. > > Thoughts, and opinions? Thanks. > > [PATCH 1/7] kvmtool: Add configure support > [PATCH] kvm tools: Introduce an ENV variable for the state dir > [PATCH 2/7] kvmtool: Add documents > [PATCH 3/7] kvmtool: Add new enums and error codes for the driver > [PATCH 4/7] kvmtool: Add hook support for kvmtool domain > [PATCH 5/7] kvmtool: Add new domain type > [PATCH 6/7] conf: Set source type of the stub console > [PATCH 7/7] kvmtool: Implementation for kvm tool driver > > Regards, > Osier > > -- > libvir-list mailing list > libvir-list@redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list