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
Best regards,
--
Edwin Török | Co-founder and Lead Developer
Skylable open-source object storage: reliable, fast, secure
http://www.skylable.com