Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unify LXD and KVM hipervisors as Linux hypervisor #3259

dann1 opened this issue Apr 23, 2019 · 0 comments


Copy link

commented Apr 23, 2019

A Linux OS can run simultaneously KVM and LXD, acting as a virtualization node that deploys containers and VMs. Currently, in order to use a hypervisor in OpenNebula, as both KVM and LXD, there are some limitations:

  • you need to add the node twice, which is a bit cumbersome
  • ultimately this method outputs false metrics of the DataCenter in terms of amount of nodes and also unnecessary duplicated data since the CPU and RAM usage of the nodes is measured the same, as they are both Linuxes.
  • In large deployments this escalates quickly since, it is twice a lot of data
  • the drivers in /var/tmp/one/ get overwritten when the node is added for the 2nd time, which could hurt some tinkering made by an admin on a virtualization node.
  • The scheduler can mess up some VM deployments because it can deploy KVM VMs on LXD nodes and LXD containers on KVM nodes as well.

Use case
Properly setup a node as KVM and LXD virtualization node

Interface Changes
There could be a lot of changes, since the vmm that is run when deploying a container, is selected based on the destination node, and not on whether the VM template states that the VM is a container or a regular VM. Also the wild VMs would need to be classified.

Additional Context
Proxmox treats its virtualization nodes this way, clearly differentiating a container from a VM. In the case of OpenNebula, it would just be marking the hypervisor setting in the template as a required field, and select the vmm_drivers based on that.

Progress Status

  • Branch created
  • Code committed to development branch
  • Testing - QA
  • Documentation
  • Release notes - resolved issues, compatibility, known issues
  • Code committed to upstream release/hotfix branches
  • Documentation committed to upstream release/hotfix branches
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
1 participant
You can’t perform that action at this time.