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.
--
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
