--- title: "Limitations of vNIOS for Google Cloud" canonical: "https://docs.infoblox.com/space/vniosgcp/1574273039/Limitations%20of%20vNIOS%20for%20Google%20Cloud" format: markdown --- Consider the limitations listed in this topic when deploying vNIOS for Google Cloud. > Macro (toc) # Common Limitations - vNIOS for Google Cloud instances do not support DNS Infrastructure Protection. - vNIOS for Google Cloud instances do not the support LAN2 interface. If you have configured the LAN2 interface on an instance, it might still function as expected. However, this is not supported because Infoblox has not qualified LAN2 on public cloud instances. Additionally, as NIOS supports high availability configurations from version 9.0.4, it treats the third interface as HA by default. Therefore, if you have configured a LAN2 interface, NIOS will treat it as an HA interface, causing errors and unexpected behavior. - vNIOS instances deployed on Google Cloud provide DHCP services for on-premises networks only. They do not serve DHCP for networks deployed on any platform. - Avoid interchanging network interfaces on a vNIOS instance as it can result in unexpected behavior. - If you change the name of a VM in Google Cloud, the hardware ID also changes. Therefore, if your vNIOS for Google Cloud license is associated with the earlier hardware ID, changing the VM name may result in a license error. - vNIOS for Google Cloud does not support IPv6 (single stack) network interfaces. You can create instances with IPv4 (single stack) or IPv4 and IPv6 (dual stack) network interfaces. - vNIOS for Google Cloud does not support IPv6 addresses on MGMT interfaces because the IPv6 gateway is a unique local address (ULA). # Limitations Specific to HA Limitations related to high availability (HA) configuration, a capability introduced in NIOS 9.0.4: - vNIOS for Google Cloud instances do not support HA configuration on the instance type n1-highmem-2 that is used in IB-V825 and CP-V805 appliances. - vNIOS for Google Cloud instances do not support an HA setup with nodes on different cloud platforms, regions, zones, or on different instance types such as node 1 on a physical appliance and node 2 on a virtual appliance. - Due to a certain restriction from Google Cloud, the Address Resolution Protocol (ARP) functionality on the passive node of an HA pair always remains enabled. It cannot be disabled. Therefore, the passive node always responds to ping requests. - vNIOS for Google Cloud instances do not support the use of external IP address for accessing an HA Grid Master. - The time taken for an HA failover can vary depending on the response time from the host. - vNIOS for Google Cloud does not support automatic upgrade of software (NIOS) on an HA node If the node is running on a version of NIOS that is prior to 9.0.4. - Avoid interchanging network interfaces on a vNIOS instance as it can result in unexpected behavior. - If both nodes of an HA pair are powered off simultaneously, the alias IP address (VIP) assigned to the HA interface may get released to the free pool. If that happens, you must recover the IP address and reconfigure it as the alias IP address. - vNIOS for Google Cloud HA deployments are not supported on IPv6 (single stack), and IPv4 and IPv6 (dual stack) networks. # Limitations Specific to vDiscovery - Infoblox vDiscovery for Google Cloud does not support the discovery of load balancers. - When a VM in Google Cloud uses the **custom hostname** option, the **VM name** and the **VM hostname** fields are different. vDiscovery for Google Cloud uses only the VM name for the managed VM and ignores the VM hostname. - In NIOS versions prior to 9.0.4, when running vDiscovery across multiple projects, you must create one vDiscovery job per Google Cloud project. vDiscovery across multiple Google Cloud projects through a single vDiscovery job is not supported. - When you create an instance using a snapshot on Google Cloud and then run vDiscovery, the **OS** field in the **IPAM** tab will be blank. - In NIOS versions prior to 9.0.4, 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 VPC subnet of its host project. - From NIOS 9.0.4 onwards, if you want to discover shared resources (resources deployed in a shared VPC) using vDiscovery, ensure that the host project(s) and its service project(s) run on the same member or virtual node. - From NIOS 9.0.4 onwards, if you want to discover shared resources using vDiscovery to discover virtual entities in a service project, ensure that you discover the host project(s) first followed by the service project(s). - A vDiscovery job fails to discover a shared VPC if an HA failover occurs in between the discovery of the host and service projects. To discover the shared VPC, rerun the vDiscovery job on host and service projects after the HA failover. - From NIOS 9.0.4, it is necessary for the same member to discover both the host project and its service projects. - The discovery of shared VPC resources for a service project may lag by one or more intervals depending on the host project(s) discovery of the shared VPC. - Google Cloud vDiscovery discards networks or networks under auto-created subnetworks.