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.