docs: FS PV updated

Signed-off-by: Fabian Deutsch <[email protected]>

docs/filesystem-pv-disks.md

@@ -35,14 +35,11 @@ virtual disks.
 
 Currently KubeVirt only supports [direct PV disks](direct-pv-disks.md).
 This feature works, by assigning PVCs backed by network block storage (currently
-only iSCSI) to a VM. The connection details of the PVC are then leveraged with
-qemu's built-in network storage drivers, to directly connect qemu to the remote
-storage. This effectively bypasses all other Kubernetes or KubeVirt components,
-and establishes a direct connection between qemu and the storage backend.
+only iSCSI) to a VM.
 
-The mechanism proposed in proposal however is leveraging Kubernetes to attach
-the remote storage as a file-system to a pod, to use this file-system to storage
-disk images which are acting as a backend storage to the VM.
+The mechanism proposed in this proposal is leveraging Kubernetes to attach
+the remote storage as a file-system to a container, to use this file-system to
+store a disk image to act as a backend storage to the VM's disk.
 
 To keep the story compatability between the block and file-system storage, this
 proposal assumes that the file-system based storage will also just support a 1:1
@@ -69,31 +66,30 @@ spec:
   domain:
     devices:
       disks:
-      - type: PersistentVolumeClaim
-        source:
-          name: vm-01-disk
-        target:
-          bus: scsi
-          device: sda
+      - name: root-disk
+        volumeName: my-fs-store
+  volumes:
+  - name: my-fs-store
+    persistentVolumeClaim: my-fs-claim
 ```
 
-Here the user attaches the PersistentVolumeClaim _vm-01-disk_ to a VM, the
-assumption is that the _vm-01-disk_ volume is a file-system based volume.
+Here the user attaches the PersistentVolumeClaim `my-fs-claim` as a disk to a
+VM.
 
 
 ### Storage Type Inference
 
 The system needs to know if the referenced volume needs to be treated as a
-block or file-system volume. This information can be infered from the existing
-PV metadata.
+block or file-system volume.
+This information can be infered from the existing PV metadata.
 
 
 ## Implementation
 
 ### Volume layout
 
-A file-system based volume will contain the image file only, this file must be
-named `disk.img`.
+A file-system based volume will contain only a single image file, this file
+must be named `disk.img`.
 The format of the file must be `raw`.
 
 The file-system layout of a mounted volume then looks like:
@@ -102,25 +98,8 @@ The file-system layout of a mounted volume then looks like:
 /disk.img
 ```
 
-### Mounting & sharing
-
-The file-system volume needs to be associated with the launcher container of
-the VM pod, and is thus mounted in the VMs pod launcher mount namespace.
-
-As the qemu proccesses run in the libvirt's mount namespace, the volume mount
-namespace has to be shared with libvirt.
-
-To achieve this, libvrit needs to gain access to the `/var/lib/kubelet/pods`
-path in the `kubelet`'s mount namespace.
-This path contains all volume mounts of all containers.
-
-The handler can craft the (relative) path to a volume, by taking the pod's UUID
-and volume informations. This path is then passed to libvirt, which in turn uses
-it in a disk definition.
-
-FIXME define the EXACT way of how to craft the path. 
-Path is defined here:
-https://github.com/kubernetes/kubernetes/blob/master/pkg/volume/util/operationexecutor/operation_executor.go#L394
+In future we might want to add additional files to carry metadata, but the limit
+of a single image file per volume must not be changed.
 
 
 ## Additional Notes
@@ -134,7 +113,7 @@ raw block storage support, i.e.:
 ```yaml
       - type: PersistentVolumeClaim
         driver:
-          name: qemu
+          name: qemu-built-in
         source:
           name: vm-01-disks
 ---
@@ -161,10 +140,3 @@ virtual machines.
 This API design should not contradict with this use-case, but it will probably
 depend on the `driver` field mentioned above to signal the system how the PV has
 to beconsumed (mounted).
-
-### `VMConfig` level feature based usage
-
-It might be of value to users to only specify a PV, and not care about the file
-to be used for a disk. We can add such logic, but this should probably reside on
-the `VMConcifg` level. The `VM` API should focus to provide the mechanics to
-support this more opinionated approach.