A vDiscovery job retrieves information about virtual entities in cloud environments that are managed through a cloud management platform, (CMP) such as GCP. The current vDiscovery feature supports tenants, networks, and compute VMs only. It does not support data that is retrieved from load balancer networks, load balancer VMs, Kubernetes platform VMs, application gateways, service VMs, SQL VMs, or any other VMs that are created by cloud services, such as Kubernetes service or analytics service, where the IPAM is handled by the respective orchestration engines of the cloud provider.
| Note |
|---|
NoteYou can use the values that appear by default or extend the values as per your requirements. Using less than the recommended resources can cause a reduction in performance. |
...
Infoblox vDiscovery for GCP does not support the discovery of load balancers.
When a VM in GCP uses the custom hostname option, the VM name and the VM hostname fields are different. The vDiscovery for GCP uses only the VM name for the managed VM and ignores the VM hostname.
If you change the name of a VM in GCP, the hardware ID also changes. Therefore, if your vNIOS for GCP license is associated with the earlier hardware ID, changing the VM name may result in a license error.
When running vDiscovery across multiple projects, the user you must create one vDiscovery job per GCP project. vDiscovery across multiple GCP projects through a single vDiscovery job is not supported.
When you create an instance using a snapshot on GCP and then run vDiscovery, the OS field in the IPAM tab will be blank.
Running vDiscovery to discover virtual entities in a service project does not discover the VM if the network interface of the VM is using the Shared shared VPC subnet of its host project.