On 2011年12月07日 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 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)
Yes, that's what I meant. :-)
libvirt doesn't specifically need any of them, but it can support those
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 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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
