Re: [libvirt] (no subject)

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 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. >> >> 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 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, 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? >> >> 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 available for chardevs config, which include - PTYs - UNIX sockets - TCP sockets - UDP sockets - FIFO pipe - Plain file (output only obviously, but useful for logging)

libvirt doesn't specifically need any of them, but it can support those options if they exist.

>>> * 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. >> >> 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) :) Ok, that sounds sufficient for the balloon info. Regards, Daniel