From: Osier Yang <jyang@redhat.com>
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
Subject: Re: [libvirt] Add driver support for Native Linux KVM Tool
Date: Fri, 11 Nov 2011 19:30:19 +0800 [thread overview]
Message-ID: <4EBD074B.3060901@redhat.com> (raw)
In-Reply-To: <1321012626-31713-1-git-send-email-jyang@redhat.com>
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
next prev parent reply other threads:[~2011-11-11 11:30 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-11 11:56 [libvirt] (no subject) Osier Yang
2011-11-11 11:30 ` Osier Yang [this message]
2011-11-11 11:56 ` [libvirt] [PATCH 1/7] kvmtool: Add configure support Osier Yang
2011-11-11 11:57 ` [libvirt] [PATCH] kvm tools: Introduce an ENV variable for the state dir Osier Yang
2011-12-06 14:39 ` Daniel P. Berrange
2011-12-09 7:18 ` Osier Yang
2011-11-11 11:57 ` [libvirt] [PATCH 2/7] kvmtool: Add documents Osier Yang
2011-12-06 14:47 ` Daniel P. Berrange
2011-11-11 11:57 ` [libvirt] [PATCH 3/7] kvmtool: Add new enums and error codes for the driver Osier Yang
2011-12-06 14:47 ` Daniel P. Berrange
2011-11-11 11:57 ` [libvirt] [PATCH 4/7] kvmtool: Add hook support for kvmtool domain Osier Yang
2011-12-06 14:48 ` Daniel P. Berrange
2011-11-11 11:57 ` [libvirt] [PATCH 5/7] kvmtool: Add new domain type Osier Yang
2011-12-06 14:46 ` Daniel P. Berrange
2011-12-09 7:22 ` Osier Yang
2011-11-11 11:57 ` [libvirt] [PATCH 6/7] conf: Set source type of the stub console Osier Yang
2011-11-11 11:57 ` [libvirt] [PATCH 7/7] kvmtool: Implementation for kvm tool driver Osier Yang
2011-12-06 14:55 ` Daniel P. Berrange
2011-12-09 7:30 ` Osier Yang
2011-12-06 14:38 ` [libvirt] (no subject) Daniel P. Berrange
2011-12-07 6:21 ` Sasha Levin
2011-12-07 9:16 ` Daniel P. Berrange
2011-12-09 12:45 ` Osier Yang
2011-12-09 12:41 ` Osier Yang
2011-12-09 12:30 ` Osier Yang
2011-12-10 17:56 ` Pekka Enberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EBD074B.3060901@redhat.com \
--to=jyang@redhat.com \
--cc=asias.hejun@gmail.com \
--cc=gorcunov@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=levinsasha928@gmail.com \
--cc=libvir-list@redhat.com \
--cc=mingo@elte.hu \
--cc=penberg@cs.helsinki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.