Add VMware vCenter clusters as servers
You can add VMware vCenter clusters to Abiquo as server hosts. This means that Abiquo will manage vCenter clusters instead of individual vCenter servers.
In Infrastructure, you manage the cluster directly without managing individual servers and this will save you administration time. And you can still manage your servers in vCenter.
All of the VMs in the cluster will be directly listed under the cluster.
When you add vCenter clusters as hosts, you can take advantage of VMware cluster scheduling, which will fully manage the VMs on the vCenter servers within the cluster. VMware's Dynamic Resource Scheduling (DRS) works at a lower level than Abiquo scheduling and will improve vCenter performance. And Abiquo does not need to manage VM move events because from Abiquo's perspective all of the VMs in the cluster are on a single server.
When users deploy VMs, the platform will allocate them to VMware clusters instead of directly to ESXi servers. This means that you will be able to make better use of your resources, because scheduling to clusters instead of servers is much more efficient. You may be able to deploy to a cluster that is at 90% of its capacity, but you would not be able to deploy to individual servers in this cluster. This is because the vCenter manager can move VMs around the cluster according to performance needs.
Networking
When using vCenter clusters as servers, Abiquo will only search for network interfaces that are dvSwitches (VMware distributed virtual switches or VDSs). Abiquo will retrieve the dVSwitches from the cluster itself, not from the individual hosts. Optionally configure the properties for the dVSwitches.
Datastore checks
To ensure that it can deploy VMs, Abiquo checks datastores on ESXi hypervisors with the following conditions:
- datastore is accessible
- datastore is mounted as read/write on all hosts in the cluster or the current host for single host mode
- datastore is not in maintenance mode
Abiquo may automatically disable datastores:
- If you enabled a datastore but it fails the datastore check, then Abiquo will automatically disable it. If it passes a future check, then Abiquo will automatically enable it again.
- If you disabled a datastore and it fails the datastore check, Abiquo will ignore it!
Shared datastores
Abiquo recommends the use of shared datastores with vCenter clusters to ensure mobility within the cluster where all hosts can access all datastores.
- When you use a shared datastore, the platform creates a different datastore on each physical machine using the datastore. This means that a shared datastore can be enabled on one host and disabled on another, either as a result of user configuration or an issue (e.g. an NFS communication error on one host).
Local datastores
Abiquo does not recommend local datastores but if you need to work with local datastores, configure a tier with the local datastores of only a specific host. This will ensure that VMs can always find a valid local datastore,
It is not possible to use a tier containing local datastores of different hosts. When you reconfigure a VM, the error (Invalid configuration for device '0'.[InvalidDeviceSpec]) may appear if the platform is trying to create a disk or use an ISO on a local datastore that is not available to the host with the VM.
The platform represents the VMware cluster as a physical machine/hypervisor host, so it does not track the host entities in vCenter.
Mounting NFS repository on vCenter hosts
In general, the platform will mount the NFS repository automatically. However, the platform will not check that the repository is correctly mounted on hosts in the vCenter cluster until it needs to use the repository. For example, when a user tries to deploy a VM, the platform will select a host and check that it can mount the datastore and the NFS repository. After the platform copies the disk from the repository to the datastore, if the selected host is not connected or in maintenance mode, the platform may deploy the VM to another host.
In addition it is important to note:
- The platform only checks the mount information for hosts in the cluster that are connected and not in maintenance mode.
- If it is not possible to mount the NFS on a host, then it doesn't abort the operation. Errors mounting the repository are reported as a WARN in the virtualfactory.log of the Virtualization Manager remote service.
- Message: Cannot mount nas 'nfs-location' in 'hostName'
- If a host in the cluster mounts the NFS repository but it is not properly mounted, then the platform does not try to fix it. It is only reported as a WARN in virtualfactory.log of the Virtualization Manager remote service.
- Message: NFS repo 'nfs-location' in host 'hostName' ('host-id') - not mounted, not accessible or not readWrite
Allocation rules
Note that in this version, when using VMware clusters directly as physical machines, the platform will detect the server and the level above the server as usual (server - cluster) but in this case, it will be cluster - datacenter. To create allocation rules for the clusters that you have registered directly as physical machines, use the "Server" rules, not the cluster rules.
Deprecated remote access using VNC
VMware vSphere version 7 does not allow remote access by VNC, so you will need to switch to WebMKS. See Enable WebMKS for vCenter
But for earlier versions the platform can automatically add the remote access IP to deployed VMs. This functionality can be configured with Abiquo properties, see Detect vCenter management IPs.
The following diagram shows how Abiquo discovers, manages, and allows remote access to a vCenter Cluster.
Copyright © 2006-2022, Abiquo Holdings SL. All rights reserved