Re: [RFC] Unify KVM kernel-space and user-space code into a single project

[Ingo Molnar <mingo@elte.hu>]

* Richard W.M. Jones <rjones@redhat.com> wrote:

> On Mon, Mar 22, 2010 at 01:05:13PM +0000, Daniel P. Berrange wrote:
> > This is close to the way libguestfs already works. It boots QEMU/KVM pointing
> > to a minimal stripped down appliance linux OS image, containing a small agent
> > it talks to over some form of vmchannel/serial/virtio-serial device. Thus the
> > kernel in the appliance it runs is the only thing that needs to know about the
> > filesystem/lvm/dm on-disk formats - libguestfs definitely does not want to be
> > duplicating this detailed knowledge of on disk format itself. It is doing
> > full read-write access to the guest filesystem in offline mode - one of the
> > major use cases is disaster recovery from a unbootable guest OS image.
> 
> As Dan said, the 'daemon' part is separate and could be run as a standard 
> part of a guest install, talking over vmchannel to the host. The only real 
> issue I can see is adding access control to the daemon (currently it doesn't 
> need it and doesn't do any).  Doing it this way you'd be leveraging the 
> ~250,000 lines of existing libguestfs code, bindings in multiple languages, 
> tools etc.

I think it would be a nice option to allow such guest-side "daemon's" to be 
executed in the guest context without _any_ guest-side support.

This would be possible by building such minimal daemons that use vmchannel, 
and which are built for generic x86 (maybe even built for 32-bit x86 so that 
they can run on any x86 distro). They could execute as the init task of any 
guest kernel - Qemu could 'blend in / replace' the binary as the init task of 
the guest temporarily - and some simple bootstrap code could then start the 
daemon and start the real init binary (and turn off the 'blending' of the init 
task).

That way any guest could be extended via such Qemu functionality - even 
without any kernel changes. Has anyone thought about (or coded) such a 
solution perhaps?

	Ingo