virtiofs: Update virtiofs docs

Update this document to get rid of any nemu mentions.
Added comment to mention that number of containers that can be
launched may be limited by the size of `/dev/shm`.

Fixes #674

Signed-off-by: Archana Shinde <[email protected]>

Author: amshinde

how-to/how-to-use-virtio-fs-with-kata.md

@@ -13,39 +13,49 @@ As of the 1.7 release of Kata Containers, [9pfs](https://www.kernel.org/doc/Docu
 
 To help address these limitations, [virtio-fs](https://virtio-fs.gitlab.io/) has been developed. virtio-fs is a shared file system that lets virtual machines access a directory tree on the host. In Kata Containers, virtio-fs can be used to share container volumes, secrets, config-maps, configuration files (hostname, hosts, `resolv.conf`) and the container rootfs on the host with the guest.  virtio-fs provides significant performance and POSIX compliance improvements compared to 9pfs.
 
-Enabling of virtio-fs requires changes in the guest kernel as well as the VMM. For Kata Containers, experimental virtio-fs support is enabled through the [NEMU VMM](https://github.com/intel/nemu).
+Enabling of virtio-fs requires changes in the guest kernel as well as the VMM. For Kata Containers, experimental virtio-fs support is enabled through `qemu` and `cloud-hypervisor` VMMs.
 
 **Note: virtio-fs support is experimental in the 1.7 release of Kata Containers. Work is underway to improve stability, performance and upstream integration. This is available for early preview - use at your own risk**
 
 This document describes how to get Kata Containers to work with virtio-fs.
 
 ## Pre-requisites
 
-* Before Kata 1.8 this feature required the host to have hugepages support enabled. Enable this with the `sysctl vm.nr_hugepages=1024` command on the host.
+Before Kata 1.8 this feature required the host to have hugepages support enabled. Enable this with the `sysctl vm.nr_hugepages=1024` command on the host.In later versions of Kata, virtio-fs leverages `/dev/shm` as the shared memory backend. The default size of `/dev/shm` on a system is typically half of the total system memory. This can pose a physical limit to the maximum number of pods that can be launched with virtio-fs. This can be overcome by increasing the size of `/dev/shm` as shown below:
 
+```bash
+$ mount -o remount,size=${desired_shm_size} /dev/shm
+```
+ 
 ## Install Kata Containers with virtio-fs support
 
-The Kata Containers NEMU configuration, the NEMU VMM and the `virtiofs` daemon are available in the [Kata Container release](https://github.com/kata-containers/runtime/releases) artifacts starting with the 1.7 release. While the feature is experimental, distribution packages are not supported, but installation is available through [`kata-deploy`](https://github.com/kata-containers/packaging/tree/master/kata-deploy).
+The Kata Containers `qemu` configuration with virtio-fs and the `virtiofs` daemon are available in the [Kata Container release](https://github.com/kata-containers/runtime/releases) artifacts starting with the 1.9 release. Installation is available through [distribution packages](https://github.com/kata-containers/documentation/blob/master/install/README.md#supported-distributions) as well through [`kata-deploy`](https://github.com/kata-containers/packaging/tree/master/kata-deploy).
 
-Install the latest release of Kata as follows:
+**Note: Support for virtio-fs was first introduced in `NEMU` hypervisor in Kata 1.8 release. This hypervisor has been deprecated.**
+
+Install the latest release of Kata with `kata-deploy` as follows:
 ```
 docker run --runtime=runc -v /opt/kata:/opt/kata -v /var/run/dbus:/var/run/dbus -v /run/systemd:/run/systemd -v /etc/docker:/etc/docker -it katadocker/kata-deploy kata-deploy-docker install
 ```
 
-This will place the Kata release artifacts in `/opt/kata`, and update Docker's configuration to include a runtime target, `kata-nemu`. Learn more about `kata-deploy` and how to use `kata-deploy` in Kubernetes [here](https://github.com/kata-containers/packaging/tree/master/kata-deploy#kubernetes-quick-start).
-
+This will place the Kata release artifacts in `/opt/kata`, and update Docker's configuration to include a runtime target, `kata-qemu-virtiofs`. Learn more about `kata-deploy` and how to use `kata-deploy` in Kubernetes [here](https://github.com/kata-containers/packaging/tree/master/kata-deploy#kubernetes-quick-start).
 
 ## Run a Kata Container utilizing virtio-fs
 
-Once installed, start a new container, utilizing NEMU + `virtiofs`:
+Once installed, start a new container, utilizing `qemu` + `virtiofs`:
 ```bash
-$ docker run --runtime=kata-nemu -it busybox
+$ docker run --runtime=kata-qemu-virtiofs -it busybox
 ```
 
-Verify the new container is running with the NEMU hypervisor as well as using `virtiofsd`. To do this look for the hypervisor path and the `virtiofs` daemon process on the host:
+Verify the new container is running with the `qemu` hypervisor as well as using `virtiofsd`. To do this look for the hypervisor path and the `virtiofs` daemon process on the host:
 ```bash
 $ ps -aux | grep virtiofs
 root ... /home/foo/build-x86_64_virt/x86_64_virt-softmmu/qemu-system-x86_64_virt
 ...  -machine virt,accel=kvm,kernel_irqchip,nvdimm ...
 root ... /home/foo/build-x86_64_virt/virtiofsd-x86_64 ...
 ```
+
+You can also try out virtio-fs using `cloud-hypervisor` VMM:
+```bash
+$ docker run --runtime=kata-clh -it busybox
+```