If you select the Host in the tree view, information about it is shown in the details view. This information is divided into four tabs: Host info, Pools, Guests and Network. At this point, the Pools and Guests tab should be empty. You can find more information about them in the Administration Guide.
Host info tab
This tab displays basic information about the Host, and a summary of its available resources.
The table on the left shows:
Current and desired state. If they differ, the Manager will try to bring the Host to the desired state.
Name, address and description.
VDI address: This is the IP address/name reported to the VDI clients to connect to. This is required when the Host has a public and a private address.
CPU type and Hypervisor version.
Message provided by the Host's agent in case of error.
The graphs on the right show a summary of the available resources in this Host. Hosts provide CPU and RAM resources to Guests. The total resources offered by a Host consist of its physical resources adjusted by an overcommit factor. By overcommiting, a Host can offer more resources than actually available.
This tab shows the network interfaces available to the selected Host, which can be configured with the flexVDI Config tool:
- Physical interfaces.
- Bridge interfaces.
- Bonding interfaces.
- VLAN interfaces.
Configure the Host's resources
Right-click on the Host in the tree view, and select Modify in the popup menu. A wizard will show to modify some of the properties of your Host:
With this wizard you can modify:
- A description for the Host.
- The Host's IP address as seen by the Manager. This is the address the Manager will use to communicate with the Host.
- The Host's VDI address as seen by the Clients. This is the address that will be notified to a client when it wants to connect with a guest that is running in this Host. This is most useful when the Host has a private address in the Manager subnet, and a public address to receive Client connections.
- CPU and RAM overcommit, as a factor by which physical resources are multiplied.
As stated before, overcommiting allows the Host to report more resources than physically available. Overcommiting CPU resources is very useful, because it is a time-shared resource. It allows to run several virtual machines on the same CPU, reducing its idle time and optimizing its utilization. Besides, it is safe to overcommit the CPU, because in case of congestion the system will gracely degrade its performance, allowing the administrator to solve the problem. On a typical desktop (web browsing, office applications, etc...), a CPU overcommit factor of 4 is recommended. If you plan to run more CPU-intensive tasks, start at 1 and increase the value until you feel comfortable.
On the other hand, overcommiting RAM resources is not recommended at all. RAM is not a shared resource, each Guest gets an exclusive amount of it. If the physical RAM is exhausted, the system will start to use swap space (if available), and the performance of both the Guests and the Host will be severely affected. Do it under your own responsibility.
In order to avoid removing resources from a Host that has Guests running, you always can increase the overcommit factors of a Host, but you must disable it first to decrease them.