[libvirt] (no subject)

[Daniel P. Berrange]

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
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|