Known Issues

A complete list of known issues for OpenNebula is maintained here.

This page will be updated with relevant information about bugs affecting OpenNebula, as well as possible workarounds until a patch is officially published.

Drivers - Virtualization

Drivers - Storage

Sunstone

  • Guacamole RDP as is currently shipped in OpenNebula does not support NLA authentication. You can follow these instructions in order to disable NLA in the Windows box to use Guacamole RDP within Sunstone.
  • The Windows Optimized OS Profile yaml file at /etc/one/fireedge/sunstone/profiles/windows_optimized.yaml has the wrong configuration. Utilizing such profile in Sunstone will lead to a VM that libvirt fails to create. You have to edit the file and replace its contents with the documentation yaml content.
  • Enabling fullViewMode in sunstone configuration is not working. You can find the detailed information here. This is the typo in the configuration file. You can simply fix the issue by removing one ":" in this configuration file.
  • When fullModeView mode is active and a status change is made in the VM, the buttons at the top are not updated. To see the buttons that correspond to the current status of the VM, you have to go back to the data table and reselect the VM. This error will be resolved in future versions. You can find more information here.
  • Uploaded files are not deleted from /var/tmp when creating an image from upload file. You can find detailed information here. This may also trigger a race condition that deletes the temporary file from /var/tmp preventing the correct registering of the image, this may apply in some cases only.

Migration

  • When upgrading to 7.0 the onedb migration might fail if the /etc/one/sunstone-views.yaml file contains a single, unclosed value under the labels_groups key, example:

    labels_groups:
  default:

    This can be mitigated by declaring an empty array as the value instead, example:

    labels_groups:
  default: []

Install Linux Graphical Desktop on KVM Virtual Machines

OpenNebula uses the cirrus graphical adapter for KVM Virtual Machines by default. It could happen that after installing a graphical desktop on a Linux VM, the Xorg window system does not load the appropriate video driver. You can force a VESA mode by configuring the kernel parameter vga=VESA_MODE in the GNU GRUB configuration file. Here you can find the VESA mode numbers. For example, adding vga=791 as kernel parameter will select the 16-bit 1024×768 resolution mode.

Backups - Veeam

  • If the backup chain is deleted in OpenNebula and an incremental is attempted from Veeam, the data may be corrupt, so a manual Full Backup is needed from Veeam, otherwise the incremental data will be missing.
  • After performing a backup using Veeam VNC may stop working for the backed up VM and some configuration attributes may be lost. If facing this issue, please apply the following change to the /usr/lib/one/ovirtapi-server/controllers/backup_controller.rb file in the backup server at lines ~247-251 (the 2 vm.updateconf calls need the true statement at the end). Then, restart the apache2/httpd service:
...
    vm.updateconf('BACKUP_CONFIG = ["MODE"="INCREMENT", "KEEP_LAST"="2",' \
        'BACKUP_VOLATILE"="YES"]', true) # <- Add true parameter
else
    LOGGER.info 'Backup volatiles disabled.'
    vm.updateconf('BACKUP_CONFIG = ["MODE"="INCREMENT", "KEEP_LAST"="2"]', true) # <- Add true parameter
...
  • In LVM environments, VM restores may fail to deploy if the restored VM is scheduled in the same host as the original VM (and the original is still deployed). To fix this, apply the following change to the /usr/lib/one/ovirtapi-server/controllers/vm_controller.rb file in the backup server at lines ~800. Then, restart the apache2/httpd service:
...
xml_element.delete_element('TEMPLATE/NIC')
xml_element.delete_element('TEMPLATE/DISK')
xml_element.delete_element('TEMPLATE/GRAPHICS')
xml_element.delete_element('TEMPLATE/OS/BOOT')
xml_element.delete_element('TEMPLATE/VMID')
xml_element.delete_element('TEMPLATE/OS/UUID') # <- Add this line
...

Market proxy settings

  • The option --proxy in the MARKET_MAD may not be working correctly. To solve it, execute systemctl edit opennebula and add the following entries:
[Service]
Environment="http_proxy=http://proxy_server"
Environment="https_proxy=http://proxy_server"
Environment="no_proxy=domain1,domain2"

Where proxy_server is the proxy server to be used and no_proxy is a list of the domains or IP ranges that must not be accessed via proxy by opennebula. After that, reload systemd service configuration with systemctl daemon-reload and restart opennebula with a systemctl restart opennebula

Monitoring

When configuring resource usage forecasts, it is important to ensure that the forecast period is not shorter than the probe period defined for MONITOR_HOST and MONITOR_VM in /etc/one/monitord.conf. If the forecast period is set to a value smaller than the monitoring interval, the prediction probe will raise an error and may disable monitoring for the affected Host and VMs.

By default, the monitoring interval for a Host is two minutes. In the following example, the forecast period is set to one minute, which is shorter than the Host’s monitoring interval of two minutes. This misconfiguration will result in an error and place the Host in an error state:

host:
  db_retention: 4 # Number of weeks
  forecast:
      enabled: true
      period: 1 # Number of minutes
      lookback: 60 # The look-back windows in minutes to use for the predictions

To avoid this error, always set the forecast period to a value equal to or greater than the monitoring interval. For example, if the Host monitoring interval is two minutes, the forecast period should be set to at least two minutes:

host:
  db_retention: 4 # Number of weeks
  forecast:
      enabled: true
      period: 2 # Number of minutes
      lookback: 60 # Look-back window in minutes for predictions

OneGate

LinuxContainers marketplace

The appliances on this marketplace will fail to boot when deployed on rhel10 like hosts. The parameter lxc.apparmor.profile=unconfined is what causes the issue and needs to be removed after the appliance is imported.

RAW=[
  DATA="lxc.apparmor.profile=unconfined",
  TYPE="lxc" ]

High CPU utilization due to predictions

With some configurations, the usage of CPU on the hosts can be very high, due to running predictions. In such case, the number of threads used by BLAS (Basic Linear Algebra Subprograms) can be limited to 1 (or other suitable number) with the environment variables:

export OMP_NUM_THREADS=${OMP_NUM_THREADS:-1}
export OPENBLAS_NUM_THREADS=${OPENBLAS_NUM_THREADS:-1}
export MKL_NUM_THREADS=${MKL_NUM_THREADS:-1}
export BLIS_NUM_THREADS=${BLIS_NUM_THREADS:-1}
export NUMEXPR_NUM_THREADS=${NUMEXPR_NUM_THREADS:-1}

A more comprehensive way is to replace the following old files with the appropriate files from one repository: