[libvirt] libguestfs integration: rich disk access for libvirt applications

[Richard W.M. Jones]

On Wed, Sep 28, 2011 at 06:37:17PM +0100, Daniel P. Berrange wrote:
> On Wed, Sep 28, 2011 at 11:14:57AM +0100, Stefan Hajnoczi wrote:
> > On Tue, Sep 27, 2011 at 12:55 PM, Richard W.M. Jones <rjones at redhat.com> wrote:
> > > To put this all into one place:
> > >
> > > (1) An ugly new libvirt API that runs febootstrap-supermin-helper to
> > > create the appliance.
> > [...]
> > > I'm worried about item (1) in this list ...
> > 
> > This is the only instance where libvirt knows about libguestfs.  All
> > other steps are libguest only or involve libguestfs knowing about
> > libvirt.
> > 
> > Would it be possible introduce a "domain-builder" concept into
> > libvirt?  When libguestfs is installed it drops a domain-builder
> > configuration/script that libvirt can pick up.  Then you can say
> > something like virDomainBuild(name="guestfs-appliance",
> > builder="guestfs").
> 
> We do have a historical syntax from Xen paravirt which lets us call out
> to a helper at boot time, namely the "<bootloader>" element. With Xen
> this is typically something like pygrub, or pxegrub, which does some
> work and writes out a kernel+initrd into temporary files, and prints
> the file paths + any kernel args on stdout.
> 
> We could just wire up this concept in KVM too without any real trouble,
> and then we could have guestfs-bootloader script todo the magic setup

I'm fine with this.

Are there security implications to allowing users to add <bootloader>
clauses pointing at random scripts that get run on remote machines as
different users?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top