Re: [Qemu-discuss] [Qemu-devel] Qemu as a library?

[Mikael]

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 <address@hidden>:

On Tue, Apr 10, 2012 at 8:09 AM, Mikael <address@hidden> 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