Re: [libvirt] (no subject)

[Osier Yang <jyang@redhat.com>]

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