[libvirt] (no subject)

[Osier Yang]

On 2011年12月07日 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", there
>>>      is no option for user to configure the properties for the "vnc",
>>>      such as the port. It hides things, doesn't provide ways to query
>>>      the properties too, this causes problems for libvirt to add the
>>>      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 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?
>>
>>>    * There is a gap about the domain status between KVM tool and libvirt,
>>>      it's caused by KVM tool unlink()s the guest socket when user exits
>>>      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 'kvm
> list', 'kvm debug', etc). It's basically the server in a server-client
> 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. See
>>>      "[PATCH] kvm tools.....". As generally we want the state dir of
>>>      a driver can be "/var/run/libvirt/kvmtool/..." for root user or
>>>      "$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 state
> 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:kvmtool'
>> 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 wants 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 was
> 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, 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?

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 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) :)
>
> Any other commands are added on-demand. Just let us know what you want
> to see there.
>