Bug #28003

VM is allways created with 1 vCPU

Added by Nikola Belavic almost 3 years ago. Updated 5 months ago.

Bugzilla link:
Fixed in Releases:
Found in Releases:


I am using foreman xen plugin to create new VMs. I am using network based provisioning.
Everything is OK, except VCPU - all VMs are always created with only 1 vCPU

Foreman Version 1.22
ruby-foreman-xen (1.0.0-1) - installed from debian package
OS: Debian 9.9
XCP-ng (Xenserver fork) version 7.6 (all features should be identical to Xenserver 7.6)

I have searched foreman and xen logs, but i didn't found anything usefull. If you want, i cann provide these logs.

foreman-production.log foreman-production.log 18.6 KB foreman production.log Nikola Belavic, 10/04/2019 04:02 PM
xensource.log xensource.log 38.5 KB log file from xcp-ng pool master Nikola Belavic, 10/04/2019 04:02 PM

Associated revisions

Revision 26e92068 (diff)
Added by Michael Moll over 2 years ago

Fixes #28003 - correct VCPUs_max / VCPUs_at_startup casing


#1 Updated by Nikola Belavic almost 3 years ago

Here are log files...

#2 Updated by Nikola Belavic almost 3 years ago

I found this in audit.log on xcp-ng:

Oct 4 15:06:37 alphecca01 xapi: [20191004T13:06:37.984Z|audit|alphecca01|9936812 INET :::80|VM.create R:86eee6b15ab0|audit] ('trackid=fa7f9026338190078d18840400cc4eab' 'LOCAL_SUPERUSER' 'root' 'ALLOWED' 'OK' 'API' 'VM.create' (('name_description' 'To use this template from the CLI, install your VM using vm-install, then set other-config-install-repository to the path to your network repository, e.g. http://&lt;server&gt;/&lt;path> or nfs:server:/<path>' '' '') ('ha_always_run' 'B(false)' '' '') ('ha_restart_priority' '' '' '') ('is_a_template' 'B(false)' '' '') ('memory_dynamic_max' '4294967296' '' '') ('memory_dynamic_min' '4294967296' '' '') ('memory_static_max' '4294967296' '' '') ('memory_static_min' '4294967296' '' '') ('memory_target' '0' '' '') ('name_label' 'blake-pridgen.testbla2.local' '' '') ('affinity' 'alphecca02' 'f18509a2-64f4-401a-8009-364bc9c49aa1' 'OpaqueRef:987ef14b-5065-44bf-9a94-de78d730fdbe')))

There is no mention of vcpu settings...

#3 Updated by Nikola Belavic over 2 years ago

  • Assignee set to Anonymous
  • Priority changed from Normal to Urgent

#4 Updated by Anonymous over 2 years ago

  • Assignee deleted (Anonymous)
  • Priority changed from Urgent to Low

Please do not assign issues to random people.

#5 Updated by Nikola Belavic over 2 years ago

Sorry about that :(
I just thought you are most skilled to resolve this...
I am fighting with this for a long time now, but i am failing to resolve it (i don't have adequate ruby knowledge).
I am using foreman for baremetal provisioning and this plugin would be great addition for vm provisioning.

Please help!

#6 Updated by Nikola Belavic over 2 years ago

I think i found problem.
I did some additional logging in gems/foreman_xen-1.0.0/app/models/foreman_xen/xenserver.rb and found out that after

(line 348)     vm_attr = template.attributes.dup.merge(attr)

i have duplicate args in "vm_attr" (vcpus_max, VCPUs_max and vcpus_at_startup, VCPUs_at_startup), so i did a following:

root@foreman-2-master:/usr/share/foreman/vendor/ruby/2.3.0/gems/foreman_xen-1.0.0/app/models/foreman_xen# diff -u xenserver.rb-orig xenserver.rb
--- xenserver.rb-orig   2020-01-28 16:59:06.710976277 +0100
+++ xenserver.rb        2020-01-29 12:29:49.076579264 +0100
@@ -273,8 +273,8 @@
         name:               args[:name],
         name_description:   args[:comment],
-        VCPUs_max:          args[:vcpus_max],
-        VCPUs_at_startup:   args[:vcpus_max],
+        vcpus_max:          args[:vcpus_max],
+        vcpus_at_startup:   args[:vcpus_max],
         memory_static_max:  args[:memory_max],
         memory_dynamic_max: args[:memory_max],
         memory_dynamic_min: args[:memory_min],
@@ -346,6 +346,15 @@

After that, creating VM from template works as expected.
Can somebody please check/verify this and implement in next release?
I am not a developer, maybe there is better solution (like automatic conversion to lowercase, or something?).

#7 Updated by Anonymous over 2 years ago

  • Status changed from New to Ready For Testing
  • Pull request added

Could please test the linked PR? It extends the lowercasing to all occurrences.

#8 Updated by Nikola Belavic over 2 years ago

So far, various tests are OK.
For now, I am only doing tests with template based provisioning.

#9 Updated by Anonymous over 2 years ago

  • Status changed from Ready For Testing to Closed

#10 Updated by Martin Juhl 5 months ago

  • Difficulty set to trivial
  • Priority changed from Low to Normal
  • Found in Releases 1.7.2 added


I think that this bug has been solved incorrectly..

If you look at: the variable is actually uses the uppercase variant..

Using the upstream 1.0.1 version fails for us, when trying to deploy, telling us that the uppercase variant of the variable can't be found...

I don't know how this has been working for @Nikola, but as far as I can tell, the variable has never been using the lower case variant..

Can we please reverse this commit?

Also available in: Atom PDF