5.2. Cluster Tasks

⁠5.2. Cluster Tasks

5.2.1. Creating a New Cluster
5.2.2. Explanation of Settings and Controls in the New Cluster and Edit Cluster Windows
5.2.3. Editing a Resource
5.2.4. Setting Load and Power Management Policies for Hosts in a Cluster
5.2.5. Updating the MoM Policy on Hosts in a Cluster
5.2.6. CPU Profiles
5.2.7. Importing an Existing Red Hat Gluster Storage Cluster
5.2.8. Explanation of Settings in the Add Hosts Window
5.2.9. Creating a New Logical Network in a Data Center or Cluster
5.2.10. Removing a Cluster
5.2.11. Designate a Specific Traffic Type for a Logical Network with the Manage Networks Window
5.2.12. Explanation of Settings in the Manage Networks Window
5.2.13. Changing the Cluster Compatibility Version

⁠5.2.1. Creating a New Cluster

A data center can contain multiple clusters, and a cluster can contain multiple hosts. All hosts in a cluster must be of the same CPU type (Intel or AMD). It is recommended that you create your hosts before you create your cluster to ensure CPU type optimization. However, you can configure the hosts at a later time using the Guide Me button.

⁠

Procedure 5.1. Creating a New Cluster

Select the Clusters resource tab.
Click New to open the New Cluster window.
Select the Data Center the cluster will belong to from the drop-down list.
Enter the Name and Description of the cluster.
Select the CPU Type and Compatibility Version from the drop-down lists. It is important to match the CPU processor family with the minimum CPU processor type of the hosts you intend to attach to the cluster, otherwise the host will be non-operational.
Note
For both Intel and AMD CPU types, the listed CPU models are in logical order from the oldest to the newest. If your cluster includes hosts with different CPU models, select the oldest CPU model. For more information on each CPU model, see https://access.redhat.com/solutions/634853.
Select either the Enable Virt Service or Enable Gluster Service radio button to define whether the cluster will be populated with virtual machine hosts or with Gluster-enabled nodes. Note that you cannot add Red Hat Enterprise Virtualization Hypervisor hosts to a Gluster-enabled cluster.
Optionally select the Enable to set VM maintenance reason check box to enable an optional reason field when a virtual machine is shut down from the Manager, allowing the administrator to provide an explanation for the maintenance.
Select either the /dev/random source (Linux-provided device) or /dev/hwrng source (external hardware device) check box to specify the random number generator device that all hosts in the cluster must use.
Click the Optimization tab to select the memory page sharing threshold for the cluster, and optionally enable CPU thread handling and memory ballooning on the hosts in the cluster.
Click the Resilience Policy tab to select the virtual machine migration policy.
Click the Cluster Policy tab to optionally configure a cluster policy, configure scheduler optimization settings, enable trusted service for hosts in the cluster, enable HA Reservation, and add a custom serial number policy.
Click the Console tab to optionally override the global SPICE proxy, if any, and specify the address of a SPICE proxy for hosts in the cluster.
Click the Fencing policy tab to enable or disable fencing in the cluster, and select fencing options.
Click OK to create the cluster and open the New Cluster - Guide Me window.
The Guide Me window lists the entities that need to be configured for the cluster. Configure these entities or postpone configuration by clicking the Configure Later button; configuration can be resumed by selecting the cluster and clicking the Guide Me button.

The new cluster is added to the virtualization environment.

⁠5.2.2. Explanation of Settings and Controls in the New Cluster and Edit Cluster Windows

⁠5.2.2.1. General Cluster Settings Explained

⁠

Figure 5.2. New Cluster window

The table below describes the settings for the General tab in the New Cluster and Edit Cluster windows. Invalid entries are outlined in orange when you click OK, prohibiting the changes being accepted. In addition, field prompts indicate the expected values or range of values.

⁠

Table 5.1. General Cluster Settings

Field	Description/Action
Data Center	The data center that will contain the cluster. The data center must be created before adding a cluster.
Name	The name of the cluster. This text field has a 40-character limit and must be a unique name with any combination of uppercase and lowercase letters, numbers, hyphens, and underscores.
Description / Comment	The description of the cluster or additional notes. These fields are recommended but not mandatory.
CPU Type	The CPU type of the cluster. Choose one of: Intel Conroe Family Intel Penryn Family Intel Nehalem Family Intel Westmere Family Intel SandyBridge Family Intel Haswell AMD Opteron G1 AMD Opteron G2 AMD Opteron G3 AMD Opteron G4 AMD Opteron G5 IBM POWER8 All hosts in a cluster must run either Intel, AMD, or IBM POWER8 CPU type; this cannot be changed after creation without significant disruption. The CPU type should be set to the oldest CPU model in the cluster. Only features present in all models can be used. For both Intel and AMD CPU types, the listed CPU models are in logical order from the oldest to the newest.
Compatibility Version	The version of Red Hat Enterprise Virtualization. Choose one of: 3.0 3.1 3.2 3.3 3.4 3.5 You will not be able to select a version older than the version specified for the data center.
CPU Architecture	The CPU architecture of the cluster. Choose one of: undefined x86_64 ppc64 This field only appears if a CPU Type is not specified.
Enable Virt Service	If this radio button is selected, hosts in this cluster will be used to run virtual machines.
Enable Gluster Service	If this radio button is selected, hosts in this cluster will be used as Red Hat Gluster Storage Server nodes, and not for running virtual machines. You cannot add a Red Hat Enterprise Virtualization Hypervisor host to a cluster with this option enabled.
Import existing gluster configuration	This check box is only available if the Enable Gluster Service radio button is selected. This option allows you to import an existing Gluster-enabled cluster and all its attached hosts to Red Hat Enterprise Virtualization Manager. The following options are required for each host in the cluster that is being imported: Address: Enter the IP or fully qualified domain name of the Gluster host server. Fingerprint: Red Hat Enterprise Virtualization Manager fetches the host's fingerprint, to ensure you are connecting with the correct host. Root Password: Enter the root password required for communicating with the host.
Enable to set VM maintenance reason	If this check box is selected, an optional reason field will appear when a virtual machine in the cluster is shut down from the Manager. This allows you to provide an explanation for the maintenance, which will appear in the logs and when the virtual machine is powered on again.
Required Random Number Generator sources:	If one of the following check boxes is selected, all hosts in the cluster must have that device available. This enables passthrough of entropy from the random number generator device to virtual machines. /dev/random source - The Linux-provided random number generator. /dev/hwrng source - An external hardware generator. Note that this feature is only supported on hosts running Red Hat Enterprise Linux 6.6 and later or Red Hat Enterprise Linux 7.0 and later.

⁠5.2.2.2. Optimization Settings Explained

Memory page sharing allows virtual machines to use up to 200% of their allocated memory by utilizing unused memory in other virtual machines. This process is based on the assumption that the virtual machines in your Red Hat Enterprise Virtualization environment will not all be running at full capacity at the same time, allowing unused memory to be temporarily allocated to a particular virtual machine.

CPU Thread Handling allows hosts to run virtual machines with a total number of processor cores greater than number of cores in the host. This is useful for non-CPU-intensive workloads, where allowing a greater number of virtual machines to run can reduce hardware requirements. It also allows virtual machines to run with CPU topologies that would otherwise not be possible, specifically if the number of guest cores is between the number of host cores and number of host threads.

The table below describes the settings for the Optimization tab in the New Cluster and Edit Cluster windows.

⁠

Table 5.2. Optimization Settings

Field	Description/Action
Memory Optimization	None - Disable memory overcommit: Disables memory page sharing. For Server Load - Allow scheduling of 150% of physical memory: Sets the memory page sharing threshold to 150% of the system memory on each host. For Desktop Load - Allow scheduling of 200% of physical memory: Sets the memory page sharing threshold to 200% of the system memory on each host.
CPU Threads	Selecting the Count Threads As Cores check box allows hosts to run virtual machines with a total number of processor cores greater than the number of cores in the host. The exposed host threads would be treated as cores which can be utilized by virtual machines. For example, a 24-core system with 2 threads per core (48 threads total) can run virtual machines with up to 48 cores each, and the algorithms to calculate host CPU load would compare load against twice as many potential utilized cores.
Memory Balloon	Selecting the Enable Memory Balloon Optimization check box enables memory overcommitment on virtual machines running on the hosts in this cluster. When this option is set, the Memory Overcommit Manager (MoM) will start ballooning where and when possible, with a limitation of the guaranteed memory size of every virtual machine. To have a balloon running, the virtual machine needs to have a balloon device with relevant drivers. Each virtual machine in cluster level 3.2 and higher includes a balloon device, unless specifically removed. Each host in this cluster receives a balloon policy update when its status changes to `Up`. If necessary, you can manually update the balloon policy on a host without having to change the status. See Section 5.2.5, “Updating the MoM Policy on Hosts in a Cluster”. It is important to understand that in some scenarios ballooning may collide with KSM. In such cases MoM will try to adjust the balloon size to minimize collisions. Additionally, in some scenarios ballooning may cause sub-optimal performance for a virtual machine. Administrators are advised to use ballooning optimization with caution.
KSM control	Selecting the Enable KSM check box enables MoM to run Kernel Same-page Merging (KSM) when necessary and when it can yield a memory saving benefit that outweighs its CPU cost.

⁠5.2.2.3. Resilience Policy Settings Explained

The resilience policy sets the virtual machine migration policy in the event of a host becoming non-operational. Virtual machines running on a host that becomes non-operational are live migrated to other hosts in the cluster; this migration is dependent upon your cluster resilience policy. If a host is non-responsive and gets rebooted, virtual machines with high availability are restarted on another host in the cluster. The resilience policy only applies to hosts in a non-operational state.

⁠

Table 5.3. Host Failure State Explained

State	Description
Non Operational	Non-operational hosts can be communicated with by the Manager, but have an incorrect configuration, for example a missing logical network. If a host becomes non-operational, the migration of virtual machines depends on the cluster resilience policy.
Non Responsive	Non-responsive hosts cannot be communicated with by the Manager. If a host becomes non-responsive, all virtual machines with high availability are restarted on a different host in the cluster.

Virtual machine migration is a network-intensive operation. For instance, on a setup where a host is running ten or more virtual machines, migrating and restarting all of them can be a long and resource-consuming process. Therefore, select the policy action to best suit your setup. If you prefer a conservative approach, disable all migration of virtual machines. Alternatively, if you have many virtual machines, but only several which are running critical workloads, select the option to migrate only highly available virtual machines.

The table below describes the settings for the Resilience Policy tab in the New Cluster and Edit Cluster windows. See Section 5.2.1, “Creating a New Cluster” for more information on how to set the resilience policy when creating a new cluster.

⁠

Table 5.4. Resilience Policy Settings

Field	Description/Action
Migrate Virtual Machines	Migrates all virtual machines in order of their defined priority.
Migrate only Highly Available Virtual Machines	Migrates only highly available virtual machines to prevent overloading other hosts.
Do Not Migrate Virtual Machines	Prevents virtual machines from being migrated.

⁠5.2.2.4. Cluster Policy Settings Explained

Cluster policies allow you to specify the usage and distribution of virtual machines between available hosts. Define the cluster policy to enable automatic load balancing across the hosts in a cluster.

⁠

Figure 5.3. Cluster Policy Settings: vm_evenly_distributed

The table below describes the settings for the Cluster Policy tab.

⁠

Table 5.5. Cluster Policy Tab Properties

Field	Description/Action
Select Policy	Select a policy from the drop-down list. none: Set the policy value to none to have no load or power sharing between hosts. This is the default mode. evenly_distributed: Distributes the CPU processing load evenly across all hosts in the cluster. Additional virtual machines attached to a host will not start if that host has reached the defined Maximum Service Level. power_saving: Distributes the CPU processing load across a subset of available hosts to reduce power consumption on underutilized hosts. Hosts with a CPU load below the low utilization value for longer than the defined time interval will migrate all virtual machines to other hosts so that it can be powered down. Additional virtual machines attached to a host will not start if that host has reached the defined high utilization value. vm_evenly_distributed: Distributes virtual machines evenly between hosts based on a count of the virtual machines. The cluster is considered unbalanced if any host is running more virtual machines than the HighVmCount and there is at least one host with a virtual machine count that falls outside of the MigrationThreshold.
Properties	The following properties appear depending on the selected policy, and can be edited if necessary: HighVmCount: Sets the maximum number of virtual machines that can run on each host. Exceeding this limit qualifies the host as overloaded. The default value is 10. MigrationThreshold: Defines a buffer before virtual machines are migrated from the host. It is the maximum inclusive difference in virtual machine count between the most highly-utilized host and the least-utilized host. The cluster is balanced when every host in the cluster has a virtual machine count that falls inside the migration threshold. The default value is 5. SpmVmGrace: Defines the number of slots for virtual machines to be reserved on SPM hosts. The SPM host will have a lower load than other hosts, so this variable defines how many fewer virtual machines than other hosts it can run. The default value is 5. CpuOverCommitDurationMinutes: Sets the time (in minutes) that a host can run a CPU load outside of the defined utilization values before the cluster policy takes action. The defined time interval protects against temporary spikes in CPU load activating cluster policies and instigating unnecessary virtual machine migration. Maximum two characters. The default value is 2. HighUtilization: Expressed as a percentage. If the host runs with CPU usage at or above the high utilization value for the defined time interval, the Red Hat Enterprise Virtualization Manager migrates virtual machines to other hosts in the cluster until the host's CPU load is below the maximum service threshold. The default value is 80. LowUtilization: Expressed as a percentage. If the host runs with CPU usage below the low utilization value for the defined time interval, the Red Hat Enterprise Virtualization Manager will migrate virtual machines to other hosts in the cluster. The Manager will power down the original host machine, and restart it again when load balancing requires or there are not enough free hosts in the cluster. The default value is 20. ScaleDown: Reduces the impact of the HA Reservation weight function, by dividing a host's score by the specified amount. This is an optional property that can be added to any policy, including none. HostsInReserve: Specifies a number of hosts to keep running even though there are no running virtual machines on them. This is an optional property that can be added to the power_saving policy. EnableAutomaticHostPowerManagement: Enables automatic power management for all hosts in the cluster. This is an optional property that can be added to the power_saving policy. The default value is true.
Scheduler Optimization	Optimize scheduling for host weighing/ordering. Optimize for Utilization: Includes weight modules in scheduling to allow best selection. Optimize for Speed: Skips host weighting in cases where there are more than ten pending requests.
Enable Trusted Service	Enable integration with an OpenAttestation server. Before this can be enabled, use the `engine-config` tool to enter the OpenAttestation server's details.
Enable HA Reservation	Enable the Manager to monitor cluster capacity for highly available virtual machines. The Manager ensures that appropriate capacity exists within a cluster for virtual machines designated as highly available to migrate in the event that their existing host fails unexpectedly.
Provide custom serial number policy	This check box allows you to specify a serial number policy for the virtual machines in the cluster. Select one of the following options: Host ID: Sets the host's UUID as the virtual machine's serial number. Vm ID: Sets the virtual machine's UUID as its serial number. Custom serial number: Allows you to specify a custom serial number.

When a host's free memory drops below 20%, ballooning commands like mom.Controllers.Balloon - INFO Ballooning guest:half1 from 1096400 to 1991580 are logged to /var/log/vdsm/mom.log. /var/log/vdsm/mom.log is the Memory Overcommit Manager log file.

⁠5.2.2.5. Cluster Console Settings Explained

The table below describes the settings for the Console tab in the New Cluster and Edit Cluster windows.

⁠

Table 5.6. Console Settings

Field	Description/Action
Define SPICE Proxy for Cluster	Select this check box to enable overriding the SPICE proxy defined in global configuration. This feature is useful in a case where the user (who is, for example, connecting via the User Portal) is outside of the network where the hypervisors reside.
Overridden SPICE proxy address	The proxy by which the SPICE client will connect to virtual machines. The address must be in the following format: protocol://[host]:[port]

⁠5.2.2.6. Fencing Policy Settings Explained

The table below describes the settings for the Fencing Policy tab in the New Cluster and Edit Cluster windows.

⁠

Table 5.7. Fencing Policy Settings

Field	Description/Action
Enable fencing	Enables fencing on the cluster. Fencing is enabled by default, but can be disabled if required; for example, if temporary network issues are occurring or expected, administrators can disable fencing until diagnostics or maintenance activities are completed. Note that if fencing is disabled, highly available virtual machines running on non-responsive hosts will not be restarted elsewhere.
Skip fencing if host has live lease on storage	If this check box is selected, any hosts in the cluster that are Non Responsive and still connected to storage will not be fenced.
Skip fencing on cluster connectivity issues	If this check box is selected, fencing will be temporarily disabled if the percentage of hosts in the cluster that are experiencing connectivity issues is greater than or equal to the defined Threshold. The Threshold value is selected from the drop-down list; available values are 25, 50, 75, and 100.

⁠5.2.3. Editing a Resource

Summary

Edit the properties of a resource.

⁠

Procedure 5.2. Editing a Resource

Use the resource tabs, tree mode, or the search function to find and select the resource in the results list.
Click Edit to open the Edit window.
Change the necessary properties and click OK.

Result

The new properties are saved to the resource. The Edit window will not close if a property field is invalid.

⁠5.2.4. Setting Load and Power Management Policies for Hosts in a Cluster

The evenly_distributed and power_saving cluster policies allow you to specify acceptable CPU usage values, and the point at which virtual machines must be migrated to or from a host. The vm_evenly_distributed cluster policy distributes virtual machines evenly between hosts based on a count of the virtual machines. Define the cluster policy to enable automatic load balancing across the hosts in a cluster. For a detailed explanation of each cluster policy, see Section 5.2.2.4, “Cluster Policy Settings Explained”.

⁠

Procedure 5.3. Setting Load and Power Management Policies for Hosts

Use the resource tabs, tree mode, or the search function to find and select the cluster in the results list.
Click Edit to open the Edit Cluster window.

⁠
Figure 5.4. Edit Cluster Policy
Select one of the following policies:
- none
- vm_evenly_distributed
  1. Set the maximum number of virtual machines that can run on each host in the HighVmCount field.
  2. Define the maximum acceptable difference between the number of virtual machines on the most highly-utilized host and the number of virtual machines on the least-utilized host in the MigrationThreshold field.
  3. Define the number of slots for virtual machines to be reserved on SPM hosts in the SpmVmGrace field.
- evenly_distributed
  1. Set the time (in minutes) that a host can run a CPU load outside of the defined utilization values before the cluster policy takes action in the CpuOverCommitDurationMinutes field.
  2. Enter the CPU utilization percentage at which virtual machines start migrating to other hosts in the HighUtilization field.
- power_saving
  1. Set the time (in minutes) that a host can run a CPU load outside of the defined utilization values before the cluster policy takes action in the CpuOverCommitDurationMinutes field.
  2. Enter the CPU utilization percentage below which the host will be considered under-utilized in the LowUtilization field.
  3. Enter the CPU utilization percentage at which virtual machines start migrating to other hosts in the HighUtilization field.
Choose one of the following as the Scheduler Optimization for the cluster:
- Select Optimize for Utilization to include weight modules in scheduling to allow best selection.
- Select Optimize for Speed to skip host weighting in cases where there are more than ten pending requests.
If you are using an OpenAttestation server to verify your hosts, and have set up the server's details using the engine-config tool, select the Enable Trusted Service check box.
Optionally select the Enable HA Reservation check box to enable the Manager to monitor cluster capacity for highly available virtual machines.
Optionally select the Provide custom serial number policy check box to specify a serial number policy for the virtual machines in the cluster, and then select one of the following options:
- Select Host ID to set the host's UUID as the virtual machine's serial number.
- Select Vm ID to set the virtual machine's UUID as its serial number.
- Select Custom serial number, and then specify a custom serial number in the text field.
Click OK.

⁠5.2.5. Updating the MoM Policy on Hosts in a Cluster

The Memory Overcommit Manager handles memory balloon and KSM functions on a host. Changes to these functions at the cluster level are only passed to hosts the next time a host moves to a status of Up after being rebooted or in maintenance mode. However, if necessary you can apply important changes to a host immediately by synchronizing the MoM policy while the host is Up. The following procedure must be performed on each host individually.

⁠

Procedure 5.4. Synchronizing MoM Policy on a Host

Click the Clusters tab and select the cluster to which the host belongs.
Click the Hosts tab in the details pane and select the host that requires an updated MoM policy.
Click Sync MoM Policy.

The MoM policy on the host is updated without having to move the host to maintenance mode and back Up.

⁠5.2.6. CPU Profiles

CPU profiles define the maximum amount of processing capability a virtual machine in a cluster can access on the host on which it runs, expressed as a percent of the total processing capability available to that host. CPU profiles are created based on CPU profiles defined under data centers, and are not automatically applied to all virtual machines in a cluster; they must be manually assigned to individual virtual machines for the profile to take effect.

⁠5.2.6.1. Creating a CPU Profile

Create a CPU profile. This procedure assumes you have already defined one or more CPU quality of service entries under the data center to which the cluster belongs.

⁠

Procedure 5.5. Creating a CPU Profile

Click the Clusters resource tab and select a cluster.
Click the CPU Profiles sub tab in the details pane.
Click New.
Enter a name for the CPU profile in the Name field.
Enter a description for the CPU profile in the Description field.
Select the quality of service to apply to the CPU profile from the QoS list.
Click OK.

You have created a CPU profile, and that CPU profile can be applied to virtual machines in the cluster.

⁠5.2.6.2. Removing a CPU Profile

Remove an existing CPU profile from your Red Hat Enterprise Virtualization environment.

⁠

Procedure 5.6. Removing a CPU Profile

Click the Clusters resource tab and select a cluster.
Click the CPU Profiles sub tab in the details pane.
Select the CPU profile to remove.
Click Remove.
Click OK.

You have removed a CPU profile, and that CPU profile is no longer available. If the CPU profile was assigned to any virtual machines, those virtual machines are automatically assigned the default CPU profile.

⁠5.2.7. Importing an Existing Red Hat Gluster Storage Cluster

You can import a Red Hat Gluster Storage cluster and all hosts belonging to the cluster into Red Hat Enterprise Virtualization Manager.

When you provide details such as the IP address or host name and password of any host in the cluster, the gluster peer status command is executed on that host through SSH, then displays a list of hosts that are a part of the cluster. You must manually verify the fingerprint of each host and provide passwords for them. You will not be able to import the cluster if one of the hosts in the cluster is down or unreachable. As the newly imported hosts do not have VDSM installed, the bootstrap script installs all the necessary VDSM packages on the hosts after they have been imported, and reboots them.

Important

Currently, a Red Hat Gluster Storage node can only be added to a cluster which has its compatibility level set to 3.1, 3.2, or 3.3.

⁠

Procedure 5.7. Importing an Existing Red Hat Gluster Storage Cluster to Red Hat Enterprise Virtualization Manager

Select the Clusters resource tab to list all clusters in the results list.
Click New to open the New Cluster window.
Select the Data Center the cluster will belong to from the drop-down menu.
Enter the Name and Description of the cluster.
Select the Enable Gluster Service radio button and the Import existing gluster configuration check box.
The Import existing gluster configuration field is displayed only if you select Enable Gluster Service radio button.
In the Address field, enter the hostname or IP address of any server in the cluster.
The host Fingerprint displays to ensure you are connecting with the correct host. If a host is unreachable or if there is a network error, an error Error in fetching fingerprint displays in the Fingerprint field.
Enter the Root Password for the server, and click OK.
The Add Hosts window opens, and a list of hosts that are a part of the cluster displays.
For each host, enter the Name and the Root Password.
If you wish to use the same password for all hosts, select the Use a Common Password check box to enter the password in the provided text field.
Click Apply to set the entered password all hosts.
Make sure the fingerprints are valid and submit your changes by clicking OK.

The bootstrap script installs all the necessary VDSM packages on the hosts after they have been imported, and reboots them. You have now successfully imported an existing Red Hat Gluster Storage cluster into Red Hat Enterprise Virtualization Manager.

⁠5.2.8. Explanation of Settings in the Add Hosts Window

The Add Hosts window allows you to specify the details of the hosts imported as part of a Gluster-enabled cluster. This window appears after you have selected the Enable Gluster Service check box in the New Cluster window and provided the necessary host details.

⁠

Table 5.8. Add Gluster Hosts Settings

Field	Description
Use a common password	Tick this check box to use the same password for all hosts belonging to the cluster. Enter the password in the Password field, then click the Apply button to set the password on all hosts.
Name	Enter the name of the host.
Hostname/IP	This field is automatically populated with the fully qualified domain name or IP of the host you provided in the New Cluster window.
Root Password	Enter a password in this field to use a different root password for each host. This field overrides the common password provided for all hosts in the cluster.
Fingerprint	The host fingerprint is displayed to ensure you are connecting with the correct host. This field is automatically populated with the fingerprint of the host you provided in the New Cluster window.

⁠5.2.9. Creating a New Logical Network in a Data Center or Cluster

Summary

Create a logical network and define its use in a data center, or in clusters in a data center.

⁠

Procedure 5.8. Creating a New Logical Network in a Data Center or Cluster

Use the Data Centers or Clusters resource tabs, tree mode, or the search function to find and select a data center or cluster in the results list.
Click the Logical Networks tab of the details pane to list the existing logical networks.
- From the Data Centers details pane, click New to open the New Logical Network window.
- From the Clusters details pane, click Add Network to open the New Logical Network window.
Enter a Name, Description, and Comment for the logical network.
Optionally select the Create on external provider check box. Select the External Provider from the drop-down list and provide the IP address of the Physical Network.
If Create on external provider is selected, the Network Label, VM Network, and MTU options are disabled.
Enter a new label or select an existing label for the logical network in the Network Label text field.
Optionally enable Enable VLAN tagging.
Optionally disable VM Network.
Set the MTU value to Default (1500) or Custom.
From the Cluster tab, select the clusters to which the network will be assigned. You can also specify whether the logical network will be a required network.
If Create on external provider is selected, the Subnet tab will be visible. From the Subnet tab, select the Create subnet and enter a Name, CIDR, and Gateway address, and select an IP Version for the subnet that the logical network will provide. You can also add DNS servers as required.
From the vNIC Profiles tab, add vNIC profiles to the logical network as required.
Click OK.

Result

You have defined a logical network as a resource required by a cluster or clusters in the data center. If you entered a label for the logical network, it will be automatically added to all host network interfaces with that label.

Note

When creating a new logical network or making changes to an existing logical network that is used as a display network, any running virtual machines that use that network must be rebooted before the network becomes available or the changes are applied.

⁠5.2.10. Removing a Cluster

Summary

Move all hosts out of a cluster before removing it.

Note

You cannot remove the Default cluster, as it holds the Blank template. You can however rename the Default cluster and add it to a new data center.

⁠

Procedure 5.9. Removing a Cluster

Use the resource tabs, tree mode, or the search function to find and select the cluster in the results list.
Ensure there are no hosts in the cluster.
Click Remove to open the Remove Cluster(s) confirmation window.
Click OK

Result

The cluster is removed.

⁠5.2.11. Designate a Specific Traffic Type for a Logical Network with the Manage Networks Window

Summary

Specify the traffic type for the logical network to optimize the network traffic flow.

⁠

Procedure 5.10. Specifying Traffic Types for Logical Networks

Use the Clusters resource tab, tree mode, or the search function to find and select the cluster in the results list.
Select the Logical Networks tab in the details pane to list the logical networks assigned to the cluster.
Click Manage Networks to open the Manage Networks window.
⁠
Figure 5.5. Manage Networks
Select appropriate check boxes.
Click OK to save the changes and close the window.

Result

You have optimized the network traffic flow by assigning a specific type of traffic to be carried on a specific logical network.

Note

Logical networks offered by external providers must be used as virtual machine networks; they cannot be assigned special cluster roles such as display or migration.

⁠5.2.12. Explanation of Settings in the Manage Networks Window

The table below describes the settings for the Manage Networks window.

⁠

Table 5.9. Manage Networks Settings

Field	Description/Action
Assign	Assigns the logical network to all hosts in the cluster.
Required	A Network marked "required" must remain operational in order for the hosts associated with it to function properly. If a required network ceases to function, any hosts associated with it become non-operational.
VM Network	A logical network marked "VM Network" carries network traffic relevant to the virtual machine network.
Display Network	A logical network marked "Display Network" carries network traffic relevant to SPICE and to the virtual network controller.
Migration Network	A logical network marked "Migration Network" carries virtual machine and storage migration traffic.

⁠5.2.13. Changing the Cluster Compatibility Version

Summary

Red Hat Enterprise Virtualization clusters have a compatibility version. The cluster compatibility version indicates the features of Red Hat Enterprise Virtualization supported by all of the hosts in the cluster. The cluster compatibility is set according to the version of the least capable host operating system in the cluster.

Note

To change the cluster compatibility version, you must have first updated all the hosts in your cluster to a level that supports your desired compatibility level.

⁠

Procedure 5.11. Changing the Cluster Compatibility Version

Log in to the Administration Portal as the administrative user. By default this is the admin user.
Click the Clusters tab.
Select the cluster to change from the list displayed. If the list of clusters is too long to filter visually then perform a search to locate the desired cluster.
Click the Edit button.
Change the Compatibility Version to the desired value.
Click OK to open the Change Cluster Compatibility Version confirmation window.
Click OK to confirm.

Result

You have updated the compatibility version of the cluster. Once you have updated the compatibility version of all clusters in a data center, then you are also able to change the compatibility version of the data center itself.

Warning

Upgrading the compatibility will also upgrade all of the storage domains belonging to the data center. If you are upgrading the compatibility version from below 3.1 to a higher version, these storage domains will become unusable with versions older than 3.1.