From mboxrd@z Thu Jan 1 00:00:00 1970 From: Osier Yang Subject: Re: [libvirt] (no subject) Date: Fri, 09 Dec 2011 20:41:49 +0800 Message-ID: <4EE2020D.5080605@redhat.com> References: <1321012626-31713-1-git-send-email-jyang@redhat.com> <20111206143813.GA7937@redhat.com> <1323238866.8489.21.camel@lappy> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "Daniel P. Berrange" , libvir-list@redhat.com, kvm@vger.kernel.org, penberg@cs.helsinki.fi, gorcunov@gmail.com, mingo@elte.hu, asias.hejun@gmail.com To: Sasha Levin Return-path: Received: from mx1.redhat.com ([209.132.183.28]:48222 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752189Ab1LIMmA (ORCPT ); Fri, 9 Dec 2011 07:42:00 -0500 In-Reply-To: <1323238866.8489.21.camel@lappy> Sender: kvm-owner@vger.kernel.org List-ID: On 2011=E5=B9=B412=E6=9C=8807=E6=97=A5 14:21, 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: >>> * Lacks of options for user's configuration, such as "-vnc", the= re >>> is no option for user to configure the properties for the "vnc= ", >>> such as the port. It hides things, doesn't provide ways to que= ry >>> the properties too, this causes problems for libvirt to add th= e >>> vnc support, as vnc clients such as virt-manager, virt-viewer, >>> have no way to connect the guest. Even vncviewer can't. >> >> Being able to specify a VNC port of libvirt's choosing is pretty >> much mandatory to be able to support that.In addition being able >> to specify the bind address is important to be able to control >> security. eg to only bind to 127.0.0.1, or only to certain NICs >> in a multi-NIC host. > > I'll add that feature in the next couple of days. > >> >>> * KVM tool manages the network completely itself (with DHCP supp= ort?), >>> no way to configure, except specify the modes (user|tap|none).= I >>> have not test it yet, but it should need explicit script to se= tup >>> the network rules(e.g. NAT) for the guest access outside world= =2E >>> Anyway, there is no way for libvirt to control the guest netwo= rk. >> >> 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, it > 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 f= d > to the hypervisor? >> >>> * There is a gap about the domain status between KVM tool and li= bvirt, >>> it's caused by KVM tool unlink()s the guest socket when user e= xits >>> from console (both text and graphic), but libvirt still think = the >>> guest is running. >> >> Being able to reliably detect shutdown/exit of the KVM too is >> a very important tasks, and we can't rely on waitpid/SIG_CHLD >> because we want to daemonize all instances wrt libvirtd. >> >> In the QEMU driver we keep open a socket to the monitor, and >> when we see an I/O error / POLLHUP on the socket we know that >> QEMU has quit. >> >> What is this guest socket used for ? Could libvirt keep open a >> connection to it ? > > It's being used for communication with the IPC sub-commands (like 'kv= m > list', 'kvm debug', etc). It's basically the server in a server-clien= t > setup used to signal the hypervisor to do things. > > Theres also no problem with keeping an open connection to it. I'll update the codes to use it. > >> One other option would be to use inotify to watch for deletion >> of the guest socket in the filesystem. This is sortof what we >> do with the UML driver. >> >>> * 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. S= ee >>> "[PATCH] kvm tools.....". As generally we want the state dir o= f >>> a driver can be "/var/run/libvirt/kvmtool/..." for root user o= r >>> "$HOME/.libvirt/kvmtool/run" for non-root user. >> >> What does it do with the state dir ? Is that just for storing the >> guest socket ? > > afaik that patch should be already in as well. > > It does two things in the state dir: > > - Store sockets. > - KVM tools has a feature which lets a user boot a guest based on > virtio-9p which lets him see a system which is an exact copy of the > host. This makes testing of programs and sandboxing very easy. The st= ate > files required for that are stored in that dir as well. > >> >> With QEMU we chose $HOME/.libvirt/qemu or /var/run/libvirt because >> there was no policy set by QEMU itself. If KVM tool has a policy >> for where it stores its state, we should just use that, and not >> try to force it into a libvirt specific location. >> >> In a privileged libvirtd instace, we should aim to still have >> kvmtool itself run as an unprivilegd user / group , eg 'kvmtool:kvmt= ool' >> And we could set the home dir of that user to /var/lib/kvmtool >> >>> * kvmtoolGetVersion is just broken now, as what "./kvm version" = returns >>> is something like "3.0.rc5.873.gb73216", however, libvirt want= s things >>> like "2.6.40.6-0". This might be not a problem as long as KVM = tool >>> has a official package. >> >> The version numbers libvirt reports for hypervisors are pretty >> meaningless really. In that example you give I'd just report '3.0' >> as the version from libvirt. Anything that relies on these versions >> from libvirt is doomed to be broken anyway. > > The version is just a 'git describe' of the kernel tree in which it w= as > built, so if you build KVM tools from an "official" kernel tree* you'= ll > also get pretty versions :) > > * After KVM tools is merged... > >> >>> * console connection is implemented by setup ptys in libvirt, st= dout/stderr >>> of kvm tool process is redirected to the master pty, and libvi= rt 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? >> >> 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? No others except the console. But as we have already implemented the console support using pty in libvirt self. So temporarily wont's use it. > >>> * Not much ways existed yet for external apps or user to query t= he guest >>> informations. But this might be changed soon per KVM tool grow= s 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 of > info out of the balloon driver (including the memory stats VQ - which > afaik we're probably the only ones who actually do that (but I might = be > wrong) :) > > Any other commands are added on-demand. Just let us know what you wan= t > to see there. >