Zklei has been out for very very very very long vacation. And he is back to work now. I will push him to finish this in this week. Sry for delay .... BR~ Haomin -----邮件原件----- 发件人: kata-dev-request@lists.katacontainers.io [mailto:kata-dev-request@lists.katacontainers.io] 发送时间: 2019年6月13日 13:24 收件人: kata-dev@lists.katacontainers.io 主题: kata-dev Digest, Vol 19, Issue 11 Send kata-dev mailing list submissions to kata-dev@lists.katacontainers.io To subscribe or unsubscribe via the World Wide Web, visit http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev or, via email, send a message with subject or body 'help' to kata-dev-request@lists.katacontainers.io You can reach the person managing the list at kata-dev-owner@lists.katacontainers.io When replying, please edit your Subject line so it is more specific than "Re: Contents of kata-dev digest..." Today's Topics: 1. Feature: mounting block devices in the guest VM (Ernst, Eric) 2. Re: Dracut initramfs for distro packaging (Marco Vedovati) 3. Re: virtio-fs + VM Templating (Peng Tao) 4. Re: Feature: mounting block devices in the guest VM (=?utf-8?B?d2Vpemhhbmc1NTUuenc=?=) ---------------------------------------------------------------------- Message: 1 Date: Wed, 12 Jun 2019 15:24:12 +0000 From: "Ernst, Eric" <eric.ernst@intel.com> To: "kata-dev@lists.katacontainers.io" <kata-dev@lists.katacontainers.io> Subject: [kata-dev] Feature: mounting block devices in the guest VM Message-ID: <185DA9B2-1E27-4237-B23B-BC53934148C9@intel.com> Content-Type: text/plain; charset="utf-8" Virt-kats – We’ve discussed this a few times, but haven’t been able to land any PRs. See the following (duplicate) issues that highlight feature request: * https://github.com/kata-containers/runtime/issues/571 * https://github.com/kata-containers/runtime/issues/881 Listening to folks using or seeking to use Kata in production, it seems this is a desired use case, and that we should be able to propose enabling as a non-default configurable option. See the following PR in agent/runtime from zklei: * https://github.com/kata-containers/runtime/pull/882 * https://github.com/kata-containers/agent/pull/407 Zklei dropped off face of Kata-earth, and I would like to see if we can: 1. agree upon the feature definition and its addition, and 2. find someone to pick the implementation of this feature up. Feedback? Zhang Wei, anyone at Huawei still working on this feature? Thanks, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20190612/bf4f5dcd/attachment-0001.html> ------------------------------ Message: 2 Date: Wed, 12 Jun 2019 19:06:16 +0200 From: Marco Vedovati <mvedovati@suse.com> To: Jose Carlos Venegas Munoz <jose.carlos.venegas.munoz@intel.com>, Stefan Hajnoczi <stefanha@redhat.com> Cc: kata-dev@lists.katacontainers.io, Paolo Bonzini <pbonzini@redhat.com>, Xu Wang <gnawux@gmail.com>, lsm5@fedoraproject.org Subject: Re: [kata-dev] Dracut initramfs for distro packaging Message-ID: <0fdc40af-d998-c46e-57ea-03a62c7f610a@suse.com> Content-Type: text/plain; charset=utf-8 On 5/7/19 10:38 PM, Jose Carlos Venegas Munoz wrote:

So I think would need more feedback from all the community and also from linux distributions in general so we can have a solution that works better for all.

Hi Jose Carlos, Stefan, I am providing a follow-up, since I also faced packaging problems trying to provide Kata image and kernel packages in openSUSE: - w.r.t. kernel: providing a "third party" kernel package along with the official distro kernels is something not usually possible for various reasons, such as the need to maintain a strict control over how the kernels are built/patched/maintained. - w.r.t. image: lack of standardized/simple ways of generating a image and to provide it inside a package. I've evaluated the use of dracut generated initramfs starting from Stefan PoC, and in the few tests I did it seems a viable solution, keeping in mind that at the moment the main use case would be to provide something that is packaging friendly. With respect to the distro kernels compatibility, the goal would be to reuse a vanilla or a generic kvm kernel that is already provided by the distribution, and have dracut load in the initramfs the kernel modules required by Kata.

Here some question related with dracut usage:

1. Is it possible to build a disk image?

You can build a disk image with DAX using as base the rootfs included in the initramfs.

2. Is it possible to have a custom rootfs with packages I want? Today we require system + agent + iptables + chrony. But also we support not having system but the agent as init. Also, users may want to add additional binaries in the future (to be part of the official image or just for hacking).

Support for agent + iptables + chrony is something that could be provided with a custom dracut modules, or using the dracut overlay (as Stefan PoC). I have spent some time polishing the tests I did, and I've submitted a "RFC" PR to osbuilder to add support for dracut-based initrd / images: https://github.com/kata-containers/osbuilder/pull/312 Hopefully this is a good starting point. Cheers Marco ------------------------------ Message: 3 Date: Thu, 13 Jun 2019 12:59:36 +0800 From: Peng Tao <bergwolf@hyper.sh> To: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: "Castelino, Manohar R" <manohar.r.castelino@intel.com>, "kata-dev@lists.katacontainers.io" <kata-dev@lists.katacontainers.io> Subject: Re: [kata-dev] virtio-fs + VM Templating Message-ID: <CACGKRzXYjxxu=7DKZ09EaOZZ0cT+y1TOi3rS3ZMMfCHEn1mFPA@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" On Thu, Jun 6, 2019 at 1:33 AM Dr. David Alan Gilbert <dgilbert@redhat.com> wrote:

* Castelino, Manohar R (manohar.r.castelino@intel.com) wrote:

...

...

It's very similar to the trick that NEMU uses for templating. With the x-ignore-shared-ram migration capability enabled, migration will not write to the migration stream any RAM block that had the shared=on flag on the qemu commandline. So you should then be able to restart from the migration stream and existing RAM image.

So does it mean we can drop our vm-templating patches and move to using " x-ignore-shared-ram" on QEMU 4.0.

Today we only need two patches, which will come down to a single patch which would bring up closer to upstream QEMU 4.0 which would be ideal. https://github.com/kata-containers/packaging/blob/master/qemu/patche s/4.0.x/0001-9p-removing-coroutines-of-9p-to-increase-the-I-O-per.pa tch https://github.com/kata-containers/packaging/blob/master/qemu/patche s/4.0.x/0002-migration-add-capability-to-bypass-the-shared-memory.pa tch

Yes, I'm hoping that with 4.0 you can avoid 0002 - but I've not tried it; I'd be interested in your results.

Hi Dave, I gave it a try and failed to do vm templating with x-ignore-shared. One key difference between x-ignore-shared and Lai's migrate-bypass-shared patch is that Lai doesn't verify shared memory block upon ram load. OTOH x-ignore-shared rely on ram share property to reconstruct the destination guest memory. In kata, we make use of the fact that destination ram can be private to implement vm templating feature so that multiple new guests can share map the same template VM memory privately (memory-backend-file share=off). The way we implement vm templating in kata is: 1. Start the template VM: qemu-system-x86 -m 2G \ -object memory-backend-file,id=mem0,size=2G,share=on,mem-path=/tmpfs/template-memory \ -numa node,memdev=mem0 2. Stop the template VM, set migration bypass-shared-memory capability, migrate exec:cat>/tmpfs/state, quit it 3. Start target VM: qemu-system-x86 -m 2G \ -object memory-backend-file,id=mem0,size=2G,share=off,mem-path=/tmpfs/template-memory \ -numa node,memdev=mem0 \ -incoming "exec:cat /tmpfs/template-state" 4. Start more target VMs like 3 There are some major differences between above and the example given by x-ignore-shared patchset[1]: 1. on target vm, memory-backend-file is mapped privately (share=off) 2. no migration capability is set on the target vm 3. it is possible to create multiple target VMs based on the same template VM I have made some hacky change to make x-ignore-shared work for vm templating, mostly by reverting the commit "migration: Add capabilities validation" and reconstructing destination VM ram without using migration share capability or ram share property[2]. So I want to ask about your opinion on how to make vm templating work. Shall we change qemu to load ram without the x-ignore-shared capability? Or add another capability to implement similar feature along side x-ignore-shared? [1] https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg04332.html [2] https://github.com/bergwolf/qemu/commits/vm-templating Cheers, Tao -- Into something rich and strange. ------------------------------ Message: 4 Date: Thu, 13 Jun 2019 13:23:56 +0800 From: "=?utf-8?B?d2Vpemhhbmc1NTUuenc=?="<weizhang555.zw@gmail.com> To: "=?utf-8?B?RXJuc3QsIEVyaWM=?="<eric.ernst@intel.com>, " kata-dev@lists.katacontainers. =?utf-8?B?aW8=?="<kata-dev@lists.katacontainers.io> Subject: Re: [kata-dev] Feature: mounting block devices in the guest VM Message-ID: <tencent_7ABFBB4EA1A9F918BA28269E@qq.com> Content-Type: text/plain; charset="utf-8" An HTML attachment was scrubbed... URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20190613/8f3cd37f/attachment.html> ------------------------------ Subject: Digest Footer _______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev ------------------------------ End of kata-dev Digest, Vol 19, Issue 11 ****************************************