I’ve developed a sort of framework to extend the default domain XML generated by OpenNebula. There is an option to override the default VMM_MAD scripts with local ones.
Here is a short guide how to configure it if you’d like to give it a try.
# checkout addon-storpool
git clone https://github.com/OpenNebula/addon-storpool
# copy the relevant files
cp -a addon-storpool/vmm/kvm/deploy* /var/lib/one/remotes/vmm/kvm/
# create the placeholder for the extra scripts
# and "enable" some of the scripts
# optionally if you want better windows performace add hyperv-clock.py too
# fix the ownership...
chown -R oneadmin.oneadmin /var/lib/one/remotes/vmm/kvm
After preparing the files you’ll need to enable them in oned.conf, so edit /etc/one/oned.conf and add to the VM_MAD’s ARGUMENTS:
VM_MAD = [
ARGUMENTS = "-t 15 -r 0 kvm -l deploy=deploy-tweaks",
The topology is configured via variables in the VM’s “USER TEMPLATE”. To protect the variables to be editable only by the oneadmin user you should append the following lines to /etc/one/oned.conf:
cat >>/etc/one/oned.conf <<EOF
VM_RESTRICTED_ATTR = "T_CPU_THREADS"
VM_RESTRICTED_ATTR = "T_CPU_SOCKETS"
VM_RESTRICTED_ATTR = "T_CPU_FEATURES"
VM_RESTRICTED_ATTR = "T_CPU_MODE"
VM_RESTRICTED_ATTR = "T_CPU_MODEL"
VM_RESTRICTED_ATTR = "T_CPU_VENDOR"
VM_RESTRICTED_ATTR = "T_CPU_CHECK"
VM_RESTRICTED_ATTR = "T_CPU_MATCH"
After the configuration changes you must restart the opennebula service and update the hosts with
su - oneadmin -c 'onehost sync --force'
Here is how it works. With this configuration OpenNebula will call the deply-tweaks on the front-end instead of calling /var/tmp/one/vmm/kvm/deploy on the KVM host via ssh. The deploy-tweaks script cache the domain XML and will query opennebula for the VM details (a.k.a. the VM’s metadata). Then it will pass both the domain XML and the VM’s metadata to each of the
*.py scripts in deploy-tweaks.d/ folder. Each called script will tweak the domain XML. Finally deploy-tweaks will ssh to the KVM host and pass the tweaked domain XML to the OpenNebula’s native deploy script that will start the VM.
Regarding the configuration variables for your case, you’ll need to define in the VM’s USER TEMPLATE
T_CPU_THREADS = 2 and
T_CPU_SOCKETS = 2 (and have even number of VCPUs ). The other variables are mostly for internal use to define weird testing VM configurations.
Here is an example of a configuration - these are the VM Attributes:
Finally you should restart the reconfigured VM so the tweaked deploy script will kick in.
Hope this helps.
Edit: Please note that you’ll probably need to add some python library packages on the front-end, though.