hvm-docs-refresh
8743fff510
1161 content change(s) across 7 bundle(s)
1161 sidecar metadata update(s)
7 new bundle(s) added
Bundles with content changes:
hvm_deployment_guide (NEW): 32 page(s)
- GUID-0F55384D-5632-4CDC-AA39-A21C1C089AFA
- GUID-28F18596-4902-4CD1-83F3-1411430C5534
- GUID-2DD9D39D-9031-4BB5-A4ED-A0179BEF5259
- GUID-34B1D00A-C42E-4691-8B4F-3B110E34FE7C
- GUID-3DA92E9D-0635-427A-BA9D-5A7E475B55DB
... and 27 more
hvm_release_notes_8_1_0 (NEW): 1 page(s)
- sd00007497en_us
hvm_release_notes_8_1_1 (NEW): 1 page(s)
- sd00007609en_us
hvm_release_notes_8_1_2 (NEW): 1 page(s)
- sd00007734en_us
hvm_user_manual_8_1_0 (NEW): 374 page(s)
- GUID-008AF6CD-E219-4D76-B175-B763E5C397CE
- GUID-02679208-A796-4A58-80AC-33DCF6A4899F
- GUID-034C2E21-6B14-4AAD-A582-2638A4C7D04C
- GUID-04410F73-1BA6-46D4-A7A4-E4706C5FD522
- GUID-0503F050-177F-4360-9B1A-49439AF366B8
... and 369 more
hvm_user_manual_8_1_1 (NEW): 376 page(s)
- GUID-008AF6CD-E219-4D76-B175-B763E5C397CE
- GUID-02679208-A796-4A58-80AC-33DCF6A4899F
- GUID-034C2E21-6B14-4AAD-A582-2638A4C7D04C
- GUID-04410F73-1BA6-46D4-A7A4-E4706C5FD522
- GUID-0503F050-177F-4360-9B1A-49439AF366B8
... and 371 more
hvm_user_manual_8_1_2 (NEW): 376 page(s)
- GUID-008AF6CD-E219-4D76-B175-B763E5C397CE
- GUID-02679208-A796-4A58-80AC-33DCF6A4899F
- GUID-034C2E21-6B14-4AAD-A582-2638A4C7D04C
- GUID-04410F73-1BA6-46D4-A7A4-E4706C5FD522
- GUID-0503F050-177F-4360-9B1A-49439AF366B8
... and 371 more
5.1 KiB
Scenario 1: Recommended Converged Networking Setup
This is where management and VM traffic is converged over the same bonded interface and storage traffic is independent. This is where management and VM traffic is converged over the same bonded interface and storage traffic is independent, for use cases where management and traffic separation is needed, review Scenario 2.
In an ideal scenario, you would have at least four network interfaces spread across at least two network cards on the host (shown in green on the diagram below). Ideally you would also have two separate network switches to help ensure resiliency and redundancy. As mentioned in the prior section, these networking examples are all created with resiliency and redundancy in mind. One storage lane is connected to each switch and likewise one management/VM lane is connected to each switch, which are bonded in and active/backup configuration. Consult the bonding table in the prior section for more details on the benefits and drawbacks to different types of network bonds.
Example 1
In this scenario, the bond handles management/VM traffic failover while multipathing handles storage failover. A diagram of such a network setup is shown below:
Example 2
In the example below, we have native VLAN on the trunk ports and on the storage ports. This means the network switch is tagging all the traffic for you and you don't have to tag it yourself. This allows you to put your IP addresses directly on the interfaces and bonds. Here, the storage VLANS get their own IP address directly on the interface while the management IP address goes directly on the bond as shown in the diagram below. With this configuration, all can be done in the installation wizard as long as the VLANs are piped to the interfaces as expected from the network switches. More specific guidance on using the installation wizard is included in later sections covering the software installation.
NOTE
Your environment an configurations will vary. You may or may not have a native VLAN set up for storage traffic as it is best practice to isolate storage traffic when possible. The need for VLAN tagging on specific interfaces is dependent on whether there is a native VLAN on that interface.
Below is a chart showing the connection from the bonded network interfaces created in the example network configuration above to OVS bridges (a virtual switch that connects VMs to the physical network), Virtual Networks (logical virtual networks managed by Libvirt), Libvirt Portgroups (subgroups within Libvirt Networks that can expose configurations, such as VLAN tagging), and tap interfaces (the virtual connection that connects the VM to the OVS bridge).
Example 3
The prior example included native VLANs on the trunk ports and storage ports so we'll now take a look at an example configuration without native VLANs. You need to create VLAN tags on the interfaces because the switch is no longer handling the tagging for you. Your IP addresses then go on those VLAN tags. In this example bond0 becomes the compute interface and bond0.x becomes the management interface when configuring the cluster in a later step (see Creating an HVM cluster). When not using a native VLAN, the storage VLANs still get their own IP address and interface but a VLAN interface gets created on the bond and the management IP address goes on the VLAN interface.
Just as in the similar chart above, the chart below shows the connection from the bonded network interfaces created in the example network configuration above to OVS bridges (a virtual switch that connects VMs to the physical network), Virtual Networks (logical virtual networks managed by Libvirt), Libvirt Portgroups (subgroups within Libvirt Networks that can expose configurations, such as VLAN tagging), and tap interfaces (the virtual connection that connects the VM to the OVS bridge).
Example 4
The same networking setup can be used with an LACP bond, however this does require extra configuration on the network switch side. The exact setup steps would depend on the specific hardware in your environment. The network setup would look something like the example below:
