vCenter Node Installation¶
This guide lays out the configuration requirements needed in the vCenter and ESX instances in order to be managed by OpenNebula.
The VMware vCenter drivers enable OpenNebula to access one or more vCenter servers managing one or more ESX Clusters. Each ESX Cluster is presented in OpenNebula as an aggregated hypervisor, i.e. as an OpenNebula Host. This means that the representation is one OpenNebula Host per ESX Cluster.
Note that OpenNebula scheduling decisions are therefore made at ESX Cluster level. vCenter then uses the DRS component to select the actual ESX Host and Datastore to deploy the Virtual Machine.
Requirements¶
Supported vSphere version (check Platform Notes). Please note that Debian is not supported in the OpenNebula front-end if you are intending to manage VMware infrastructures.
vCenter user for OpenNebula, the hassle-free approach is to declare this oneadmin user as an administrator. Otherwise, a table with the permissions required is found at the end of this guide.
If virtual standard switches are used, check that those switches exist in every ESX Host belonging to the same ESX cluster. Conversely, if you use distributed virtual switches, check that ESX Hosts have been added to switches.
Configuring FireEdge to enable VMRC access to VMs.
Although optional, the ESX cluster should have DRS enabled. OpenNebula does not schedule to the granularity of ESX Hosts, so DRS is needed to select the actual ESX Host within the cluster.
OpenNebula uses port 443 to communicate with vCenter instances. Port 443 is the default port used by vCenter, so unless you’re filtering that port, or you’ve configured a different port to listen for connections from the vSphere Web Client, OpenNebula will be able to connect with the right credentials.
It’s worth highlighting that OpenNebula will not modify any vCenter configuration with some exceptions: the creation of virtual switches and port groups if the vcenter network driver is used, and the creation of images for VMDK and/or ISO files.
For security reasons, you may define different users to access different ESX clusters. A different user can be defined in OpenNebula per ESX cluster, which is encapsulated in OpenNebula as an OpenNebula Host.
Warning
If using a federation of two or more OpenNebula instances, please make sure that you have oneadmin endpoint pointing to the local zone, otherwise monitoring subsystem and CLI tools like onevcenter may malfunction.
Configuration¶
Importing vCenter Clusters¶
OpenNebula ships with a powerful CLI tool to import vCenter clusters, VM Templates, Networks and running VMs. The tool onevcenter is self-explanatory, just set the credentials and FQDN/IP to access the vCenter Host and follow on screen instructions.
If you need to know how to import vCenter clusters, check vCenter import tool.
After importing a vCenter cluster as an OpenNebula Host, it should be successfully monitored. If the OpenNebula Host goes into ERROR state, please check connectivity and have a look at the /var/log/one/oned.log
file in order to find out the possible cause.
The following variables are added to OpenNebula Hosts representing ESX clusters:
Operation |
Note |
VCENTER_HOST |
Hostname or IP of the vCenter Host |
VCENTER_USER |
Name of the vCenter user |
VCENTER_PASSWORD |
Password of the vCenter user |
VCENTER_VERSION |
The vCenter version detected by OpenNebula e.g 5.5 |
VCENTER_CCR_REF |
The Managed Object Reference to the vCenter cluster |
VCENTER_INSTANCE_ID |
The vCenter instance UUID identifier |
You have more information about what a Managed Object Reference is and what the vCenter instance UUID is in the vCenter driver section.
Note
OpenNebula will create a special key at boot time and save it in /var/lib/one/.one/one_key
. This key will be used as a private key to encrypt and decrypt all the passwords for all the vCenters that OpenNebula can access. Thus, the password shown in the OpenNebula Host representing the vCenter is the original password encrypted with this key.
Permissions requirement¶
If the user account that is going to be used in vCenter operations is not declared as an Administrator, the following table summarizes the privileges required by the tasks performed in vCenter by OpenNebula:
Privileges ID |
Privilege name |
Notes |
Datastore.AllocateSpace |
Allocate space |
On all VMFS datastores represented by OpenNebula |
Datastore.Browse |
Browse datastore |
On all VMFS datastores represented by OpenNebula |
Datastore.FileManagement |
Low level file operations |
On all VMFS datastores represented by OpenNebula |
Datastore.Delete |
Remove datastore |
On all VMFS datastores represented by OpenNebula |
DVPortgroup.Create |
Create |
Required if you want OpenNebula to create distributed port groups |
DVPortgroup.Delete |
Delete |
Required if you want OpenNebula to destroy a distributed port group that was previously created by OpenNebula. |
DVPortgroup.Modify |
Modify |
Required if you want OpenNebula to create distributed port groups |
DVSwitch.Create |
Create |
Required if you want OpenNebula to create distributed virtual switches |
DVSwitch.Delete |
Delete |
Required if you want OpenNebula to destroy a distributed virtual switches that was previously created by OpenNebula. |
DVSwitch.HostOp |
Host operation |
Required if you want OpenNebula to create distributed virtual switches |
DVSwitch.Modify |
Modify |
Required if you want OpenNebula to create distributed virtual switches |
DVSwitch.PortSetting |
Port setting operation |
Required if you want OpenNebula to create distributed virtual switches |
Host.Config.Network |
Network configuration |
Required on all ESX Hosts where you want OpenNebula to create, update or delete virtual switches and port groups |
Network.Assign |
Assign network |
Required on any network the Virtual Machine will be connected to |
Resource.ApplyRecommendation |
Apply recommendation |
On all Storage Pods (Storage DRS cluster) represented by OpenNebula |
Resource.AssignVMToPool |
Assign Virtual Machine to resource pool |
Required to assign a resource pool to a Virtual Machine |
Resource.ColdMigrate |
Migrate powered off Virtual Machine |
Required to migrate powered off Virtual Machine |
Resource.HotMigrate |
Migrate powered on Virtual Machine |
Required to migrate powered on Virtual Machine |
System.Read |
Read |
Required to rename Uplink port group for a distributed switch only if you want OpenNebula to create distributed virtual switches. |
VirtualMachine.Config.AddExistingDisk |
Add existing disk |
Required to browse for and attach an existing virtual disk |
VirtualMachine.Config.AddNewDisk |
Add new disk |
Required to create and attach a new virtual disk |
VirtualMachine.Config.AddRemoveDevice |
Add or remove device |
Required to add or remove virtual devices |
VirtualMachine.Config.AdvancedConfig |
Advanced |
Required to make advanced configuration changes |
VirtualMachine.Config.Annotation |
Set annotation |
Required to set annotation on a Virtual Machine |
VirtualMachine.Config.ChangeTracking |
Disk change tracking |
Required to enable or disable change tracking for the Virtual Machine’s disks |
VirtualMachine.Config.CPUCount |
Change CPU count |
Required to change the number of virtual CPUs |
VirtualMachine.Config.DiskExtend |
Extend virtual disk |
Required to extend virtual disk |
VirtualMachine.Config.HostUSBDevice |
Host USB device |
Required to add, remove or edit a virtual USB device backed by a Host USB device |
VirtualMachine.Config.Memory |
Memory |
Required to set the amount of Virtual Machine memory |
VirtualMachine.Config.RawDevice |
Raw device |
Required for Virtual Machine raw device configuration |
VirtualMachine.Config.RemoveDisk |
Remove disk |
Required to detach and optionally remove a virtual disk |
VirtualMachine.Config.Rename |
Rename |
Required to rename a Virtual Machine |
VirtualMachine.Config.Settings |
Settings |
Required to change Virtual Machine settings |
VirtualMachine.Config.SwapPlacement |
Swapfile placement |
Required to set the placement policy for single Virtual Machine’s swapfile |
VirtualMachine.Interact.DeviceConnection |
Device connection |
Required to connect/disconnect media and network devices |
VirtualMachine.Interact.PowerOff |
Power Off |
Required to power off or shutdown a Virtual Machine |
VirtualMachine.Interact.PowerOn |
Power On |
Required to power on or resume a Virtual Machine |
VirtualMachine.Interact.Reset |
Reset |
Reset (power cycle) a Virtual Machine |
VirtualMachine.Interact.SetCDMedia |
Configure CD media |
Configure a different media for virtual CD-ROMs |
VirtualMachine.Interact.SetFloppyMedia |
Configure floppy media |
Required to configure a different floppy media |
VirtualMachine.Interact.Suspend |
Suspend |
Required to suspend a Virtual Machine |
VirtualMachine.Inventory.Create |
Create new |
Required to create a new Virtual Machine or template |
VirtualMachine.Inventory.CreateFromExisting |
Create from existing |
Required to create a Virtual Machine based on an existing virtual machine or template |
VirtualMachine.Inventory.Delete |
Remove |
Required to remove a Virtual Machine |
VirtualMachine.Inventory.Move |
Move |
Required to move a Virtual Machine |
VirtualMachine.Inventory.Register |
Register |
Required to add an existing Virtual Machine to the inventory |
VirtualMachine.Inventory.Unregister |
Unregister |
Required to unregister a Virtual Machine |
VirtualMachine.Provisioning.CloneTemplate |
Clone template |
Required to clone a template |
VirtualMachine.Provisioning.DeployTemplate |
Deploy template |
Required to deploy a Virtual Machine from a particular template |
VirtualMachine.Provisioning.ReadCustSpecs |
Read customization specifications |
Required to read customization specifications |
VirtualMachine.State.CreateSnapshot |
Create snapshot |
Required to create a new snapshot of a Virtual Machine. |
VirtualMachine.State.RemoveSnapshot |
Remove snapshot |
Required to remove snapshots from a Virtual Machine |
VirtualMachine.State.RevertToSnapshot |
Revert to snapshot |
Required to revert a Virtual Machine to a particular snapshot |
Special Permission¶
The above permissions, except one, can be set at the cluster level. However, OpenNebula needs access to the customization spec for successful monitoring. This is a special privilege because it needs to be applied to the vCenter server level. It means that if you try to apply the previous privileges to a cluster/datacenter and their inheritors, OpenNebula will fail and it will tell you that higher level permissions are necessary.
Our recommended approach is to create two roles, one for the general permissions (“opennebulapermissions”) that can be applied in the cluster level, and another to handle this single permission. This way, you can create a role for managing all OpenNebula permissions and another role (called, for instance, readcustspec) with only the following role:
Privileges ID |
Privilege name |
Notes |
VirtualMachine.Provisioning.ReadCustSpecs |
Read customization specifications |
Required to read customization specifications |
Once you have created the proper role, one way to manage these privileges is by creating two groups.
The first group needs to be assigned the readcustspec role. Place the OpenNebula user inside this group and grant permission over the vCenter instance to the group.
The second groups needs to be assigned the opennebulapermissions role. Place the OpenNebula user inside this group and grant permission over the desired cluster to the group.
Note
Do not forget to add the proper permissions to the datastores and any resource accessed by your OpenNebula user.