From mboxrd@z Thu Jan 1 00:00:00 1970 From: Osier Yang Subject: Re: [libvirt] (no subject) Date: Fri, 09 Dec 2011 20:45:30 +0800 Message-ID: <4EE202EA.5070300@redhat.com> References: <1321012626-31713-1-git-send-email-jyang@redhat.com> <20111206143813.GA7937@redhat.com> <1323238866.8489.21.camel@lappy> <20111207091627.GB9888@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Sasha Levin , libvir-list@redhat.com, kvm@vger.kernel.org, penberg@cs.helsinki.fi, 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]:33797 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752189Ab1LIMpk (ORCPT ); Fri, 9 Dec 2011 07:45:40 -0500 In-Reply-To: <20111207091627.GB9888@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2011=E5=B9=B412=E6=9C=8807=E6=97=A5 17:16, Daniel P. Berrange wrote: > On Wed, Dec 07, 2011 at 08:21:06AM +0200, Sasha Levin wrote: >> On Tue, 2011-12-06 at 14:38 +0000, Daniel P. Berrange wrote: >>> On Fri, Nov 11, 2011 at 07:56:58PM +0800, Osier Yang wrote: >>>> * KVM tool manages the network completely itself (with DHCP sup= port?), >>>> no way to configure, except specify the modes (user|tap|none)= =2E I >>>> have not test it yet, but it should need explicit script to s= etup >>>> the network rules(e.g. NAT) for the guest access outside worl= d. >>>> Anyway, there is no way for libvirt to control the guest netw= ork. >>> >>> If KVM tool support TAP devices, can't be do whatever we like with >>> that just by passing in a configured TAP device from libvir ? >> >> KVM tool currently creates and configures the TAP devices it uses, i= t >> shouldn't be an issue to have it use a TAP fd passed to it either. >> >> How does libvirt do it? Create a /dev/tapX on it's own and pass the = fd >> to the hypervisor? > > Yes, libvirt opens a /dev/tap device (or a macvtap device for VEPA > mode), adds it to the neccessary bridge, and/or configures VEPA, etc > and then passes the FD to the hypervisor, with a ARGV parameter to > tell the HV which FD is being passed. > >>>> * console connection is implemented by setup ptys in libvirt, s= tdout/stderr >>>> of kvm tool process is redirected to the master pty, and libv= irt connects >>>> to the slave pty. This works fine now, but it might be better= if kvm >>>> tool could provide more advanced console mechanisms. Just lik= e QEMU >>>> does? >>> >>> This sounds good enough for now. >> >> KVM tools does a redirection to a PTY, which at that point could be >> redirected to anywhere the user wants. >> >> What features might be interesting to do on top of that? > > I presume that Osier is just comparing with the features QEMU has ava= ilable > for chardevs config, which include > > - PTYs > - UNIX sockets > - TCP sockets > - UDP sockets > - FIFO pipe > - Plain file (output only obviously, but useful for logging) Yes, that's what I meant. :-) > > libvirt doesn't specifically need any of them, but it can support tho= se > options if they exist. Yes, these won't prevent us, I just meant it will be great if they are supported. > >>>> * Not much ways existed yet for external apps or user to query = the guest >>>> informations. But this might be changed soon per KVM tool gro= ws up >>>> quickly. >>> >>> What sort of guest info are you thinking about ? The most immediate >>> pieces of info I can imagine we need are >>> >>> - Mapping between PIDs and vCPU threads >>> - Current balloon driver value >> >> Those are pretty easily added using the IPC interface I've mentioned >> above. For example, 'kvm balloon' and 'kvm stat' will return a lot o= f >> info out of the balloon driver (including the memory stats VQ - whic= h >> afaik we're probably the only ones who actually do that (but I might= be >> wrong) :) > > Ok, that sounds sufficient for the balloon info. > > Regards, > Daniel