Added the known issues to the FAQ section in the README.md

Signed-off-by: Lintong Jiang <lintongj@vmware.com>

README.md

@@ -131,4 +131,16 @@ follow these steps to set a default VolumeSnapshotLocation.
 Your volume data is stored in the Velero bucket with prefixes beginning with *plugins/vsphere-astrolabe-repo*
 Velero versions prior to 1.3.2 will fail when using a bucket that has objects with the *plugins* prefix.  If you have
 multiple Velero instances sharing a common bucket, please be sure to upgrade all of the to 1.3.2 before making any
-backups with the vSphere plugin 
+backups with the vSphere plugin 
+
+## FAQ
+1. The restore would fail if the K8s node VMs are placed in any sub-folders of vSphere VM inventory. 
+    1. Workaround: moving node VMs to the top level of VM inventory. (for users of the release v1.0.0)
+    2. Solution: the issue was resolved post the release v1.0.0 in the master branch at commit 1c3dd7e20c3198e4a94a5a17874d4c474b48c2e2.
+2. The restore might possibly place the restored PVs in a vSphere datastore which is imcompatible with the StorageClass 
+specified in the restored PVC, as we don't rely on the StorageClass for the PV placement on restore in the release v1.0.0. 
+A fix to the PV placement based on the StorageClass can be expected in the next release.
+3. To use the plugin v1.0.0 in a TKG cluster, the secret of vSphere CSI credential, i.e., csi-vsphere-config, need to be renamed
+to, vsphere-config-secret. Since for the release v1.0.0, the configuration in Vanilla k8s setup was used as a reference
+and the logic about retrieving VC credential is hardcoded to retrive the vSphere CSI credential, vsphere-config-secret,
+in the `kube-system` namespace. A fix can be expected in the next release.