Open Stack

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 at lists.katacontainers.io [mailto:kata-dev-request at lists.katacontainers.io] 
发送时间: 2019年6月13日 13:24
收件人: kata-dev at lists.katacontainers.io
主题: kata-dev Digest, Vol 19, Issue 11

Send kata-dev mailing list submissions to
	kata-dev at 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 at lists.katacontainers.io

You can reach the person managing the list at
	kata-dev-owner at 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 at intel.com>
To: "kata-dev at lists.katacontainers.io"
	<kata-dev at lists.katacontainers.io>
Subject: [kata-dev] Feature: mounting block devices in the guest VM
Message-ID: <185DA9B2-1E27-4237-B23B-BC53934148C9 at 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 at suse.com>
To: Jose Carlos Venegas Munoz <jose.carlos.venegas.munoz at intel.com>,
	Stefan Hajnoczi <stefanha at redhat.com>
Cc: kata-dev at lists.katacontainers.io, Paolo Bonzini
	<pbonzini at redhat.com>, Xu Wang <gnawux at gmail.com>,
	lsm5 at fedoraproject.org
Subject: Re: [kata-dev] Dracut initramfs for distro packaging
Message-ID: <0fdc40af-d998-c46e-57ea-03a62c7f610a at 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 at hyper.sh>
To: "Dr. David Alan Gilbert" <dgilbert at redhat.com>
Cc: "Castelino, Manohar R" <manohar.r.castelino at intel.com>,
	"kata-dev at lists.katacontainers.io" <kata-dev at lists.katacontainers.io>
Subject: Re: [kata-dev] virtio-fs + VM Templating
Message-ID:
	<CACGKRzXYjxxu=7DKZ09EaOZZ0cT+y1TOi3rS3ZMMfCHEn1mFPA at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

On Thu, Jun 6, 2019 at 1:33 AM Dr. David Alan Gilbert <dgilbert at redhat.com> wrote:
>
> * Castelino, Manohar R (manohar.r.castelino at 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 at gmail.com>
To: "=?utf-8?B?RXJuc3QsIEVyaWM=?="<eric.ernst at intel.com>, "
	kata-dev at lists.katacontainers.
	=?utf-8?B?aW8=?="<kata-dev at lists.katacontainers.io>
Subject: Re: [kata-dev] Feature: mounting block devices in the guest
	VM
Message-ID: <tencent_7ABFBB4EA1A9F918BA28269E at 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 at lists.katacontainers.io
http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev


------------------------------

End of kata-dev Digest, Vol 19, Issue 11
****************************************