About virtual network interfaces

Key benefits and capabilities

Virtual network interface highlights include:

• The ability to assign multiple, secondary private IPv4 IP addresses from a VPC subnet.
• The option to define and enforce security groups and unique IAM policies to give you more control over network security.
• Scalability and flexibility for high-availability solutions.
• Existence without being attached to a server, and the option to move from one instance or resource to another, reducing failover time.
• The ability to attach floating IPs, primary/secondary reserved IPs, and security groups.

Planning considerations

Review the following considerations before creating a VNI:

• Creating resources with child network interfaces will continue to be supported, but new networking features, like secondary IP addresses, are supported only on virtual network interfaces.

• Although an instance or bare metal server does not allow a mix of interface types, a subnet allows a mix of instances and bare metal servers -- some with child network interfaces and some with virtual network interfaces.

• You must configure the primary IP address when creating a virtual network interface. You can configure additional (secondary) reserved IP addresses when creating the virtual network interface, or you can later add secondary IP addresses individually. All secondary IP addresses must be in the same subnet as the primary IP address.

• You can configure one floating IP address on a virtual network interface that has infrastructure NAT enabled. A virtual network interface configured this way can be used by an instance or a bare metal server.

• For a virtual network interface that allows IP spoofing and has infrastructure NAT disabled, you can configure multiple floating IP addresses. A virtual network interface configured this way can only be used by a bare metal server.

• All IP addresses on a virtual network interface must be in the same subnet.

• If a virtual network interface's auto-delete property is set to false, if you then delete the virtual server instance, the virtual network interface will remain. The virtual network interface can then be attached to a different target resource.

• After a VNI detaches from a target, you can reattach it to one of the following:

  • A new share mount target (if ip-spoofing is disabled, there no secondary IPs, and infrastructure NAT is set to true)
  • A new network attachment on an instance (if infrastructure NAT is set to true)
  • A new network attachment on a bare metal server (when bare metal is supported)

Getting started with virtual network interfaces

You can use a VNI to manage the IP addresses and security groups in a separate resource with a lifecycle that is independent of your target resource.

1. Ensure that you have a VPC and subnet attached. For more information, see creating VPC resources using the IBM Cloud console or creating with CLI and API.

2. Review planning considerations and any known issues and limitations.

3. Ensure that you have the correct IAM permissions to create a VNI.

4. Create a virtual network interface with a private IP address, a public IP address, and security groups.

5. Attach your VNI to a supported target resource when provisioning the target. Currently, there are three supported target types:

   • Virtual server instance
     • When provisioning an instance, attach the VNI to the primary network attachment child resource. See Creating virtual server instances.
     • If you have an existing virtual server instance with a primary network attachment, you can provision an additional network attachment on the virtual server instance, attaching the VNI to the new network attachment. See Creating network attachments.
   • Bare metal server
     • When provisioning a bare metal server, attach the VNI to the primary network attachment child resource. See Creating Bare Metal Servers on VPC.
     • If you have an existing bare metal server with a primary network attachment, you can provision an additional network attachment on the bare metal server, attaching the VNI to the new network attachment. See Creating network attachments.
   • File share mount
     • When provisioning a new file share mount, attach the VNI to the file share mount target. See Creating file shares and mount targets and Mount targets for file shares.

It's also possible to create a VNI in the context of provisioning each of these targets. In other words, you don't need to create a VNI ahead of time. Later, you can delete the instance and preserve the VNI by ensuring that --auto-delete is false (Auto release switch). Then, you can create a new instance using the same VNI.

Use case 1: High availability with virtual network interfaces

Virtual network interfaces reduce the time required to switch to a failover instance. In a virtual server instance that doesn't use virtual network interfaces, a failover requires routing changes that can take several minutes to propagate. In the following example, you have a primary virtual server instance configured with a network interface, and a backup virtual server instance that has its own network interface. If the primary virtual server instance fails, you must bring the backup virtual server instance online, and reconfigure your routes to use the backup instance's network interface.

By using a virtual network interface, you can move it from one instance to another. The independent lifecycle of the virtual network interface means that it keeps its IP address and you don't have to reconfigure your routes, reducing failover time to seconds.

Use case 2: Secondary IP addresses with virtual network interfaces

A virtual server instance that runs several instances of an application can be segmented such that each instance of the application has its own IP address.

For this example, a single virtual server instance is running three instances of a SQL database application. Each SQL instance needs to have its own IP address. By using secondary IP addresses on a virtual network interface, you can assign different IP addresses to each application instance.

Support for old API clients

For compatibility with old clients, the API response provides a read-only representation of each network attachment and its associated virtual network interface as a child network interface:

• When retrieving an instance network interface, the properties are derived as follows:

The status value is determined according to the following table:

• The same properties are derived when retrieving a bare metal server network interface, in addition to the following properties that are specific to bare metal server network interfaces:

Related links

These links provide additional information about virtual network interfaces for VPC:

• Activity tracker events
• FAQs
• IAM permissions
• Quotas
• Terraform registry
• Troubleshooting