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.

Core

Drivers - Virtualization

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 following new features have not been integrated into Sunstone yet, but are planned for a future release:

    • New monitor message EXEC_VM to retrieve the result of commands executed inside a Virtual Machine.
    • VirtioFS datastores enable Virtual Machines to directly access host filesystems, providing fast, low-latency shared file access. This simplifies data sharing across VMs while improving performance for data-intensive workloads.

Migration

  • When upgrading to 7.2 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.

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

SUSE

  • The following components are not available for SUSE in 7.2:

    • opennebula-form
    • opennebula-ovirt
    • opennebula-lxc
  • PyONE gRPC is not working on openSUSE 16 due to a protobuf packaging bug. The workaround is to force-install a compatible version:

    pip3.13 install protobuf==5.28.3 --force
    

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" ]