[kata-dev] RFC: direct-assigned filesystem volume proposal

Christophe de Dinechin cdupontd at redhat.com
Fri Apr 9 15:08:04 UTC 2021



> On 8 Apr 2021, at 02:07, Eric Ernst <eric.g.ernst at gmail.com> wrote:
> 
> 
> 
> On Thu, Apr 1, 2021 at 7:58 AM Stefan Hajnoczi <stefanha at redhat.com <mailto:stefanha at redhat.com>> wrote:
> On Mon, Mar 29, 2021 at 04:49:31PM -0700, Eric Ernst wrote:
> > I'd like to see if we can create a pattern in upstream Kata Containers to
> > help facilitate directly assigning volumes to the VM via virtio-blk,
> > skipping any mounts on the host, and avoiding needing to use a shared
> > file-system for the particular volume. Some of the benefits in doing this:
> >  - we can better isolate the host (no mounted filesystem),
> 
> It would be nice to make the mechanism extensible so other types of
> volumes can be attached in the future.
> 
> It might be desirable to perform an NFS mount inside the sandbox VM
> instead of on the host, for example. The downside is that the sandbox VM
> needs access to the storage network, but the host kernel is no longer
> involved.
> 
> Stefan,
> 
> Sorry I missed this initial reply. Can you help with identifying how you think we should augment the DiskMountInfo structure to accomodate? 

At the last arch committee meeting, Peng Tao presented the work they did
CSI and CNI side to expose a port that the runtime can talk to to get device
information.

We will keep discussing about it next week, but I think there are very
interesting options for network-attached storage if we can somehow
make sure we can combine CSI + CNI (I'm not discounting the effort to
translate the network topology from host to guest for such cases, what
Sfefan described as "access to the storage network).

Consider an NFS volume, or iSCSI, or something like that. Now,
let's imagine that we also have some "fast" network e.g. a NIC directly
mapped in the guest, a VF, etc. Then it would make sense to do all
the networking from within the guest e.g. for performance reasons.

But the interaction becomes quite complex in that case:
- CSI has the original storage definition
- The runtime needs to detect that this is a network volume
  (I believe your DiskMountInfo has what we need, not 100% sure)
- CNI will have the information on where to access that network
  (and generally speaking, we know how to expose that in-guest)
- That turns into an in-guest mount, e.g. NFS
- … plus some routing to make sure we can reach that storage

I am not sure this is exactly what Stefan had in mind, but that is what
popped in my own brain when Peng Tao showed up his slides.

That does not directly answer your question. I believe that as you
propose it, we'd have all the information we need, since we have
an FsType (where presumably we could have "nfs") and a volume
type (where we presumably could see "iscsi"). I have not considered
all the combinations, but at first sight, it looks sane as is ;-)


Thanks
Christophe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20210409/07db6843/attachment.html>


More information about the kata-dev mailing list