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

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-li...) Could qemu-nbd from inside the guest be used? (as a performance/security tradeoff)

> (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?

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