[Libguestfs] Improving supermin appliance startup time (lkvm/qboot)

[Richard W.M. Jones]

On Wed, Mar 16, 2016 at 07:44:54PM +0200, Török Edwin wrote:
> On 03/15/2016 21:34, Richard W.M. Jones wrote:
> > I was looking at Clear Containers last week.
> > [...]
> > 
> > This is all very good analysis.
> 
> Thanks, looks like I raised the question at a good time :)
> 
> > 
> > The issues that I had in brief were:
> > 
> > (1) We could run kvmtool, perhaps by adding a new backend, but it
> > seems a better idea to add the required features to qemu.  Anything
> > based on kvmtool wouldn't support qcow2 and the myriad other features
> > of qemu (see also:
> > https://rwmj.wordpress.com/2015/11/07/linux-kernel-library-backend-for-libguestfs/)
>
> Could qemu-nbd from inside the guest be used? (as a
> performance/security tradeoff)

There was also a proposed solution for using an [ordinary chroot-
style] container as the libguestfs appliance back in the day.  It
involved qemu-nbd (on the host) plus loopback mounting IIRC.  I don't
think anyone ever explored it in any depth, since it requires root and
as you say isn't secure.

> > (2) On the kernel side, the Intel kernel contains lots of little
> > hacks, and many baremetal CONFIG_* options are disabled.  Hacks can be
> > upstreamed once we massage them into shape.  The real issue is keeping
> > a single baremetal + virt kernel image, since separate kernel images
> > would never fly with Fedora or RHEL.  That means we cannot just
> > disable slow drivers/subsystems by having an alternate kernel with
> > lots of CONFIG_* options disabled, we need to address those problems
> > properly.
> > 
> > (3) DAX / NVDIMM / etc - love them.  Not supported upstream (either
> > kernel or qemu) yet.
> > 
> > (4) Passthrough (eg 9p) filesystems.  You touched on that above.
> > Red Hat doesn't much like 9pfs for several reasons, yet we also don't
> > have a plausible alternative at the moment.  This is mainly a problem
> > for running fast Docker containers, rather than libguestfs though.
>
> Another thought: why does guestfish need to boot the appliance more
> than once?  Could virsh save/restore or managedsave/stop/start be
> used?

This was once proposed too.  It requires a complete change to the way
we build and manage the appliance, and it was unclear if there would
be much benefit.

> The guestfs appliance seems to be around 80MB saved [*] (perhaps ballooning could help shrink this, or it could be compressed with lz4/lzop).
> 
> [*] I copied the XML and changed some things in it, cause the original failed to save with: error: Requested operation is not valid: domain is marked for auto destroy

Rich.

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