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 _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
