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