Hi Jun -
That's the problem - none of this can be done whatsoever with libvirt.
The issue about libvirt is that it is a manager of virtualization programs
running in separate OS processes. Doing the kind of tight interaction with
several qemu instances in one userland process & thread, and full
encapsulation of all the guests' IO into handlers in that app, would
require Enormous amounts of IPC and OS context switching. To the best of my
knowledge, such an approach would mean an approx 1000% speed decrease in
the qemu performance, compared to if it's used as a library as I queried
for in the previous email.
Has anyone implemented a qemu 'library'?
For you who know how this could be done, how much work would it be?
(I suppose the big thing is that qemu not must use pretty much any global
state in it, as the library should deliver the ability for an app to
contain/run several qemu instances at the same time.
The rest of the things (IO encapsulation features) already exist in
some form, they just need to be wrapped to into the form of an API rather
than being in the form of internal device drivers only.)
Thanks,
Mikael
Den 10 april 2012 04:43 skrev Jun Koi <junkoi2...@gmail.com>:
> On Tue, Apr 10, 2012 at 8:09 AM, Mikael <mikael.tr...@gmail.com> wrote:
> > Dear list,
> >
> > I understood that earlier on there was a "libqemu" library, using which
> an
> > ordinary userspace application could allocate a qemu virtual machine and
> get
> > it in a pointer/handle representation, run it as long as it wanted to,
> and
> > intercept any activity from or to it in detail.
> >
> > This is a *great* feature.
> >
> > Does it exist today? In case not, are there plans to introduce it now?
> >
> >
> > I suppose that it's QEMU and not KVM that should be the entry point for
> an
> > app for this purpose, as KVM only is a submodule of QEMU, for
> accelerating
> > part of its activity, correct?
> >
> >
> > The API functionality I'd want is:
> > * Open or close machine
> > * Monitor RAM consumption
> > * Execute machine for specified number of milliseconds, or until the
> > machine somehow marks it's sleeping (does Linux and other OS:es signal
> this
> > somehow?)
> > * Ability to feed machine with network and block device input. Callbacks
> > that receive network output and block device writes/responses from the
> > machine. I suppose this effectively means to implement an own, custom nic
> > and block device driver.
> >
> > Finally, if any callbacks could lead to that the machine execute
> procedure
> > returns (i.e. giving a behavior similar to Unix' select() and read() for
> > picking up new data on sockets), that would be incredibly good. (If
> having
> > several machines, there could be infinite recursion problems if events
> are
> > passed to a callback instead of as a return.)
> >
>
> most of these requirements can be done via libvirt, no?
>
> thanks,
> Jun
>
